Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Shumon,

On 09/03/15 21:17, Shumon Huque wrote:
> On Mon, Mar 9, 2015 at 2:55 PM, Shumon Huque <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> Shumon Huque wrote:
>> PS. regarding Paul Vixie's recent suggestion of adding an AAAA or
>> A record set in the additional section for a corresponding A or
>> AAAA query, I just learned today that Unbound already does this.
>> Not sure if there are any DNS client APIs that can successfully
>> make use of this info yet.
> 
> Hi, Shumon:
> 
> Do you mean that Unbound will accept such answers from servers, or
> that it will send such answers to clients, or both?
> 
> 
> This was from a transcript of a 'dig' session to an unbound
> resolver - so this is unbound sending responses back to clients.
> I'm not sure if it accepts such answers from queries to authority
> servers, nor do I know if there are any authority servers that
> return such responses.
> 
> 
> I just tried querying an Unbound 1.5.2 server for a cached, signed
> pair of A/AAAA records and I don't believe Unbound sends such
> answers to clients, at least not by default.
> 
> 
> Hmm, let me double check the details of the configuration and get 
> back to you. From the discussion with the colleagues that are 
> running this server, it sounded like it was the default, but
> perhaps some configuration knob needs to be tweaked.
> 
> 
> Upon closer inspection, it looks like I was mistaken. I was misled
> by the following output which coincidentally looks like gratuitous
> AAAA in the additional section:
> 
> $ dig @N.N.N.N getdnsapi.net <http://getdnsapi.net> A +ignore 
> +sit='b1c18d3e4328485cfe63a64b54fdf6a106f0e2e550919fa3'
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52975 ;; flags:
> qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
> 
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; SIT:
> b1c18d3e4328485c43b55e7954fdfd02f2cd44ce05415c15 (good) ;; QUESTION
> SECTION: ;getdnsapi.net <http://getdnsapi.net>.            IN    A
> 
> ;; ANSWER SECTION: getdnsapi.net <http://getdnsapi.net>.        450
> IN    A    185.49.141.37
> 
> ;; AUTHORITY SECTION: getdnsapi.net <http://getdnsapi.net>.
> 450    IN    NS getdnsapi.net <http://getdnsapi.net>. getdnsapi.net
> <http://getdnsapi.net>.        450    IN    NS mcvax.nlnet.nl
> <http://mcvax.nlnet.nl>. getdnsapi.net <http://getdnsapi.net>.
> 450    IN    NS dicht.nlnetlabs.nl <http://dicht.nlnetlabs.nl>.
> 
> ;; ADDITIONAL SECTION: getdnsapi.net <http://getdnsapi.net>.
> 450    IN    AAAA 2a04:b900:0:100::37
> 
> When in fact it's probably just unbound helpfully adding an AAAA 
> corresponding to one of the NS names in the authority section. The 
> resolver (actually identity masked) is at NLNetlabs (the unbound
> folks), so I was thinking this might possibly be some special code
> or configuration in one of their servers, but the actual
> explanation seems to be more benign.

Unbound varies its answers depending on what the authority server is
doing.  If the authority server inserts such an A or AAAA record in
the additional section, unbound has code for this case (an AAAA
inserted for an A query, or an A inserted for an AAAA query).

Only for the name that is queried, this to stop poisoning, and this is
why the code is there (it is a (happy?) side-effect of anti-poison code).

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU/tePAAoJEJ9vHC1+BF+NWXAP/1f6+vrg+GsjANkGoHcNhP0a
Fgrwq9GV9HooDM9SuXTuQd+rGyELLMwju+MWevc3GZYOZqRpkz+kvINR3vtWDemL
2H/+/MH5cDuIRe+LfBwy4qQc5XI4Kfbv+0Yw9Tm8qxy3EckO5US7jRMMNugTpRX8
s31t4DF5q8Qd6j5l1KPR8XKttLmp+xE6V3v1DFbJ9Jg1rCjgiFm6Mn1WGdiajc0l
njiodsYM4HMRaC50mEHjy8JWJHP+WDGoSqehEJZVMWNRU7W7m9ZXrJPdTkGQYEni
GzLraAXSCTbBt/P16UdUZHvPY8jvFk3oe2/igTLf7rUcagbS88XTyUmmwqMeYQav
JsccQ5gUsDMpyxWQuECNJygXmrKLwY6faLbNhraP5yLlhdFET4MJbc7WPkW75nJP
dWbv1mNl0dd53V4Bm3JKC6xX2naMi8ygAxNgPxN9iHLydu45+FF6oK5tdbOX2TOf
lMt41dXWRODUVcY3INIhNbmS3cA5YB8weDwvxoUYtsQQ7WtSrLvYXiLGsOGOg/n0
a5SESFxGTDki6iu3cNfq4DXEUtmr+n9GBnQXyP1wkIpyZH9bmFq9QYMnhppR3iLB
3jrzGF3BEcsJFB8i8kjMvtqOux/xgjKHH6Q+fnoTa29TJQtYgvdxuqI1sEhCdihW
x9mB+Q5/1oN0s+CNqC5r
=tfxm
-----END PGP SIGNATURE-----