Hi Petr, all, With reference to:
https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg > 1. The casse QTYPE=RRSIG should be made more prominent so it is > understood and not misused as ANY. There are implementations like Knot > Resolver which are work around missing RRSIG records in replies using > QTYPE=RRSIG. > > Personally I would rename the document from > Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY > to > Providing Minimal-Sized Responses to DNS Queries > that have QTYPE=ANY or QRTYPE=RRSIG > > ... and extend Abstract as well: > The Domain Name System (DNS) specifies a query type (QTYPE) > "ANY" or "RRSIG". The operator of an authoritative DNS server might > choose not torespond to such queries for reasons of local policy, > motivated by security, performance or other reasons. > > 2. Section Updates to RFC 1035 should use normative language, especially > regarding RRSIG. Proposal follows: > RRSIG queries have the same potential as ANY queries of generating > large answers as well as extra work. In the wild there are > implementations that return REFUSE, others return single RRSIG, etc. > It is RECOMMENDED returning a single RRSIG in this case. > > > 3. Text about necessity of fallback in applications trying to use ANY > query is burried under non-descriptive section name "Motivation". Given > the confusion is caused among application developers, I would like to > see it mentioned and explained again in section "Behaviour of DNS > Initiators". > I understand the points you're making, and I've read fanf's subsequent reaction to it (and your reaction to that). I don't have any objection to any of those suggestions, and I'm quite happy to come up with text for them in the next rev of the draft (thanks for your suggestions in 1 and 2). If anybody else here has thoughts about specific text or violent objections to including QTYPE=RRSIG in general, please let me know (I looked in the mail archive but couldn't find any there). The general approach I am picturing is one in which the issues for ANY and RRSIG are both described, but that implementors are free to address just one if they have particular circumstances that make that sensible. As we discuss (see Stephane's points) in the case of multiple transports, perhaps we can also recommend that implementors provide configuration options to allow administrators to deal with ANY, RRSIG, neither or both. That way we get flexibility that matches deployment, but we also get a reference for handling RRSIG in a predictable way. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
