Subject: ANY queries in ns resolution: ADDR pseudo-rrtype for IPv4 and IPv6 operation

From: bert hubert <[email-masked]>
Date: Sun, 10 Feb 2008 22:18:18 +0100

Hi everybody,

I'm having some fun seeing how much of the internet I can resolve on IPv6
only. Since both the root-servers and the .nl servers are now reachable over
IPv6, this set is not entirely empty.

In fact, there is one host that can ONLY be resolved over IPv6:
www.nl.ipv6.net.        172800  IN      AAAA    2001:888:1037::8080
although it may require some IPv4 in between.

When fixing the issues this and other domains exposed in PowerDNS, I decided
to do something different. When trying to find nameserver addresses, I now
internally use an 'ADDR' query, which gets translated into an ANY query.

The answers that come in are then filtered to only contain A and AAAA
records. The internal cache also supports ADDR queries as 'A|AAAA'.

Now, from my limited testing, this appear to work! That is, the ANY query
does not appear to be any less functional than an A query.

It is well known that 'rd' ANY queries are useless (or at best a debugging
aid), but non-rd ANY queries appear to do the job.

I only turn on the AAAA queries for users that have explicitly chosen they
want to use outgoing IPv6 queries for their resolution needs, so the
immediate impact on PowerDNS operators would be limited.

But still, I wonder if what I'm doing is technically legal, or conversely,
if there are standards complying ways for this not to work.

http://ds9a.nl/tmp/nl-ipv6-resolve shows a trace using the 'ADDR'
pseudo-query, or download
http://svn.powerdns.com/snapshots/pdns-recursor-3.1.5-snapshot4.tar.bz2
(do read the README to compile)

And execute:
$ ./pdns_recursor --local-port=5300 --daemon=no --socket-dir=./ --daemon=no
  --trace --hint-file=named.root --query-local-address6=::

For the largest amount of fun, remove all A records from the named.root

And please let me know if you think this can never work, or if you think it
should work, but won't.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Feb 2008 09:17:26 +1100

Just somethings to be aware of.

	A ANY response can be >= 64K whereas the individual A and
	AAAA queries are each less than 64K.

	A ANY query is much more likely to trigger TCP fallback.

	A ANY query will not trigger code paths which moves glue
	which matches the query to the start of the additional
	section.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Feb 2008 22:48:37 +0000

is it too late to say that appropriate additional data for an AAAA response
includes A, and that appropriate additional data for an A response include
AAAA?

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Feb 2008 10:55:33 +1100

> includes A, and that appropriate additional data for an A response include

	It's never too late.  You just can't depend on it.

	What is really wanted is one query.  AAAA can carry A.  Just
	make the nameservers/signers etc map A's into AAAA.  Set a
	end-of-transition date and after that date never make A
	queries again, FORMERR them.

	Actually we need a extend version of AAAA which carries zone
	information.  The global zone is ".".  Sites and links get to
	choose the zone name using names already allocated to them.

	e.g.

        drugs.dv.isc.org. <TBA> fe80::214:22ff:fed9:fbdc link1.dv.isc.org.
        drugs.dv.isc.org. <TBA> fd92:7065:b8e:0:214:22ff:fed9:fbdc dv.isc.org.
        drugs.dv.isc.org. <TBA> 2001:470:1f00:820:214:22ff:fed9:fbdc .
        drugs.dv.isc.org. <TBA> ::ffff:192.168.191.236 dv.isc.org.

	getaddrinfo() would be configured to know that link1.dv.isc.org
	is scopeid 1 via DHCP or manually or a RA and that dv.isc.org
	is local, again via DHCP or manually or a RA and would filter
	by default.

	Mark

---

From: bert hubert <[email-masked]>
Date: Mon, 11 Feb 2008 08:09:29 +0100

> includes A, and that appropriate additional data for an A response include

That was our previous mode of operation ('hope') but it did not get very far
on the internet.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: 11 Feb 2008 13:25:07 +0000

> > is it too late to say that appropriate additional data for an AAAA
> > response includes A, and that appropriate additional data for an A
> > response include AAAA?
> 
> That was our previous mode of operation ('hope') but it did not get very
> far on the internet.

hope, plus three dollars and a quarter, gets you a starbucks latte.  but
rough consensus and running code, well, now that's another matter entirely.

as server implementors, we could just start including AAAA RRs in the
additional data section when answering with A RRs, and including A RRs in
the additional data section when answering with AAAA RRs.  more or less
like what we do with NS and MX.  i suggested this, half heartedly, when RFC
1886 was in production, but i was new to the IETF and i didn't know that i
had to say it louder if i wanted the idea to be considered.  but if a bunch
of us just started *doing* it, it would not be a protocol violation nor
create interoperability problems, and if it works well, we can always write
a BCP about it.

here's the one line change it took to get this working in my private label
non-BIND recursive nameserver:

	Index: dns_request.c
	===================================================================
	RCS file: /home/vixie/src/cvsroot/base/robodns/dns_request.c,v
	retrieving revision 1.72
	diff -u -r1.72 dns_request.c
	--- dns_request.c       21 Jun 2007 14:17:17 -0000      1.72
	+++ dns_request.c       11 Feb 2008 13:19:43 -0000
	@@ -1143,6 +1143,8 @@
	        }
	        dns_rrset_lastrdata(&rdi);
	        dns_rrset_lrumark(rrset);
	+       if (adddom != NULL && (type == ns_t_a || type == ns_t_aaaa))
	+               dns_adddom(adddom, nadddom, nname, class, dc, now);
	        return (ret);
	 }

and here's what it looks like on the wire:

	; <<>> DiG 9.4.1 <<>> @::1 www.isc.org in aaaa
	; (1 server found)
	;; global options:  printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24902
	;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
	
	;; QUESTION SECTION:
	;www.isc.org.                   IN      AAAA
	
	;; ANSWER SECTION:
	www.isc.org.            600     IN      AAAA    2001:4f8:0:2::d
	
	;; ADDITIONAL SECTION:
	www.isc.org.            594     IN      A       204.152.184.88
	
	;; Query time: 185 msec
	;; SERVER: ::1#53(::1)
	;; WHEN: Mon Feb 11 13:18:30 2008
	;; MSG SIZE  rcvd: 73

"so, tonight's the night, i'm breaking outta this joint, who's with me?"
-- 
Paul Vixie

---

From: "Blacka, David" <[email-masked]>
Date: Tue, 12 Feb 2008 08:46:37 -0500

> create interoperability problems, and if it works well, we can  

So, what use is this extra additional section rrset?  Wouldn't RFC  
2181 rules (and general resolver paranoia) keep this A or AAAA from  
ever being used as an answer?
--
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2008 16:15:44 +0000

[davidb]
> So, what use is this extra additional section rrset?  Wouldn't RFC  2181
> rules (and general resolver paranoia) keep this A or AAAA from  ever being
> used as an answer?

in my own implementation, i upgrade additional records if they come from the
same server i would have queried for them.  i assume that others do likewise,
and that RFC 2181 is overly conservative on this one point.

however, their availability to stub resolvers (to which RFC 2181 does not
apply) is the important part.  getaddrinfo() with ai_family == PF_UNSPEC,
for example.

also, their availability in a recursive server (at the "additional data"
credibility level) for other responses (MX, NS, SRV) would moot the question,
if i have one kind of cached address record for the target, but no evidence
for/against the existence of the other kind of record, should i query for the
other kind so that my additional data can be more complete?

and it would moot the question, if you're trying to reach a name server and
you have one kind of address record for it but no evidence for or against the
existence of the other kind of record, and you can't reach it using the kind
of address you have, should you query for the kind you don't have before
giving up?

so even without patching RFC 2181 or testing getaddrinfo(), i see two 
immediate benefits from this change in behaviour, which as i said violates
no specification of which i am aware.