I have a strong objection to this document. In the introduction is it said:
"The DNS specification [RFC1034] [RFC1035] does not include specific guidance for the behaviour of DNS servers or clients in this situation. This document aims to provide such guidance." It is true that the original documents did not give specific rules for "ANY". But the original documents rarely gave specific rules for any features of the DNS. Over the years many implementations and operations set-ups have handled ANY queries. Up until recently they have all done so consistently and in a manner in conflict with this document. When an authoritative server received a ANY query for a domain name, all of the RRsets available for the name were included in the response. In recursive servers, whatever sets were in hand were returned, if none, a lookup was done to gain as many records as came available. I don't see the justification (that being scant documentation) for re-defining the expectation of what happens in response to an ANY query as being sufficient to redefine actions. Merely relying on the paucity of words in an original definition, and claiming "any" does not mean "all" is, to me, "just playing with words." OTOH, I appreciate the concern over ANY queries. And in May one DNS operator ceased behaving as was the long-term tradition (without notice). I propose two criteria for breaking from tradition. One is sufficient notice (not necessarily from the operator, an RFC on this would do), meaning that there is a defined notice to "fallback" to another approach. Two is a response that is explicitly signaling that the source is not going to answer ANY queries in the traditional manner. In my opinion, co-opting a rarely used record is akin to co-opting the TXT record, a practice that has been traditionally frowned upon. There are private types available. While these do not have an explicit signal of "why" they do not co-opt an otherwise defined record. Gaining a new RR type is not difficult, not in the wake of the SPF vs. TXT record debacle that has played out over the past decade or so. In designing a protocol, it is important that the two communicating end points have appropriate expectations and that is what my complaint is centered upon. Co-opting a record without warning disrupts legacy implementations - in this case especially needlessly as there has been little if any diversion in implmentations despite the scant words in the RFCs. Co-opting also causes future implementations some uncertainty in diving whether the "old" meaning of the record is intended or if the "newer" meaning is intended. On 10/12/15, 23:20, "DNSOP on behalf of Joe Abley" <dnsop-boun...@ietf.org on behalf of jab...@hopcount.ca> wrote: >New text added following review by Evan Hunt (on this list) and David >Lawrence (at dns-oarc in Montréal, I think). > >Forwarded message: > >> From: internet-dra...@ietf.org >> To: Marek Majkowski <ma...@cloudflare.com>, Joe Abley >> <jab...@dyn.com>, Olafur Gudmundsson <ola...@cloudflare.com> >> Subject: New Version Notification for >> draft-jabley-dnsop-refuse-any-01.txt >> Date: Mon, 12 Oct 2015 14:19:42 -0700 >> >> >> A new version of I-D, draft-jabley-dnsop-refuse-any-01.txt >> has been successfully submitted by Joe Abley and posted to the >> IETF repository. >> >> Name: draft-jabley-dnsop-refuse-any >> Revision: 01 >> Title: Providing Minimal-Sized Responses to DNS Queries with >> QTYPE=ANY >> Document date: 2015-10-12 >> Group: Individual Submission >> Pages: 16 >> URL: >> >>https://www.ietf.org/internet-drafts/draft-jabley-dnsop-refuse-any-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-jabley-dnsop-refuse-any/ >> Htmlized: >> https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-01 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-jabley-dnsop-refuse-any-01 >> >> Abstract: >> The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". >> The operator of an authoritative DNS server might choose not to >> respond to such queries for reasons of local policy, motivated by >> security, performance or other reasons. >> >> The DNS specification does not include specific guidance for the >> behaviour of DNS servers or clients in this situation. This document >> aims to provide such guidance. >> >> >> >> >> 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. >> >> The IETF Secretariat >> > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
