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

Shumon Huque <shuque@gmail.com> Mon, 09 March 2015 20:17 UTC

Return-Path: <shuque@gmail.com>
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 6719B1AC3E7 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 13:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 dOdZqgS0h-Jc for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 13:17:57 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CE41AC44B for <dnsop@ietf.org>; Mon, 9 Mar 2015 13:17:54 -0700 (PDT)
Received: by qgdz107 with SMTP id z107so31513053qgd.3 for <dnsop@ietf.org>; Mon, 09 Mar 2015 13:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Vkr8JocljbwcBSfWcWr1rUg9vvpfLY/0dqSQQKBr7D4=; b=v0/H2rQsvc5xOoVurBqReRjLrMUJpHKeR3VgWBSESdsK5g7YoWzy2DD0s9zlBHSvc8 i7le9ohJJZIchnTqZb7InBE+bWcF6pBD2cIqAdoa2xd9j99IMHcNAR39kzu2xu+gmfG/ KWt/6icfaduPMuO2tH9DiRHPOKud+lzZ2fXMSjNfsDI4geiLbpBxVqszmMPKmssXQj7j jMmXoqbV3u4F3bMp9ft6GBkH5y7ixGHGPgugDScxmctasC+Gxjwvwk3VF6ouRIrL4BfZ LZ6IOKmWK2IxzhRHtwnNHmEZyfv6pVgyFOf31jZO/UuofUQyeTUm/n5gSP3JpJf8eyUf 23xw==
MIME-Version: 1.0
X-Received: by 10.140.38.197 with SMTP id t63mr36100785qgt.61.1425932273751; Mon, 09 Mar 2015 13:17:53 -0700 (PDT)
Received: by 10.140.94.105 with HTTP; Mon, 9 Mar 2015 13:17:53 -0700 (PDT)
In-Reply-To: <CAHPuVdXt2qFre9d8pW6KD9etbyFfAMgnycT_k4J9yNxCvoE_sw@mail.gmail.com>
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>
Date: Mon, 9 Mar 2015 16:17:53 -0400
Message-ID: <CAHPuVdVzwcV48JMhRv0cxwRZFLiQnE6BrJrbVpn2yJExDGOCRA@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
To: Robert Edmonds <edmonds@mycre.ws>
Content-Type: multipart/alternative; boundary=001a11c12986a69e4d0510e0ba3b
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/S3hTztrrpURyCiY4y3rq6mLj75U>
Cc: dnsop <dnsop@ietf.org>
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
Reply-To: shuque@gmail.com
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: Mon, 09 Mar 2015 20:17:59 -0000

On Mon, Mar 9, 2015 at 2:55 PM, Shumon Huque <shuque@gmail.com> wrote:

> On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds <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 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.            IN    A

;; ANSWER SECTION:
getdnsapi.net.        450    IN    A    185.49.141.37

;; AUTHORITY SECTION:
getdnsapi.net.        450    IN    NS    getdnsapi.net.
getdnsapi.net.        450    IN    NS    mcvax.nlnet.nl.
getdnsapi.net.        450    IN    NS    dicht.nlnetlabs.nl.

;; ADDITIONAL SECTION:
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.

Shumon Huque