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

"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Tue, 10 March 2015 11:38 UTC

Return-Path: <wouter@nlnetlabs.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B211F1A8799 for <dnsop@ietfa.amsl.com>; Tue, 10 Mar 2015 04:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.084
X-Spam-Level:
X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwyVMky645qN for <dnsop@ietfa.amsl.com>; Tue, 10 Mar 2015 04:37:58 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E60F1A8769 for <dnsop@ietf.org>; Tue, 10 Mar 2015 04:37:58 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 5C0352A4E; Tue, 10 Mar 2015 12:37:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1425987476; bh=QxzvWYxuGhBH+BQqfENTBKhV1N1/rpI3bYtNfCAWp+s=; h=Date:From:To:Subject:References:In-Reply-To; b=HB6cvoU9CAj8ZdUvc6WBRPYV0D8Ca4zo4HprZ4wrptRfANYHsZ9puuC+00p27tVFh DCHjmxIn4kksCVijfeZ4z1MX4pyk5y/MpLVyzxLMGhdFTe9bfzkOn69iic8d1ztnjT f534/9mrVa76QadWoprHro/O9fOv5vxtIN9Ybm8U=
Received: from axiom.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:222:4dff:fe55:4d46]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4ACFE2A4C for <dnsop@ietf.org>; Tue, 10 Mar 2015 12:37:51 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1425987471; bh=QxzvWYxuGhBH+BQqfENTBKhV1N1/rpI3bYtNfCAWp+s=; h=Date:From:To:Subject:References:In-Reply-To; b=YxutVlCKGPuTWQ43r6XNDpukWD01InPgV0xSOPIKTPjPxX+fYZ7I30Bj+/7f3dXqY b64RLcK3KXmJ0MU5GEkJYSeUA+ZiEkz+8mniVEVTESEnmuhzhvIiH60qiXteTVVBeN 9WsE/2R++16wDmYXrrT63fDy1VJSd7VuT5jiOjns=
Message-ID: <54FED78F.8060501@nlnetlabs.nl>
Date: Tue, 10 Mar 2015 12:37:51 +0100
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20150306145217.GA8959@nic.fr> <54F9C29E.9040408@jive.com> <54F9F90D.1020806@redbarn.org> <54F9FCD3.7010204@jive.com> <54F9FDFA.2030405@redbarn.org> <F25411A6-2CBD-4A76-949C-6E236FA87863@isoc.org> <20150306205920.GA17567@isc.org> <20150309142844.GA11602@nic.fr> <C1F43BD2-126F-4C1D-B084-A4B3A1F98ECD@nominet.org.uk> <CAHPuVdUyQWnRkvRhukHyCzZspUbj9iREyXSLmXTwmOy1m8DBTQ@mail.gmail.com> <20150309184507.GA7524@mycre.ws> <CAHPuVdXt2qFre9d8pW6KD9etbyFfAMgnycT_k4J9yNxCvoE_sw@mail.gmail.com> <CAHPuVdVzwcV48JMhRv0cxwRZFLiQnE6BrJrbVpn2yJExDGOCRA@mail.gmail.com>
In-Reply-To: <CAHPuVdVzwcV48JMhRv0cxwRZFLiQnE6BrJrbVpn2yJExDGOCRA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/fP-5kRhLIvHJF1T2IRtH-kXyn4c>
Subject: Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 11:38:00 -0000

-----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 <shuque@gmail.com 
> <mailto:shuque@gmail.com>> wrote:
> 
> On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds <edmonds@mycre.ws 
> <mailto:edmonds@mycre.ws>> 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-----