Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C436F12895E for ; Mon, 18 Sep 2017 19:48:32 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.com 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 ng3H1wkQEw7u for ; Mon, 18 Sep 2017 19:48:30 -0700 (PDT) Received: from mail-io0-x247.google.com (mail-io0-x247.google.com [IPv6:2607:f8b0:4001:c06::247]) (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 5620812426E for ; Mon, 18 Sep 2017 19:48:30 -0700 (PDT) Received: by mail-io0-x247.google.com with SMTP id k101so4906041iod.1 for ; Mon, 18 Sep 2017 19:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XdDlqSzP+mhVreazXW/7rjHcZP35SuvgYuZRAtVLEQs=; b=Nzx4MNm3T2PtWFTi2Zf4LdGPaVhIEKFqDHGq6jmcUdlkcwuZwX6ilVqBbaXuGv/T4f Xi9k1zBBoBXwBn4MqOXxdCW3WanylPkgJIvOsN2LDkjL8LUEtHeXr2sO820bXF0ACxjz INYrdBw+xoH1VjjQAxOAyTiP98oZM3DOjjl8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XdDlqSzP+mhVreazXW/7rjHcZP35SuvgYuZRAtVLEQs=; b=WRiNIomPiQuMLr8apmBWzQx4/XhpUWoo6DKR7PyWrtAENW+mfRufJTgPiztG3xjeSD YOdHI/VVB6ZPRnSh09LUolSNt32HK6U59CaWXpIuaaZp4L49tS7p0aG5/IgX/zrzZ2LY vwkVmQfh90m6G9fZC36EXEzlQFIXqFE8k2trLTxcft3BUfkFMhtOQjiyQweuHG3GVLfv ir8ubWeGmw+lGXdN7TiAY4eQok0FKn2CK0y9GRkoQo1rihm+D2SpUgY0/n5NNev/4W8G VEpXKImYsEUcDNKIDvwWI5/caQedGP5/c0O5hEDWa/gRt3J4hGo7C2NK6Lszig9W4GoW OHJw== X-Gm-Message-State: AHPjjUgbAMS+a7aFhkN0soFXtNOQ9EPqyQJNf/2d67qfWpOjQrOtvZBO flmRYGeRiUDFyShkME39bbFQEezNtMJln6bBoI1aTyloZzM= X-Google-Smtp-Source: AOwi7QB7aMUAQcLLadMRWE02lxvZD4WO603K1dEcrt6AFHIy/znUVSQ0/u00tLlU/J0NYDDRKdyR9wjhPEJf8t/IHBQ= X-Received: by 10.107.20.14 with SMTP id 14mr21671686iou.69.1505789302849; Mon, 18 Sep 2017 19:48:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.133.7 with HTTP; Mon, 18 Sep 2017 19:48:02 -0700 (PDT) In-Reply-To: <150570474802.613.6489161595724212264@ietfa.amsl.com> References: <150570474802.613.6489161595724212264@ietfa.amsl.com> From: Richard Gibson Date: Mon, 18 Sep 2017 22:48:02 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a114fcaa080dcaf055981e431" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 02:48:33 -0000 --001a114fcaa080dcaf055981e431 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have some questions about this draft. How should responders populate the COUNT fields when one record answers multiple accompanying questions? For example, assume example.com has an MX record but no A or AAAA (the latter two thus being covered by an authority section SOA): QUESTION example.com. IN MX AQ example.com. IN A AQ example.com. IN AAAA ANSWER example.com. 3600 IN MX 10 mail.example.net. AUTHORITY example.com. 3600 IN SOA =E2=80=A6 ADDITIONAL . 0 CLASS4096 OPT ??? In a more general sense, how are responders to generate=E2=80=94and how are initiators to interpret=E2=80=94responses in which it is not clear which qu= estion any given response record corresponds to? Section 3 defines the prefix field of an accompanying question as "a domain name with the form of a dot or a sequence of labels ending with a pointer"... could you clarify that "the form of a dot" refers to the root domain name (i.e., a single null label with wire format 0x00)? In section 4, what is meant by "the responder assembles the prefix with the main domain name"? Wire-format domain names are necessarily fully-qualified, whether or not they end with compression pointers. Is the operation to be interpreted as something like "if the prefix is the DNS root domain, treat it as the QNAME"? If so, I think such special processing is unnecessary, because it's already possible to reference the QNAME directly with a compression pointer. Why require accompanying question names to match or be subdomains of the QNAME? It precludes potentially useful queries like QNAME=3Dwww.example.com= . accompanied by prefix=3Dstatic.example.com., and prohibiting them doesn't prevent out-of-bailiwick queries anyway. Section 5 references a "not been implemented, too many accompanying-questions." response... what would that response look like? On Sun, Sep 17, 2017 at 11:19 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : A DNS Query including A Main Question with > Accompanying Questions > Authors : Jiankang Yao > Paul Vixie > Ning Kong > Xiaodong Li > Filename : draft-yao-dnsop-accompanying-questions-04.txt > Pages : 11 > Date : 2017-09-17 > > Abstract: > This document enables DNS initiators to send a main question > accompanying with several related questions in a single DNS query, > and enables DNS responders to put the answers into a single DNS > response. This extension enables a range of initiators to look up > "X, or failing that, Y" in a better way than both current > alternatives. This mechanism can reduce the number of DNS round- > trips per application work-unit. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-04 > https://datatracker.ietf.org/doc/html/draft-yao-dnsop- > accompanying-questions-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-yao-dnsop- > accompanying-questions-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114fcaa080dcaf055981e431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have some questions about this draft.

How should responders populate the COUNT fields when one record answers mu= ltiple accompanying questions? For example, assume example.com has an MX record but no A or AAAA (the latter two th= us being covered by an authority section SOA):
QUESTION example.com. IN MX
AQ example.com. IN A
AQ example.com. IN AAAA

example.com. 3600 IN MX 10= mail.example.net.
AUT= HORITY example.com. 3600 IN SOA =E2=80= =A6
ADDITIONAL . 0 CLASS4096 OPT ???

In a more general sense, how are responders to generate= =E2=80=94and how are initiators to interpret=E2=80=94responses in which it = is not clear which question any given response record corresponds to?
=

Section 3 defines the prefix field of an accompanying q= uestion as "a domain name with the form of a dot or a sequence of labe= ls ending with a pointer"... could you clarify that "the form of = a dot" refers to the root domain name (i.e., a single null label with = wire format 0x00)?

In section 4, what is meant by = "the responder assembles the prefix with the main domain name"? W= ire-format domain names are necessarily fully-qualified, whether or not the= y end with compression pointers. Is the operation to be interpreted as some= thing like "if the prefix is the DNS root domain, treat it as the QNAM= E"? If so, I think such special processing is unnecessary, because it&= #39;s already possible to reference the QNAME directly with a compression p= ointer.

Why require accompanying question names to= match or be subdomains of the QNAME? It precludes potentially useful queri= es like QNAME=3Dwww.example.com. acc= ompanied by prefix=3Dstatic.example.c= om., and prohibiting them doesn't prevent out-of-bailiwick queries = anyway.

Section 5 references a=C2=A0"not been= implemented, too many accompanying-questions." response... what would= that response look like?


On Sun, Sep 17, 2017 at 11:19 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A DNS Query including A Main Question with Accompanying Questions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jian= kang Yao
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Vixie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ning Kong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Xiaodong Li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-yao= -dnsop-accompanying-questions-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-17

Abstract:
=C2=A0 =C2=A0This document enables DNS initiators to send a main question =C2=A0 =C2=A0accompanying with several related questions in a single DNS qu= ery,
=C2=A0 =C2=A0and enables DNS responders to put the answers into a single DN= S
=C2=A0 =C2=A0response.=C2=A0 This extension enables a range of initiators t= o look up
=C2=A0 =C2=A0"X, or failing that, Y" in a better way than both cu= rrent
=C2=A0 =C2=A0alternatives.=C2=A0 This mechanism can reduce the number of DN= S round-
=C2=A0 =C2=A0trips per application work-unit.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-yao-dnsop-accompanying-questions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-04
https://datatracker.i= etf.org/doc/html/draft-yao-dnsop-accompanying-questions-04
A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-yao-dnsop-accompanying-questions-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a114fcaa080dcaf055981e431--