DNS-запрос AAAA на интерфейсе ipv4

Мы используем RH5.8 с отключенным ipv6.

служба named(bind) находится в режиме пересылки (кеш включен)

options {
   directory "/var/named";
   listen-on { 127.0.0.1; };
   forwarders {10.10.12.1;};
   forward only;
};

Похоже, что некоторые команды (например, telnet) всегда запрашивают запись AAAA в первую очередь, а при возврате к запросу A записывают ответ (Нет такого имени) уже в именованном кэшировании.

В результате клиенты всегда получают ошибку.

в приведенном ниже примере 10.10.10.1 — это локальный IP-адрес:

127.0.0.1 -> 127.0.0.1    DNS Standard query AAAA testapp.test.com

10.10.10.1 -> 10.10.12.1 DNS Standard query AAAA testapp.test.com

10.10.10.1 -> 10.10.12.1 DNS Standard query AAAA testapp.test.com

10.10.12.1 -> 10.10.10.1 DNS Standard query response, No such name

127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name

127.0.0.1 -> 127.0.0.1    DNS Standard query A testapp.test.com

127.0.0.1 -> 127.0.0.1    DNS Standard query response, No such name

Я поискал в сети и обнаружил, что не только я сталкивался с такой проблемой http://www.linuxforums.org/forum/red-hat-fedora-linux/136217-disabling-ipv6-dns-queries.html

less /etc/modprobe.conf
  alias net-pf-10 off
  alias ipv6 off
  options ipv6 disable=1

less /etc/sysconfig/network
 NETWORKING_IPV6=no

less /etc/sysconfig/named
 OPTIONS="-4"

named -v
 BIND 9.3.6-P1-RedHat-9.3.6-20.P1.el5

но, к сожалению, пока не нашел решения...


person Greg Dan    schedule 07.04.2013    source источник
comment
Да: система всегда сначала ищет записи IPv6 AAAA. Это нормально и не должно создавать проблем для приложений. Они не получают записи AAAA, они получают только записи A и подключаются через IPv4.   -  person Sander Steffann    schedule 07.04.2013
comment
В некоторых случаях это создает проблему, так как именованное кэширование Нет ответа на такое имя для записи AAAA и не запрашивает запись A из DNS.   -  person Greg Dan    schedule 07.04.2013
comment
Затем либо авторитетный, либо пересылающий DNS-сервер неисправен (он не должен давать ответ No-Such-Name, если имя существует, даже если запрошенный тип записи не существует), либо действительно нет записи A, и в этом случае поведение правильное. В вашем случае он кажется первым, поэтому человек, который запускает этот DNS-сервер, должен получить дополнительную подсказку ... Они делают свой сервис недоступным для все больших и больших частей Интернета.   -  person Sander Steffann    schedule 07.04.2013
comment
Большое спасибо, в моем случае верно первое. Не могли бы вы направить меня к соответствующему RFC или другому документу, чтобы я мог спорить с ИТ-специалистами?   -  person Greg Dan    schedule 07.04.2013
comment
Соответствующий RFC — 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses.   -  person bortzmeyer    schedule 14.04.2013


Ответы (1)


По запросу в комментариях: некоторые пояснения по отрицательному кэшированию.

Разница между NXDOMAIN и NODATA описана в разделе 5 RFC 2308:

Отрицательный ответ, полученный в результате ошибки имени (NXDOMAIN), следует кэшировать, чтобы его можно было извлечь и вернуть в ответ на другой запрос для того же ‹QNAME, QCLASS›, который привел к кэшированному отрицательному ответу.

Таким образом, NXDOMAIN может кэшироваться на основе QNAME (т. е. «blabla.example.com.») и QCLASS (обычно «IN»). Значит, blabla.example.com вообще не существует. Отрицательная запись кэша не зависит от QTYPE. Ответ NODATA отличается:

Отрицательный ответ, полученный в результате ошибки отсутствия данных (NODATA), следует кэшировать, чтобы его можно было извлечь и вернуть в ответ на другой запрос для того же ‹QNAME, QTYPE, QCLASS›, который привел к кэшированному отрицательному ответу.

Здесь QTYPE (т.е. "AAAA") включен. Отрицательная запись в кэше NODATA означает только то, что данный конкретный тип записи для этого имени не существует.

Итак: если вы получаете ответ NXDOMAIN, вы знаете, что имя вообще не существует ни для какого типа записи. Если вы получили ответ NODATA, значит, вы знаете, что запрошенный тип записи не существует, но могут существовать другие типы записей.

Это также означает, что при отправке ответов вы не должны никогда отправлять ответ NXDOMAIN, если для того же имени может существовать допустимая запись другого типа записи. Несуществование доменного имени будет кэшироваться, и кэш начнет сообщать своим клиентам, что имя вообще не существует.

person Sander Steffann    schedule 07.04.2013
comment
RFC1536 также подчеркивает, что распознаватели должны прекратить запрашивать имя, когда сервер возвращает NXDOMAIN: сервер возвращает авторитетный NXDOMAIN, когда известно, что запрошенное имя неверно, [...] распознаватели должны распознавать, что имя, которое они запросили, было плохое имя и следует прекратить дальнейшие запросы. - person Sander Steffann; 08.04.2013