Resolve host name to an ip address
I developed a client/server simulation application. I deployed client and server on two different Windows XP machines. Somehow, the client is not able to send requests to the server.
I tried below options:
Pinged server machine successfully from client using ip-address.
Pinged client machine successfully from server using ip-address.
Checked netstat command line tool from both machines. Server is in LISTENING mode and client is in SYS_SENT mode. But the foreign address it is using to send is host name not the ip address.
Pinged server machine unsuccessfully using host name from client.
Pinged client machine successfully using host name from server.
I feel the problem is when the client is trying to connect to the server using the host name.
Could you please let me know how to force an application to use an ip address instead of a host name? Is there any other way to map the host name to an ip address?
5 Answers 5
Go to your client machine and type in:
substituting the real host name of your server for server.company.com , of course.
That should tell you which DNS server your client is using (if any) and what it thinks the problem is with the name.
To force an application to use an IP address, generally you just configure it to use the IP address instead of a host name. If the host name is hard-coded, or the application insists on using a host name in preference to an IP address (as one of your other comments seems to indicate), then you’re probably out of luck there.
However, you can change the way that most machine resolve the host names, such as with /etc/resolv.conf and /etc/hosts on UNIXy systems and a local hosts file on Windows-y systems.
Try tracert to resolve the hostname. IE you have Ip address 8.8.8.8 so you would use; tracert 8.8.8.8
You could use a C function getaddrinfo() to get the numerical address — both ipv4 and ipv6. See the example code here
This is hard to answer without more detail about the network architecture. Some things to investigate are:
- Is it possible that client and/or server is behind a NAT device, a firewall, or similar?
- Is any of the IP addresses involved a «local» address, like 192.168.x.y or 10.x.y.z?
- What are the host names, are they «real» DNS:able names or something more local and/or Windows-specific?
- How does the client look up the server? There must be a place in code or config data that holds the host name, simply try using the IP there instead if you want to avoid the lookup.
Windows XP has the Windows Firewall which can interfere with network traffic if not configured properly. You can turn off the Windows Firewall, if you have administrator privileges, by accessing the Windows Firewall applet through the Control Panel. If your application works with the Windows Firewall turned off then the problem is probably due to the settings of the firewall.
We have an application which runs on multiple PCs communicating using UDP/IP and we have been doing experiments so that the application can run on a PC with a user who does not have administrator privileges. In order for our application to communicate between multiple PCs we have had to use an administrator account to modify the Windows Firewall settings.
In our application, one PC is designated as the server and the others are clients in a server/client group and there may be several groups on the same subnet.
The first change was to use the functionality of the Exceptions tab of the Windows Firewall applet to create an exception for the port that we use for communication.
We are using host name lookup so that the clients can locate their assigned server by using the computer name which is composed of a mnemonic prefix with a dash followed by an assigned terminal number (for instance SERVER100-1). This allows several servers with their assigned clients to coexist on the same subnet. The client uses its prefix to generate the computer name for the assigned server and to then use host name lookup to discover the IP address of the assigned server.
What we found is that the host name lookup using the computer name (assigned through the Computer Name tab of the System Properties dialog) would not work unless the server PC’s Windows Firewall had the File and Printer Sharing Service port enabled.
So we had to make two changes: (1) setup an exception for the port we used for communication and (2) enable File and Printer Service in the Exceptions tab to allow for the host name lookup.
Resolve host name from IP address
I’m looking for a command line tool which gets an IP address and returns the host name, for Windows.
8 Answers 8
The command you are looking for is called nslookup , works fine for reverse lookups IFF someone has configured a reverse zone file, which they don’t always do.
if all the above fails, and you are specifically looking for a Windows machine, you can use
The data returned will be all the NetBIOS records the machine has. The one with a record type will usually be the machine’s name.
For many IP addresses you could just use ping -a, for example
If you use nslookup command with the IP address as its first argument will return the PTR record (the reverse entry) if it exists. For example:
Use dig. A Windows port is available from the ISC here (look in the immediate download box for the link to the zip file). Here’s their man page reference for dig.
Ward’s point about the reverse lookup records often not getting created is very much true. Reverse lookups often do fail because many admins don’t bother creating the ptr records.
(tested under Windows 10 x64)
From command line:
FOR /F «tokens=2 delims= » %A in (‘2^>NUL NSLOOKUP «%IP_ADDRESS%» ^| FINDSTR /C:»: «‘) do ECHO %A
Within a script:
FOR /F «tokens=2 delims= » %%A in (‘2^>NUL NSLOOKUP «%IP_ADDRESS%» ^| FINDSTR /C:»: «‘) do ECHO %%A
Two (side)notes:
- To supress NSLOOKUP errors you have to use 2^>NUL instead of 1^>NUL
- I’ve used FINDSTR /C to extract the value after the four whitespace characters. As the four spaces only seem to exist for the Name: entry, this appears to be only way to make it work on other localized systems.
Resolve ip address windows
Как уже говорилось выше, система разрешения доменных имен IP-адресами и обратная процедура построены по схеме «клиент-сервер». Функции из библиотеки libc.a (или libc.so) выступают в качестве клиентов, а вся их совокупность носит название resolver. Для того, чтобы клиент мог обратиться к серверу, он должен знать следующее:
- Установлен ли вообще сервер доменных имен,
- Если сервер установлен, то где (IP-адрес сервера доменных имен).
- Если сервер установлен, то к какому домену относится машина.
Иногда название BIND (Berkeley Internet Name Domain) вводит новичков в заблуждение. Им кажется, что речь идет не о программе, а некой альтернативе другой системе доменных имен. Для того чтобы этого избежать, иногда вместо слова «domain» используют слово «daemon», обычно употребляющиеся для обозначения программ-демонов в системах Unix, которые находятся в памяти компьютера и выполняют служебные операции. Для того чтобы потом не повторяться, сразу поясним различия между DNS и BIND.
Знать это нужно для того, чтобы правильно формировать запросы к серверу/ам доменных имен и не перегружать систему лишними или некорректными запросами.
Главная задача resolver — принять запрос от прикладного программного обеспечения, провзаимодействовать с серверами DNS и вернуть в зависимости от запроса либо IP-адрес, либо доменное имя.
Очевидно, что можно это сделать двумя разными способами. Во-первых, путем итеративного опроса серверов, а, во-вторых, путем посылки рекурсивного запроса одному из серверов доменных имен, который этот запрос и обслужит.
Рис.1. Типовая схема взаимодействия Resolver с локальным сервером доменных имен.
На практике второй способ является наиболее распространенным. При этом согласно RFC-1034 речь идет о так называемом «усеченном» resolver (stub resolver).
В RFC-1034 указано также, что основной задачей resolver является обеспечение максимально быстрого обслуживания запросов прикладных программ к системе DNS. Основное место здесь отводится кэширующим resolver-ам. Однако, stub resolver таковым не является. Это значит, что каждый раз, когда прикладная программа запрашивает систему DNS resolver посылает запрос локальному серверу доменных имен.
Любопытно, что в стандартном resolver (см. man resolver — http://ddb.kharkov.ua/cgi-bin/bsdi-man?proto=1.1&query=resolver&msection=3&apropos=0, например) предусмотрена возможность итеративного опроса серверов доменных имен, но не предусмотрена возможность кэширования.
В Windows 2000 предусмотрен кэширующий resolver, который запускается в системе в качестве сервиса по умолчанию. Существует возможность остановки и повторного пуска этого сервиса, а также просмотра результатов его работы. Важно отметить, что данный resolver умеет осуществлять «отрицательное» кэширование (negative caching). Это значит что, если на какой-либо запрос поступает отрицательный ответ, например, отсутствие данного доменного имени, то этот ответ запоминается, и в следующий раз прикладная программа получит «отлуп» прямо из кэша resolver, а не после процедуры безуспешного поиска по серверам доменных имен. Естественно, что «отрицательный» ответ хранится в кэше resolver ограниченное время (Windows 2000 TCP/IP. DNS Resolver Cache Service.).
На самом деле, появление нового resolver в Windows 2000 позволило решить некоторые проблемы, которые windows-системы доставляли системе доменных имен (см. «Полезные ссылки» [2]). Впрочем всех проблем новый resolver Microsoft так и не решил.
В рамках пакета BIND также существует кэширующий resolver, который фактически реализует функции кэширующего сервера доменных имен. При этом он реализован как процесс-демон. О его настройках и использовании мы остановимся в конце данного раздела.
Рассуждения о настройке resolver мы будем вести в терминах Unix системы, если речь пойдет о другом операционном окружении, то это будет оговорено отдельно.
Традиционно вся совокупность параметров настройки resolver задается в файле /etc/resolv.conf. Приведем примера этого файла и разберем назначение каждой из команд, которая может быть использована в файле настройки resolver.
#
# Resolver config for paul.
#
domain polyn.kiae.su
nameserver 144.206.130.137
Строки, начинающиеся с символа «#» — это комментарии. Среди них следует выделить строку «nonameserver». В нашем примере она не влияет на работу системы разрешения доменных имен, но если в сети нет сервера доменных имен, то следует с этой строки снять символ комментария, а прочие команды напротив превратить в комментарии. При отсутствии сервера доменных имен система будет использовать файл /etc/hosts (см. «История и правила именования хостов»).
По директиве domain resolver определяет, в каком домене он функционирует. Это локальное доменное имя. Локальным доменным именем называют имя домена, в который входит хост, где выполняется прикладная программа, использующая библиотеку resolver-а. Например, если хост имеет имя host.kuku.ru, то локальным доменным именем будет kuku.ru.
Узанать локальное доменное имя просто — нужно выполнить команду Hostname:
В данном случае локальное доменное имя — polyn.kiae.su.
Обычно, локальным доменным именем, которое указано после директивы domain, расширяются неполные имена хостов. Например, если обратиться к какой-либо машине с компьютера из предыдущего примера только по имени машины:
/usr/paul> telnet radleg
то система расширит имя radleg именем домена, и будет искать машину с именем radleg.polyn.kiae.su.
Указанный выше пример — это только частный случай процедуры расширения неполного имени, которая используется функциями resolver. В литературе этот процесс называется применением списка поиска.
Различают два алгоритма применения списка поиска. Ниже представлен алгоритм, который использует resolver стандартной библиотеки libc.a. Большинство клонов Unix (различные версии этой операционной системы) поставляются именно с таким алгоритмом. Обычно именно он применялся в 4-ых версиях пакета BIND.
В общем виде он выглядит следующим образом:
- Если в прикладной программе указано имя хоста с точкой на конце, то расширение имени не производится:
В данном случае имя «polyn.» завершено точкой.
/usr/paul> ping paul.polyn
Будет выполнена подстановка по следующим правилам: если в качестве домена в resolv.conf указан домен polyn.kiae.su, то будет проверена следующая последовательность имен: paul.polyn; paul.polyn.polyn.kiae.su; paul.polyn.kiae.su. Последнее имя будет разрешено сервером доменных имен. Ниже приведен пример поиска IP-адреса по списку поиска для неполного имени paul.polyn:
> paul.polyn
Server: IRIS.polyn.kiae.su
Address: 144.206.192.10
;; res_nmkquery(QUERY, paul.polyn, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
paul.polyn, type = A,/> AUTHORITY RECORDS:
-> (root)
ttl = 325 (5m25s)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2002091600
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
————
;; res_nmkquery(QUERY, paul.polyn.polyn.kiae.su, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
paul.polyn.polyn.kiae.su, type = A,/> AUTHORITY RECORDS:
-> polyn.kiae.su
ttl = 3600 (1H)
origin = polyn.net.kiae.su
mail addr = paul.kiae.su
serial = 231
refresh = 3600 (1H)
retry = 300 (5M)
expire = 9999999 (16w3d17h46m39s)
minimum ttl = 3600 (1H)
————
;; res_nmkquery(QUERY, paul.polyn.kiae.su, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 3, additional = 3
QUESTIONS:
paul.polyn.kiae.su, type = A,/> ANSWERS:
-> paul.polyn.kiae.su
internet address = 144.206.192.34
ttl = 3600 (1H)
AUTHORITY RECORDS:
-> polyn.kiae.su
nameserver = polyn.net.kiae.su
ttl = 3600 (1H)
-> polyn.kiae.su
nameserver = ns.spb.su
ttl = 3600 (1H)
-> polyn.kiae.su
nameserver = ns.ussr.eu.net
ttl = 3600 (1H)
ADDITIONAL RECORDS:
-> polyn.net.kiae.su
internet address = 144.206.160.32
ttl = 85775 (23h49m35s)
-> ns.spb.su
internet address = 193.124.83.69
ttl = 159806 (1d20h23m26s)
-> ns.ussr.eu.net
internet address = 193.124.22.65
ttl = 170465 (1d23h21m5s)
————
Name: paul.polyn.kiae.su
Address: 144.206.192.34
В этом примере адрес был успешно найден. А вот пример, в котором адрес не был найден:
> paul.polyn.kiae
Server: IRIS.polyn.kiae.su
Address: 144.206.192.10
;; res_nmkquery(QUERY, paul.polyn.kiae, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
paul.polyn.kiae, type = A,/> AUTHORITY RECORDS:
-> (root)
ttl = 86400 (1D)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2002091600
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
————
;; res_nmkquery(QUERY, paul.polyn.kiae.polyn.kiae.su, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
paul.polyn.kiae.polyn.kiae.su, type = A,/> AUTHORITY RECORDS:
-> polyn.kiae.su
ttl = 3600 (1H)
origin = polyn.net.kiae.su
mail addr = paul.kiae.su
serial = 231
refresh = 3600 (1H)
retry = 300 (5M)
expire = 9999999 (16w3d17h46m39s)
minimum ttl = 3600 (1H)
————
;; res_nmkquery(QUERY, paul.polyn.kiae.kiae.su, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
paul.polyn.kiae.kiae.su, type = A,/> AUTHORITY RECORDS:
-> kiae.su
ttl = 86400 (1D)
origin = ns.kiae.ru
mail addr = noc-dns.relarn.ru
serial = 650127450
refresh = 28800 (8H)
retry = 3600 (1H)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
Запрашивался адрес для неполного имени paul.polyn.kiae, в resolv.conf в качестве локального имени домена было указано:
Почему же мы не нашли адреса для имени? Потому, что список поиска остановился на paul.polyn.kiae.kiae.su, т.е. при переборе имен локальное доменное имя можно усечь только до имени состоящего из меток двух доменов. В нашем случае — это kiae.su.
Если ваш resolver ведет себя приведенным выше способом, то следует проверить, что в директиве domain срока заканчивается не пробелом, а отображаемым символом. В противном случае возможны ошибки при разрешении имен.
Усечение до двухзвенного имени вызвано проблемой, которая описана в RFC-1535. Суть ее заключается в том, при полном поиске, т.е. при подстановке и однозвенного имени появлялась реальная возможность «улететь» совсем на другой хост.
Например, если зарегистрировать в com домен ru (ru.com), то для всех пользователей машин из домена com, которые хотят попасть в домен ru, появляется возможность попасть в приватный домен ru.com, т.к. обычно пользователи не указывают на конце символа «.». При этом у администратора домена ru.com появляется возможность по своему усмотрению накручивать, например, сайт www.ru.com.
К слову сказать, ru.com уже зарегистрирован. Вот отчет whois:
Registrant:
Central Nic Ltd (RU70-DOM)
13 Bowerdean St Fulham
London, SW6 3TU
UK
Domain Name: RU.COM
Administrative Contact, Technical Contact:
Hostmaster (HO4073-ORG) hostmaster@CENTRALNIC.NET
CentralNic Ltd
163 New Kings Road
London
UK
+44 20 7384 3050Fax- +44 20 7736 9253
Fax- — +44 20 7736 9253
Record expires on 23-Jun-2010.
Record created on 23-Jun-2000.
Database last updated on 16-Sep-2002 10:56:25 EDT.
Domain servers in listed order:
NS0.CENTRALNIC.NET 195.82.125.70
NS1.CENTRALNIC.NET 212.18.224.66
LON-NS-2.CENTRALNIC.NET 195.149.39.141
ESS-NS-0.CENTRALNIC.NET 194.221.62.8
NS0.JML.NET 195.149.39.76
Кроме того, www.ru.com тоже уже занят.
Новые (с BIND 4.9) версии resolver, которые входят в состав BIND работают иначе:
- Если введено имя хоста без точек, то оно расширяется локальным доменным именем
- Если пункт 1 не дал результата, то введенное имя используется в качестве имени TLD.
- Если введенное имя содержит составное, но не полное (fully qualified domain name — FQDN), имя, то в этом случае сначала проверяется введенное имя без расширения его локальным доменным именем.
- Если пункт 3 не дал результата, то введенное имя расширяется локальным доменным именем.
Усечений локального доменного имени в этом алгоритме не предусмотрено.
Если по каким-либо причинам стандартный алгоритм применения списка поиска не устраивает, то тогда вместо директивы damin в resolv.conf применяют директиву search:
После директивы search через пробел или табуляцию указывают доменные имена, которые будут расширять введенное пользователем имя, если оно не относится к FQDN.
Следует заметить, что размер списка не безграничен. Всего он может содержать 256 символов.
При указании имени домена следует учитывать то, как будет в этом случае работать весь комплекс программного обеспечения, установленный на данном компьютере. Дело в том, что некоторые программы, sendmail, например, способны сами решать проблему определения IP-адресов по именам (то бишь использовать свои собственные функции при обращении к DNS, например, sm_gethostbyname()). В ряде случаев это может привести к противоречиям и ошибкам при функционировании такого сорта программ.
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. Возможно указание нескольких серверов. Обычно — это не более трех серверов доменных имен.
На самом деле, если собирать библиотеку resolver самостоятельно, то число сервер, которое можно указывать в resolv.conf может быть установлено произвольно Определяется переменной MAXNS в файле /usr/include/resolv.h.
Вообще говоря, многие ограничения resolver заданы переменными в этом файле. Например, максимальное число элементов списка поиска — MAXDNSRCH, минимальный уровень вложенности локального доменного имени — LOCALDOMAINPARTS и т.п..
Если нет указаний на сервер доменных имен, то предполагается, что существует локальный сервер доменных имен. В старых версиях предполагалось, что он размещен по адресу 127.0.01, в новых версиях предполагается, что локальный адрес 0.0.0.0. Изменение адреса связано с проблемами, которые возникали при работе хоста через коммутируемые соединения. Предполагалось, что адрес умолчания — это адрес полученный через ifconfig в момент начальной загрузки машины. В этом случае интерфейс должен быть поднят и активен. Все такого сорта адреса интерфейсов маршрутизировались через 127.0.0.1. Но если интерфейс не поднимался, то возникало «залипание» и машина висла на этапе начальной загрузки. Изменение адреса позволяет решить эту проблему в рамках самого пакета.
Общая рекомендация такова: всегда нужно создавать файл resolv.conf и указывать в нем адрес локального сервера доменных имен.
Если указано несколько серверов доменных имен, то адрес каждого сервера указывается отдельной строкой в файле resolv.conf:
# resolv.conf
search corp.ru .
nameserver 192.168.0.1
nameserver 192.168.0.2
nameserver 192.168.0.3
Опрос серверов осуществляется по порядку их указания в файле resolv.conf. Сначала будет опрашиваться 192.168.0.1, потом, если первый сервер не ответил, — 192.168.0.2, и последним, если не ответили первые два, — 192.168.0.3. Минимальный интервал времени между попытками по умолчанию (переменная RES_TIMEOUT в файле resolv.conf — 5 секунд). Обычно resolver делает 2 или 3 серии попыток (зависит от версии).
Resolver не упорядочивает сервера из директив nameserver по продолжительности времени отклика от них. Он их всегда опрашивает в том порядке, в котором они указаны в файле resolv.conf. Наиболее целесообразно первым указывать основной сервер доменных имен данного домена, а вторым дублирующий сервер доменных имен данного домена .
Обычно директивами domain, search, nameserer и ограничиваются при описании файла настройки resolv.conf. Более подробную информацию можно найти на страницах руководств системных администраторов операционных систем (ссылка на man Unix приведен в «полезных» ссылках).
И в заключении несколько слов об «умном» resolver пакета BIND 9. Он носит название lwresd и запускается в момент начальной загрузки системы как демон. Прикладные программы для работы с ним должны быть отредактированы с библиотекой вызовов этого resolver (BIND 9 lightweight resolver library).
