ПРИМЕЧАНИЕ
Было бы удобно указывать в файле /etc/resolv.conf имена, а не IP-адреса серверов имен, потому что имена удобнее запоминать и редактировать, однако это возвратило бы нас к вечной проблеме курицы и яйца: каким образом распознать имя сервера имен?
Распознаватель посылает запрос локальному серверу имен, используя UDP. Если локальный сервер имен не знает ответа, он обычно запрашивает другие серверы имен через Интернет, также используя UDP. Если ответ слишком велик, чтобы поместиться в один UDP-пакет, распознаватель автоматически переключается на TCP.
Альтернативы DNS
Можно получить информацию об имени и адресе без использования DNS. Типичной альтернативой служат статические файлы со списком узлов (обычно файл
/etc/hosts
, как мы указываем в табл. 11.2), информационная система сети (Network Information System, NIS) и упрощенный протокол службы каталогов (Lightweight Directory Access Protocol — LDAP). К сожалению, способ конфигурирования узла для использования различных типов служб имен зависит от реализации. Solaris 2.x, HP-UX 10 и более новых версий, а также FreeBSD 5.x используют файл
/etc/nswitch.conf
, тогда как AIX использует файл
/etc/netsvc.conf
. BIND 9.9 предоставляет свою собственную версию, которая называется IRS (Information Retrieval Service — служба получения информации), использующую файл
/etc/irs.conf
. Если сервер имен должен применяться для поиска имен узлов, все эти системы используют для задания IP-адресов серверов имен файл
/etc/resolv.conf
. К счастью, эти различия обычно скрыты от программиста приложений, поэтому мы просто вызываем функции распознавателя, такие как
gethostbyname
и
gethostbyaddr
.
11.3. Функция gethostbyname
Узлы компьютерных сетей мы обычно идентифицируем по их именам, удобным для человеческого восприятия. Но во всех примерах книги специально использовались IP-адреса вместо имен, поэтому мы точно знаем, что входит в структуры адресов сокетов для таких функций, как
connect
и
sendto
, и что возвращается функциями
accept
и
recvfrom
. Тем не менее большинство приложений имеют дело с именами, а не с адресами. Это особенно актуально при переходе на IPv6, поскольку адреса IPv6 (шестнадцатеричные строки) значительно длиннее адресов IPv4, записанных в точечно-десятичном представлении. (Например, запись типа AAAA и запись типа PTR для
ip6.arpa
в предыдущем разделе показывают это со всей очевидностью.)
Самая основная функция, выполняющая поиск имени узла, — это функция
gethostbyname
. При успешном выполнении она возвращает указатель на структуру
hostent
, содержащую все адреса IPv4 для узла. Однако она может возвращать только адреса IPv4. В разделе 11.6 рассматривается функция, возвращающая адреса IPv4 и IPv6. Стандарт POSIX предупреждает, что функция
gethostbyname
может быть исключена из будущей его версии.
ПРИМЕЧАНИЕ
Маловероятно, что реализации gethostbyname исчезнут раньше, чем весь Интернет перейдет на протокол IPv6, а произойдет это еще очень не скоро. Однако удаление функции из стандарта POSIX гарантирует, что она не будет использоваться в новых программах. Вместо нее мы рекомендуем использовать getaddrinfo (раздел 11.6).
#include <netdb.h>
struct hostent *gethostbyname(const char *<i>hostname</i>);
<i>Возвращает: непустой указатель в случае успешного выполнения, -1 в случае ошибки</i>
Непустой указатель, возвращаемый этой функцией, указывает на следующую структуру
hostent
:
struct hostent {
char *h_name; /* официальное (каноническое) имя узла */
char **h_alihases; /* указатель на массив указателей на псевдонимы */
int h_addrtype; /* тип адреса узла: AF_INET */
int h_length; /* длина адреса: 4 */
char **h_addr_list; /* указатель на массив указателей с адресами IPv4 или IPv6 */
};
В терминах DNS функция
gethostbyname
выполняет запрос на запись типа А. Функция возвращает только адреса IPv4.
На рис. 11.2 представлено устройство структуры
hostent
и содержащаяся в ней информация, в предположении, что искомое имя узла имеет два альтернативных имени и три адреса IPv4. Все имена узла представляют собой строки языка С.
Рис. 11.2. Структура hostent и ее одержимое
Возвращаемое имя
h_name
называется каноническим именем узла. Например, с показанными в предыдущем разделе записями CNAME каноническое имя узла
ftp://ftp.unpbook.com
будет иметь вид
linux.unpbook.com
. Также если мы вызываем функцию
gethostbyname
с узла
aix
с неполным именем, например
solaris
, то в качестве канонического имени возвращается полное доменное имя (FQDN)
solaris.unpbook.com.
.
ПРИМЕЧАНИЕ
Некоторые версии функции gethostbyname допускают, что аргумент hostname может быть записан в виде строки десятичных чисел, разделенных точками. То есть вызов в форме hptr = gethostbyname("206.62.226.33"); будет работать. Этот код был добавлен, поскольку клиент Rlogin принимает только имя узла, вызывая функцию gethostbyname, и не принимает точечно-десятичную запись [127]. Стандарт POSIX допускает это, но не устанавливает такое поведение в качестве обязательного, поэтому переносимое приложение не может использовать указанную особенность.
Функция
gethostbyname
отличается от других функций сокетов, описанных нами, тем, что она не задает значение переменной
errno
, когда происходит ошибка. Вместо этого она присваивает глобальной целочисленной переменной
h_errno
одну из следующих констант, определяемых в заголовке
<netdb.h>
:
■
HOST_NOT_FOUND
;
■
TRY_AGAIN
;
■
NO_RECOVERY
;
■
NO_DATA
(идентично
NO_ADDRESS
).
Ошибка
NO_DATA
означает, что заданное имя действительно, но у него нет записи типа А. Примером может служить имя узла, имеющего только запись типа MX.
