Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

[Richard Gibson]

On Wed, Sep 20, 2017 at 3:45 AM, Jiankang Yao <ya...@cnnic.cn> wrote:

> *From:* Richard Gibson <rgib...@dyn.com>
> *Date:* 2017-09-19 10:48
> *To:* dnsop <dnsop@ietf.org>
> *Subject:* Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-
> questions-04.txt
> In a more general sense, how are responders to generate—and how are
> initiators to interpret—responses in which it is not clear which question
> any given response record corresponds to?
>
>
> *[Jiankang Yao]*
>The responders will put the query result of main question first,
> then Accompanying Question 1, Accompanying Question 2 in the answer,
> authority or additional section. It means that the responders will put the
> results for main question first, then Accompanying Question 1, Accompanying
> Question 2, one by one in order.
>
Ah, so the response is expected to include *duplicate* records when they
answer multiple questions (e.g., in the case of NXDOMAIN and NODATA
results)? That's worth making explicit (e.g., rewording "the SOA resource
record will be put in the authority section" in section 4). And I believe
it also calls for guidance instructing responders to reject question sets
that include duplicates or special QTYPES (AXFR/IXFR/ANY), including a
description of *how* to reject (e.g., AQ-RCODE=REFUSED).

> Why require accompanying question names to match or be subdomains of the
> QNAME? It precludes potentially useful queries like QNAME=www.example.com.
> accompanied by prefix=static.example.com., and prohibiting them doesn't
> prevent out-of-bailiwick queries anyway.
> *[Jiankang Yao]*
> currently the use cases for accompanying questions are the same domain
> names with different typs (A and AAA) or different sub domain names (TLSA
> record: _443._tcp.www.example.com  ).
>
> If we can find some strong use cases for  queries like QNAME=
> www.example.com. accompanied by prefix=static.example.com, we may
> consider to adjust the design.
>
 I don't think you need to adjust the design, just strike "The domain name
for accompanying questions MUST be same with the domain name for a main
question or be children name of it" from section 3.

Your response did get me thinking about name compression, though. RFC 3597
section 4 <https://tools.ietf.org/html/rfc3597#section-4> states "Future
specifications for new RR types that contain domain names within their
RDATA MUST NOT allow the use of name compression for those names", and I
don't think that should be tossed aside lightly. If they truly are to be
allowed in EDNS0 options (which may already be a mistake), I think that
they MUST be required to point into the first QNAME of the message.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

[Jiankang Yao]

Dear Richard Gibson,

 Thanks a lot for your kind review and questions.

 some comments are below inline.




Jiankang Yao

From: Richard Gibson
Date: 2017-09-19 10:48
To: dnsop
Subject: Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt
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  (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 


ANSWER example.com. 3600 IN MX 10 mail.example.net.
AUTHORITY example.com. 3600 IN SOA …
example.com. 3600 IN SOA … 
ADDITIONAL . 0 CLASS4096 OPT ???


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

 
[Jiankang Yao] 
   The responders will put the query result of main question first, then 
Accompanying Question 1, Accompanying Question 2 in the answer, authority or 
additional section. It means that the responders will put the results for main 
question first, then Accompanying Question 1, Accompanying Question 2, one by 
one in order.

   The  initiators will also interpret the result in the answer, authority or 
additional section, one question by one question in order, main question first, 
then Accompanying Question 1, Accompanying Question 2. The interpretation will 
base on the value of 
ANCOUNT, ARCOUNT, NSCOUNT, and AQ-ANCOUNT, AQ-ARCOUNT, AQ-NSCOUNT.

In your example above,  
ANCOUNT=1, ARCOUNT=1, NSCOUNT=0;
AQ1-ANCOUNT=0,   AQ1-ARCOUNT=0, AQ1-NSCOUNT=1;
AQ2-ANCOUNT=0, AQ2-ARCOUNT=0, AQ1-NSCOUNT=1

so the initiators will know:
the result for main question is: 

 ANSWER example.com. 3600 IN MX 10 mail.example.net.
 AUTHORITY 
ADDITIONAL . 0 CLASS4096 OPT ???

the result for accompanying question 1 is: 

 ANSWER 
AUTHORITY example.com. 3600 IN SOA …
ADDITIONAL 

the result for accompanying question 2 is: 

   ANSWER 
   AUTHORITY example.com. 3600 IN SOA …
   ADDITIONAL 

 




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)?
[Jiankang Yao] 
sorry for confusion words. it means  a single null label .


 

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.
[Jiankang Yao] 
thanks, You are right. I will clarify the words.

 

Why require accompanying question names to match or be subdomains of the QNAME? 
It precludes potentially useful queries like QNAME=www.example.com. accompanied 
by prefix=static.example.com., and prohibiting them doesn't prevent 
out-of-bailiwick queries anyway.
[Jiankang Yao] 
currently the use cases for accompanying questions are the same domain names 
with different typs (A and AAA) or different sub domain names (TLSA record: 
_443._tcp.www.example.com  ).

If we can find some strong use cases for  queries like QNAME=www.example.com. 
accompanied by prefix=static.example.com, we may consider to adjust the design.

 


Section 5 references a "not been implemented, too many accompanying-questions." 
response... what would that response look like?
[Jiankang Yao] 
Here, I think that it need a new rcode value for it.



Best Regards.
Jiankang Yao
 




On Sun, Sep 17, 2017 at 11:19 PM, <internet-dra...@ietf.org> 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 cur

Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

[Richard Gibson]

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  (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 

ANSWER example.com. 3600 IN MX 10 mail.example.net.

AUTHORITY example.com. 3600 IN SOA …

ADDITIONAL . 0 CLASS4096 OPT ???


In a more general sense, how are responders to generate—and how are
initiators to interpret—responses in which it is not clear which question
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=www.example.com.
accompanied by prefix=static.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=draft-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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop