Clients get DNS timeouts because ipv6 means more queries for each lookup

Tue Jul 12 02:35:18 UTC 2011

Wikipedia have been told multiple times that their nameservers are
broken, that they fail to add the CNAME records, as required by RFC
1034, which results in garbage answers being returned.  Those garbage
answers result in the FORMERR log messages.

Both of the answers below should have CNAME chains in them but only
the A query has them.

Now luckily this doesn't affect every AAAA lookup as the CNAME
records returned from the A lookup are cached, so every hour the
recursive nameserver needs to go through this dance.  Asking for A
before AAAA just hides the problem by priming the cache.

Mark

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23606
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;en.wikipedia.org.		IN	A

;; ANSWER SECTION:
en.wikipedia.org.	3600	IN	CNAME	text.wikimedia.org.
text.wikimedia.org.	600	IN	CNAME	text.pmtpa.wikimedia.org.
text.pmtpa.wikimedia.org. 3600	IN	A	208.80.152.2

;; Query time: 411 msec
;; SERVER: 91.198.174.4#53(ns2.wikimedia.org)
;; WHEN: Tue Jul 12 12:02:06 2011

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23260
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;en.wikipedia.org.		IN	AAAA

;; AUTHORITY SECTION:
wikimedia.org.		86400	IN	SOA	ns0.wikimedia.org. hostmaster.wikimedia.org. 2011071119 43200 7200 1209600 600

;; Query time: 306 msec
;; SERVER: 208.80.152.142#53(ns1.wikimedia.org)
;; WHEN: Tue Jul 12 12:00:58 2011
;; MSG SIZE  rcvd: 108

In message <4E1B9222.8090609 at dougbarton.us>, Doug Barton writes:
> On 07/11/2011 11:11, Jonathan Kamens wrote:
> > The number of DNS queries required for each address lookup requested by
> > a client has gone up considerably because of IPV6. The problem is being
> > exacerbated by the fact that many DNS servers on the net don't yet
> > support IPV6 queries.
> 
> I have to disagree with your premise here. It's true that DNS software
> has a notoriously long deprecation cycle, but AAAA records have been
> around for long enough that it's highly unlikely there are enough name
> servers that don't handle them to make a noticeable difference. And even
> if you can find one, it should be upgraded for a vast array of other
> reasons.
> 
> > The result is that address lookups are frequently
> > taking so long that the client gives up before getting the result.
> 
> It sounds to me like you don't have IPv6 connectivity. If so, you've
> already been given the advice to configure your OS to avoid asking for
> AAAA at all, or at least to ask for A first. Heed this advice.
> 
> > The example I am seeing this with most frequently is my RSS feed reader,
> > rss2email, trying to read a feed from en.wikipedia.org in a cron job
> > that runs every 15 minutes. I am regularly seeing this in the output of
> > the cron job:
> > 
> >     W: Name or service not known [8]
> >     http://en.wikipedia.org/w/index.php?title=/[elided]/&feed=atom&action=h
> istory
> > 
> > The wikipedia.org domain has three DNS servers. Let's assume that the
> > root and org. nameservers are cached already when rss2email does its
> > query. If so, then it has to do the following queries:
> > 
> >     wikipedia.org DNS
> >     en.wikipedia.org AAAA
> >     en.wikipedia.org A
> > 
> > This is fine when the wikipedia.org nameservers are working, but let's
> > postulate for the moment that two of them are down, unreachable, or
> > responding slowly, which apparently happens pretty often. Then we end up
> > doing:
> > 
> >     wikipedia.org DNS
> >     en.wikipedia.org AAAA /times out
> >     /en.wikipedia.org AAAA /times out
> >     /en.wikipedia.org AAAA
> >     en.wikipedia.org A /times out/
> >     en.wikipedia.org A /times out
> >     /en.wikipedia.org A
> > 
> > By now the end of that sequence, the typical 30-second DNS request
> > timeout has been exceeded, and the client gives up.
> 
> See above. YOU need to configure your software to not ask for AAAA, or
> to ask for A first.
> 
> > I said above that the problem is exacerbated by the fact that many DNS
> > servers don't yet support IPV6 queries. This is because the AAAA queries
> > don't get NXDOMAIN responses, which would be cached, but rather FORMERR
> > responses, which are not cached. As a result, the scenario describes
> > above happens much more frequently because the DNS server has to redo
> > the AAAA queries often.
> 
> Can you provide examples of specific name servers, on the network now,
> that respond this way? The authoritative name servers for wikipedia.org
> respond correctly (NOERROR/ANSWER=0) to AAAA queries for
> en.wikipedia.org. If you are seeing a FORMERR response to these queries
> the problem lies somewhere in your resolution chain.
> 
> Before taking mitigating steps in correctly functioning software is
> considered there needs to be substantial evidence that there are enough
> really really old name servers that behave the way you describe still on
> line to make the effort worthwhile.
> 
> 
> hth,
> 
> Doug
> 
> -- 
> 
> 	Nothin' ever doesn't change, but nothin' changes much.
> 			-- OK Go
> 
> 	Breadth of IT experience, and depth of knowledge in the DNS.
> 	Yours for the right price.  :)  http://SupersetSolutions.com/
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org