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

[Richard Gibson <[e-mail]>]

On Wed, Sep 20, 2017 at 3:45 AM, Jiankang Yao <[e-mail]> wrote:

> *From:* Richard Gibson <[e-mail]>
> *Date:* 2017-09-19 10:48
> *To:* dnsop <[e-mail]>
> *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.