0

We use RH5.8 with ipv6 disabled.

named(bind) service is in forward mode (cache enabled)

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

It appears that some commands (like telnet) always query AAAA record in the first place and when fallback to query A record the answer (No such name) already in named caching.

As a result, clients are always getting an error.

in the example below, 10.10.10.1 is a local 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

I searched over net and discovered that not only me encountered with such problem 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

but unfortunately did not find any solution so far...

Gregory Danenberg
  • 519
  • 2
  • 9
  • 15
  • 1
    Yes: the system always looks up IPv6 AAAA records first. That is normal, and should not cause any problems for applications. They don't get an AAAA records, they get only an A records, and they connect over IPv4. – Sander Steffann Apr 07 '13 at 12:27
  • For some cases it does a problem, since named caching "No such name" response for AAAA record, and does not query A record from DNS. – Gregory Danenberg Apr 07 '13 at 12:38
  • 4
    Then either the authoritative or forwarding DNS server is broken (it must not give a No-Such-Name response if the name does exist, even if the requested record type doesn't exist) or there really is no A record, in which case the behaviour is correct. In your case it seems to be the first one, so the person who runs that DNS server should get some extra clue... They are making their service unavailable to larger and larger parts of the internet. – Sander Steffann Apr 07 '13 at 14:06
  • Thanks a lot, the first one is true in my case. Could you please refer me to relevant RFC or another doc, so I'll be able to argue with IT guys? – Gregory Danenberg Apr 07 '13 at 15:35
  • 1
    The relevant RFC is 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses" – bortzmeyer Apr 14 '13 at 15:32

1 Answers1

1

As requested in the comments: some explanation on negative cacheing.

The difference between NXDOMAIN and NODATA is described in section 5 of RFC 2308:

A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response.

So an NXDOMAIN can be cached based on the QNAME (i.e. "blabla.example.com.") and the QCLASS (usually "IN"). So it means that blabla.example.com does not exist at all. The negative cache entry is independent of the QTYPE. A NODATA answer is different:

A negative answer that resulted from a no data error (NODATA) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QTYPE, QCLASS> that resulted in the cached negative response.

Here is QTYPE (i.e. "AAAA") is included. A NODATA negative cache entry only means that this specific record type does not exist for this name.

So: If you receive an NXDOMAIN response then you know that the name doesn't exist at all for any record type. If you receive a NODATA response then you know that the requested record type does not exist, but other record types may exist.

This also means that when sending responses you should never send an NXDOMAIN response if there may be a valid record of a different record type for the same name. The non-existence of the domain name will be cached and the cache will start telling its clients that the name doesn't exist at all.

Sander Steffann
  • 9,509
  • 35
  • 40
  • RFC1536 also highlights that resolvers should stop querying for a name when the server returns an NXDOMAIN: A server returns an authoritative NXDOMAIN when the queried name is known to be bad, [...] Resolvers should recognize that the name they queried for was a bad name and should stop querying further. – Sander Steffann Apr 07 '13 at 22:07