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
