[dns-operations] IPv6 & IPv4 addresses

Paul Vixie vixie at isc.org
Fri Mar 18 15:46:55 UTC 2011


> Date: Fri, 18 Mar 2011 09:57:12 +0000
> From: Simon Munton <Simon.Munton at communitydns.net>
> 
> > in EDNS1 (circa 1999) i had this defined as requiring all QNAMEs to be
> > the same (since RCODE refers to the QNAME alone not the full q-tuple)
> > but this was tossed out as "too many moving parts" or similar.
> 
> I'm sure you're right, Paul, seems a shame as (right now) I can't see the
> issues, where the QNAME is constant, plus the query packet size will only
> be very slightly bigger.

the problem, as with many things in DNS, is that BIND4 didn't do the right
thing.  if we wanted to establish QDCOUNT>1 we would have to negotiate it,
meaning every initiator who wanted to try it would have to have a fallback
path and would end up triggering that fallback path variously, depending on
exactly what kind of nonuseful answer they got (could be SERVFAIL, could be
that all QDCOUNT>0 is treated as QDCOUNT==1, could be FORMERR, could be the
silence of the timeout.)  when we decided to negotiate at all, we did it by
using ADCOUNT>0 in queries and putting OPT RR's in there.  it was the number
of round trips and the clarity of the fallback trigger that mattered, not
whether QDCOUNT>1 became expressible.

> Should also be better for the authority server as its gone to the trouble
> of pulling out the data for that name already, so supplying more than one
> RR would be less overhead than running the query again from scratch
> .... well it would on our system anyway!

the time taken to reference data in RAM is so many orders of magnitude
smaller than the time taken by even half of even one round trip even on
a LAN, that this kind of performance consideration never enters into it.
DNS is a distributed system and our first order performance concerns all
involve the speed of photons in fiber or the speed of electrons in copper.


More information about the dns-operations mailing list