Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
Ted Lemon wrote: i took the words "at or below" to mean "in-bailiwick". caches that are not organized as tree-like data structures still have to be able to find the closest encloser, which means they do know ancestor/descendent relationships, even if the data structure itself is otherwise flatishly hashlike. The most straightforward way to implement this is to say "FOO.BAR.COM"'s closest encloser is BAR.COM, and then look BAR.COM up in the cache. Which is fine when you _need_ to do that. It's not fine to do it on every query even when it otherwise would not have been necessary (which would be the vast majority of cases). But to implement this algorithm you need to start at the room, so first look at ".", then at "COM", then at "BAR.COM". That's three hash lookups if there's a cached NXDOMAIN, and four if there isn't. Blech. Ted, I think you're reading it wrong. The implementation doesn't matter at all. As Co-Chair Woolf kindly and classily 2x4'd me last year, an RFC should be of the form "if you want to do X, here's a way to do it interoperably." This specification should express the basic idea that after an NXDOMAIN has been received from an authority server for name X, then the receiver of that NXDOMAIN is allowed to (note: "allowed to"; this is optional, and is just an optimization) treat it as also applying to any name that is in-bailiwick for X. (Sometimes that will be expressed as "at or below X" or "a subdomain of X".) If an implementation doesn't perform this optimization, then for names below X, it will forward queries to an authority, who WILL answer with NXDOMAIN unless the name-below-X has actually been created in the time since the NXDOMAIN for X itself was received. Like all other forms of negative caching, this is just a speedup, and if a cache is implemented in a way that makes "is there a negative cache element for whose owner name this qname is in-bailiwick?" too expensive, then that negative caching implementation will probably not perform this optimization. There is a specification clarification here: QUERY for an empty non-terminal name must yield response RCODE=0 ANCOUNT=0 even for QTYPE=255. I've always interpreted RFC 1034+1035 that way but not every implementer did. This clarification is nec'y for the optimization being described, since otherwise an empty non-terminal could hide all of its subdomains from implementations of the optimization under discussion. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
> i took the words "at or below" to mean "in-bailiwick". caches that are > not organized as tree-like data structures still have to be able to find > the closest encloser, which means they do know ancestor/descendent > relationships, even if the data structure itself is otherwise flatishly > hashlike. The most straightforward way to implement this is to say "FOO.BAR.COM"'s closest encloser is BAR.COM, and then look BAR.COM up in the cache. Which is fine when you _need_ to do that. It's not fine to do it on every query even when it otherwise would not have been necessary (which would be the vast majority of cases). But to implement this algorithm you need to start at the room, so first look at ".", then at "COM", then at "BAR.COM". That's three hash lookups if there's a cached NXDOMAIN, and four if there isn't. Blech. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
> Perhaps we can make it explicit that the tree here is conceptual, and > not an implementation required data structure? That's not the point. The point is that if the _cache_ is represented as a tree, then you can talk about names being "under" other names; if it's not, then that relationship doesn't exist _in the cache_ even though it _does_ exist in the namespace. > The domain name space is certainly defined in terms of a tree structure. > And the cache being a subset of the data in the domain name space -- it > is much easier to reason about it in terms of that tree structure and to > describe things in those terms (names under/above, descendent names, > subtrees etc). Absolutely right. The problem is that are not just reasoning about it: we are placing a requirement on implementations. > On the question of "SHOULD", I was hoping we'd get rough consensus > that this is a good goal, in terms of making the entire DNS ecosystem > more efficient - why should resolvers make unnecessary outbound > queries for name that don't exist, and why should authoritative servers > receive those queries? But I understand the concern that there might be > implementation challenges for some. That's up to the chairs to decide, but I certainly don't think we _should_ have consensus on this point without having some sense of whether there is any measurable real-world increase in efficiency. This is easy to implement, as is any proposal; the question is, do we want to slow down _every_ query in order to speed up a very tiny number of queries? A hashed implementation will, for every query, have to check every label in the question, starting from the root, a cached NXDOMAIN record, and almost every time will find nothing. So this is really quite a significant increase in overhead. Whereas the increase in efficiency even for caches that use a tree data structure will be down in the noise. What this might be is a quick speed hack for dealing with PRSD attacks in caches that use trees. So I support _allowing_ this behavior. I just don't support requiring it, and if you do, you should really do some measurements to show that there is a _significant_ speed improvement to justify such a requirement. Otherwise, I think that this change is out of charter, because there's no operational issue that this new _requirement_ addresses, even if the clarification has some value operationally. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
On Fri, Mar 11, 2016 at 3:52 PM, Ted Lemon wrote: > > It is certainly not the goal. Can you tell exactly where it is > > assumed? Section 2 is supposed to be implementation-neutral. > > Right here: > >When an iterative caching DNS resolver receives a response NXDOMAIN, >it SHOULD store it in its cache and all names and RRsets at or below >that node SHOULD then be considered to be unreachable. Subsequent >queries for such names SHOULD elicit an NXDOMAIN response. > > "At or below" assumes a tree. Just because it isn't explicitly mentioned > doesn't mean that it's not saying that! > Perhaps we can make it explicit that the tree here is conceptual, and not an implementation required data structure? The domain name space is certainly defined in terms of a tree structure. And the cache being a subset of the data in the domain name space -- it is much easier to reason about it in terms of that tree structure and to describe things in those terms (names under/above, descendent names, subtrees etc). In fact, the DNS algorithm description in RFC 1034 clearly states an assumption that the cache is a tree structure, so the precedent is already well established: see section 4.3.2 which says "The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache:" ... Personally, I would be okay with removing the "Implementation Considerations" section. On the question of "SHOULD", I was hoping we'd get rough consensus that this is a good goal, in terms of making the entire DNS ecosystem more efficient - why should resolvers make unnecessary outbound queries for name that don't exist, and why should authoritative servers receive those queries? But I understand the concern that there might be implementation challenges for some. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
Ted Lemon wrote: It is certainly not the goal. Can you tell exactly where it is assumed? Section 2 is supposed to be implementation-neutral. Right here: When an iterative caching DNS resolver receives a response NXDOMAIN, it SHOULD store it in its cache and all names and RRsets at or below that node SHOULD then be considered to be unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response. "At or below" assumes a tree. Just because it isn't explicitly mentioned doesn't mean that it's not saying that! i took the words "at or below" to mean "in-bailiwick". caches that are not organized as tree-like data structures still have to be able to find the closest encloser, which means they do know ancestor/descendent relationships, even if the data structure itself is otherwise flatishly hashlike. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dnsop - Requested sessions have been scheduled for IETF 95
DNSOP I apologize but in wanting to get two sessions to separate the 6761 riff-raff, we angered the scheduling gods, and they gave us back to back sessions on Friday Morning. once i get home i'll put together a preliminary agenda for the chairs, tim On 3/12/16 12:05 AM, "IETF Secretariat" wrote: Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (2:00:00) Friday, Morning Session I 1000-1200 Room Name: Buen Ayre C size: 250 - dnsop Session 2 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Pacifico A size: 300 - Request Information: - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 140 Conflicts to Avoid: First Priority: dprive dnssd homenet appsawg apparea dhc dane dbound Second Priority: eppext trans intarea mif v6ops Third Priority: sidr saag pcp opsawg opsarea grow 6man Special Requests: With the DNS-OARC meeting the weekend before IETF in the same hotel, we are hoping you can book this meeting in the first two days of the conference to encourage any participants from OARC to attend. - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] dnsop - Requested sessions have been scheduled for IETF 95
Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (2:00:00) Friday, Morning Session I 1000-1200 Room Name: Buen Ayre C size: 250 - dnsop Session 2 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Pacifico A size: 300 - Request Information: - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 140 Conflicts to Avoid: First Priority: dprive dnssd homenet appsawg apparea dhc dane dbound Second Priority: eppext trans intarea mif v6ops Third Priority: sidr saag pcp opsawg opsarea grow 6man Special Requests: With the DNS-OARC meeting the weekend before IETF in the same hotel, we are hoping you can book this meeting in the first two days of the conference to encourage any participants from OARC to attend. - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erratra rejection
In message <20160311214228.ga30...@mycre.ws>, Robert Edmonds writes: > Hi, > > Dick Franks wrote: > > On 11 March 2016 at 17:47, Robert Edmonds wrote: > > > > > Dick Franks wrote: > > > > There is no need to resort to doctrinal arguments about > MUST/SHOULD, or > > > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > > > > > Mark A's objection really points a fundamental contradiction in > RFC6844 > > > > itself. > > > > > > Hi, Dick: > > > > > > Are you implying that 6844 violates 1035 in some way? > > > > > > 6844 5.1.1 defines the tag field in a way which forbids the (arbitrary) > > characters which MAY (but SHOULD NOT) be present according to the text > in > > 5.1. > > It's clear from the context that 6844 5.1 is talking about the wire > format, while 5.1.1 is talking about the presentation format. If the > rules for the canonical presentation format are stricter than the rules > for the wire format, then there exist wire RRs that cannot be > represented using the canonical presentation format. Which, the > verifier's notes in erratum 4061 claim, is OK, and not a contradiction. That's only the verifier's opinion (sorry Kathleen). Master files are used for zone transfers (see STD 13). They need to be able to represent all records. Master file parsers need know when they are being presented with garbage or well formed records. The RFC does not do that. Unknown format is for *unknown* records not *know* records. If the text representation cannot represent *every* record for that type then the RFC is *broken*. If CAA want implementations to use unknown format then the RFC should say that. [ There are some other DNS type RFC's that could be updated to say the same thing. ] Note saying that the canonical format is lower case causes potential DNSSEC issues if record get written out in canonical form then get read back in as there is potential for case change which will cause RRSIGs to no longer match. > > This conflicts with the 1035 notion that master files contain text > > representation of RRs. > > Any instance of a cacheable wire RR has a master file compatible text > representation, thanks to the generic text encoding defined in RFC 3597. > > 1035 doesn't distinguish between canonical and generic text > representation because the generic encoding hadn't been invented yet, of > course. > > > I understand the > > > reasoning in the erratum rejection: > > > > > > ... > > > > > > The author believes SHOULD is correct here. The protocol on the > wire > > > will work just fine if someone breaks this advice. > > > > > > Yes, it might well break some zone file parsers. But those aren't > on > > > the wire and that type of incompatibility is exactly what I would > > > expect from violating a SHOULD. > > > > > > ... > > > > > > to be asserting that a valid wire format RR can have no valid > canonical > > > presentation format. > > > > > > But CAA _does_ have a canonical presentation format, defined at 5.1.1. > > Sorry, I meant to say that the erratum rejection asserts that there can > exist instances of valid on-the-wire RRs of known type that don't have a > valid canonical presentation form. > > > The closest requirement I can find in 1035 is this: > > > > > > 5. MASTER FILES > > > > > > Master files are text files that contain RRs in text form. Since > the > > > contents of a zone can be expressed in the form of a list of RRs a > > > master file is most often used to define a zone, though it can be > used > > > to list a cache's contents. > > > > > > > So are you really suggesting flipping between canonical 6844 format and > > 3597 \# format merely because the tag field happens to contain some > > non-alphanumeric character or upper case letter? > > Yes. If a RR can't be presented canonically, how else would you do it? > > This is apparently exactly how BIND handles LOC records whose VERSION > field is not 0, BTW: There are subtle difference between LOC and CAA. While it is forseeable that we may need to define a different version we have no idea what that version will be. For tags we do actually have ideas about what that could be as we have deliberately choosen to restrict the syntax of the tag from the set of all known characters. CAA could have defined the tag to be a UTF-8 string. CAA could have defined it to be a arbitary ASCII string. It could have defined the canonical presentation format to be a printable lowercase ASCII string with a prefered syntax of a-z, 0-9 or escaped UTF-8 with A-Z mapped to a-z. The record is just plainly poorly defined as different implementors have different ideas about what is meant to be supported and that is causing problem. PKIX needs to fix this. Once they fix this the nameserver vendors can fix implementations to match. > $ dig +norec @70.89.251.90 -t AXFR test.mycre.ws > > ; <<>> DiG 9.10.3 <<>> +norec @70.89.251.90 -t AXFR test.mycre.ws > ; (1 server found) > ;; global options: +cmd > tes
Re: [DNSOP] Erratra rejection
Hi, Dick Franks wrote: > On 11 March 2016 at 17:47, Robert Edmonds wrote: > > > Dick Franks wrote: > > > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > > > Mark A's objection really points a fundamental contradiction in RFC6844 > > > itself. > > > > Hi, Dick: > > > > Are you implying that 6844 violates 1035 in some way? > > > 6844 5.1.1 defines the tag field in a way which forbids the (arbitrary) > characters which MAY (but SHOULD NOT) be present according to the text in > 5.1. It's clear from the context that 6844 §5.1 is talking about the wire format, while §5.1.1 is talking about the presentation format. If the rules for the canonical presentation format are stricter than the rules for the wire format, then there exist wire RRs that cannot be represented using the canonical presentation format. Which, the verifier's notes in erratum 4061 claim, is OK, and not a contradiction. > This conflicts with the 1035 notion that master files contain text > representation of RRs. Any instance of a cacheable wire RR has a master file compatible text representation, thanks to the generic text encoding defined in RFC 3597. 1035 doesn't distinguish between canonical and generic text representation because the generic encoding hadn't been invented yet, of course. > I understand the > > reasoning in the erratum rejection: > > > > [...] > > > > The author believes SHOULD is correct here. The protocol on the wire > > will work just fine if someone breaks this advice. > > > > Yes, it might well break some zone file parsers. But those aren't on > > the wire and that type of incompatibility is exactly what I would > > expect from violating a SHOULD. > > > > [...] > > > > to be asserting that a valid wire format RR can have no valid canonical > > presentation format. > > > But CAA _does_ have a canonical presentation format, defined at 5.1.1. Sorry, I meant to say that the erratum rejection asserts that there can exist instances of valid on-the-wire RRs of known type that don't have a valid canonical presentation form. > The closest requirement I can find in 1035 is this: > > > > 5. MASTER FILES > > > > Master files are text files that contain RRs in text form. Since the > > contents of a zone can be expressed in the form of a list of RRs a > > master file is most often used to define a zone, though it can be used > > to list a cache's contents. > > > > So are you really suggesting flipping between canonical 6844 format and > 3597 \# format merely because the tag field happens to contain some > non-alphanumeric character or upper case letter? Yes. If a RR can't be presented canonically, how else would you do it? This is apparently exactly how BIND handles LOC records whose VERSION field is not 0, BTW: $ dig +norec @70.89.251.90 -t AXFR test.mycre.ws ; <<>> DiG 9.10.3 <<>> +norec @70.89.251.90 -t AXFR test.mycre.ws ; (1 server found) ;; global options: +cmd test.mycre.ws. 3600IN SOA mycre.ws. hostmaster.mycre.ws. 2016031104 7200 3600 604800 3600 test.mycre.ws. 3600IN NS bst.mycre.ws. loc.test.mycre.ws. 3600IN LOC \# 16 FFC0237FB02600C0237F loc2.test.mycre.ws. 3600IN LOC 42 21 28.764 N 71 0 51.617 W -10.00m 2000m 1m 10m test.mycre.ws. 3600IN SOA mycre.ws. hostmaster.mycre.ws. 2016031104 7200 3600 604800 3600 ;; Query time: 0 msec ;; SERVER: 70.89.251.90#53(70.89.251.90) ;; WHEN: Fri Mar 11 15:58:01 EST 2016 ;; XFR size: 5 records (messages 1, bytes 197) > > RFC6844 offers no justification for case folding, so > > > specifying exact matching would make the whole issue go away. > > > > I would hazard a guess that the "Matching of tag values is case > > insensitive" sentence is a requirement on applications that consume the > > RR, and not to DNS protocol comparisons like RRset data equality or > > DNSSEC canonical form. (Note the sentence "Applications that interpret > > CAA records..." a few lines up.) > > > > An unnecessary complication in my view, but maybe that is off-topic here. Well, speaking of unnecessary complications, maybe the practice of defining data RRTYPEs with canonical presentation formats that can only represent a subset of valid on-the-wire RRs ought to be explicitly banned going forward. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
> It is certainly not the goal. Can you tell exactly where it is > assumed? Section 2 is supposed to be implementation-neutral. Right here: When an iterative caching DNS resolver receives a response NXDOMAIN, it SHOULD store it in its cache and all names and RRsets at or below that node SHOULD then be considered to be unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response. "At or below" assumes a tree. Just because it isn't explicitly mentioned doesn't mean that it's not saying that! > If the cache is a hash, the requirement at the beginning of section > two is actually expensive to implement, > This is exactly what section 5 says (last paragraph). Yes, it does say that, and I agree with what it says--I'm just proposing that the document be changed so that it's not necessary to say that. > I disagree here. This is (if approved) a normative document. It does > place "new" requirments. (I write "new" between quotes because > resolvers with NXDOMAIN cut behavior are, IMHO, legal even today, the > original RFCs are not perfectly clear.) This is what I'm saying: it shouldn't be making requirements on the resolver. It should just clarify that if you get an NXDOMAIN for name K, any name that is a subdomain of K can be assumed also to return an NXDOMAIN. > It is a change in the behaviour of the majority of resolvers, but not > a change in the protocol. So, yes, it is "to address operational > issues with the DNS protocols by extending or performing protocol > maintenance on them" Any protocol change that changes the operation of the DNS in any way can be justified on this basis. If that is what this section of the charter means, then we can make nearly any change to the protocol that we want and still be in charter. I think more reasonably what this section of the charter means is that you can update the protocol to address an operational problem. But this draft isn't really adressing an operational problem: your motivation for doing this is to support DPRIVE, not because anybody is going to notice a reduction in the number of queries even if this is widely implemented. It's not even addressing a serious problem in DPRIVE. If it's just to address a subset of possible PRSD attacks, the protocol clarification without the requirement is already sufficient, because the clarification adds a tool for implementors who are motivated to use this technique to address that problem, but is not required of implementors who want to approach it in a different way. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Wed, Mar 02, 2016 at 10:10:09AM +0100, Shane Kerr wrote a message of 29 lines which said: > I can see that implementors such as yourself like won't bother with > a special-cased version, and that adding code to restrict this > technique to the root only is likely to be MORE WORK. I know at least one case of an implemented option which is to the root only when it could be more general: https://doc.powerdns.com/md/recursor/settings/#root-nx-trust So, not all implementers think the same. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erratra rejection
On 11 March 2016 at 17:47, Robert Edmonds wrote: > Dick Franks wrote: > > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > Mark A's objection really points a fundamental contradiction in RFC6844 > > itself. > > Hi, Dick: > > Are you implying that 6844 violates 1035 in some way? 6844 5.1.1 defines the tag field in a way which forbids the (arbitrary) characters which MAY (but SHOULD NOT) be present according to the text in 5.1. This conflicts with the 1035 notion that master files contain text representation of RRs. I understand the > reasoning in the erratum rejection: > > [...] > > The author believes SHOULD is correct here. The protocol on the wire > will work just fine if someone breaks this advice. > > Yes, it might well break some zone file parsers. But those aren't on > the wire and that type of incompatibility is exactly what I would > expect from violating a SHOULD. > > [...] > > to be asserting that a valid wire format RR can have no valid canonical > presentation format. But CAA _does_ have a canonical presentation format, defined at 5.1.1. The closest requirement I can find in 1035 is this: > > 5. MASTER FILES > > Master files are text files that contain RRs in text form. Since the > contents of a zone can be expressed in the form of a list of RRs a > master file is most often used to define a zone, though it can be used > to list a cache's contents. > So are you really suggesting flipping between canonical 6844 format and 3597 \# format merely because the tag field happens to contain some non-alphanumeric character or upper case letter? > RFC6844 offers no justification for case folding, so > > specifying exact matching would make the whole issue go away. > > I would hazard a guess that the "Matching of tag values is case > insensitive" sentence is a requirement on applications that consume the > RR, and not to DNS protocol comparisons like RRset data equality or > DNSSEC canonical form. (Note the sentence "Applications that interpret > CAA records..." a few lines up.) > An unnecessary complication in my view, but maybe that is off-topic here. -- Dick Franks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt
On Fri, Mar 11, 2016 at 04:26:19AM +, Ted Lemon wrote a message of 13 lines which said: > However, I think that this document still goes too far in terms of > assuming a particular implementation, in the sense that it appears > to assume that the cache is a tree. It is certainly not the goal. Can you tell exactly where it is assumed? Section 2 is supposed to be implementation-neutral. Section 5 discusses implementations but does not assume or recommend a specific one. Section 1 uses the word "tree" but to describe the abstract data structure (you will certainly agree that domain names are a tree...) not the actual implementation. > If the cache is a hash, the requirement at the beginning of section > two is actually expensive to implement, This is exactly what section 5 says (last paragraph). > I think this document could be made a lot simpler if it simply said > what it says in the abstract, without placing new requirements on > DNS caches. I disagree here. This is (if approved) a normative document. It does place "new" requirments. (I write "new" between quotes because resolvers with NXDOMAIN cut behavior are, IMHO, legal even today, the original RFCs are not perfectly clear.) > BTW, is this even in charter for DNSOP? I suppose the theory is > that it falls under item 4 in the charter, but that seems like a > stretch to me. It is a change in the behaviour of the majority of resolvers, but not a change in the protocol. So, yes, it is "to address operational issues with the DNS protocols by extending or performing protocol maintenance on them" ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erratra rejection
Dick Franks wrote: > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > imagine that the RFC6844 tail can wag the RFC1035 dog. > > Mark A's objection really points a fundamental contradiction in RFC6844 > itself. Hi, Dick: Are you implying that 6844 violates 1035 in some way? I understand the reasoning in the erratum rejection: [...] The author believes SHOULD is correct here. The protocol on the wire will work just fine if someone breaks this advice. Yes, it might well break some zone file parsers. But those aren't on the wire and that type of incompatibility is exactly what I would expect from violating a SHOULD. [...] to be asserting that a valid wire format RR can have no valid canonical presentation format. The closest requirement I can find in 1035 is this: 5. MASTER FILES Master files are text files that contain RRs in text form. Since the contents of a zone can be expressed in the form of a list of RRs a master file is most often used to define a zone, though it can be used to list a cache's contents. I.e., cacheable RRTYPEs (non- meta TYPEs) must be representable in master files. At the time 1035 was written, this would have implied a requirement that valid wire format RRs must have a valid canonical presentation format. But 3597 defined the generic "\#" encoding for RDATA appearing in master files, and explicitly allowed its use for representing known RRTYPEs: An implementation MAY also choose to represent some RRs of known type using the above generic representations for the type, class and/or RDATA, which carries the benefit of making the resulting master file portable to servers where these types are unknown. Using the generic representation for the RDATA of an RR of known type can also be useful in the case of an RR type where the text format varies depending on a version, protocol, or similar field (or several) embedded in the RDATA when such a field has a value for which no text format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0. Even though an RR of known type represented in the \# format is effectively treated as an unknown type for the purpose of parsing the RDATA text representation, all further processing by the server MUST treat it as a known type and take into account any applicable type- specific rules regarding compression, canonicalization, etc. > RFC6844: > > 5.1.1. Canonical Presentation Format > >The canonical presentation format of the CAA record is: > [snip] > >Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower > case. > > [I assume "non-zero" really means "non-empty"] > > > is incompatible with the text in 5.1: > >Tag: The property identifier, a sequence of US-ASCII characters. > > Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' > through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT > contain any other characters. Matching of tag values is case > insensitive. > > Tag values submitted for registration by IANA MUST NOT contain any > characters other than the (lowercase) US-ASCII characters 'a' > through 'z' and the numbers 0 through 9. > > > which not only appears to imply the existence of two distinct species of > tag identifiers, but has the bizarre consequence that not all tag > identifiers are exactly representable using the canonical format prescribed > by section 5.1.1 > > The same form of words, or at least compatible words, should be used in > both places. RFC6844 offers no justification for case folding, so > specifying exact matching would make the whole issue go away. I would hazard a guess that the "Matching of tag values is case insensitive" sentence is a requirement on applications that consume the RR, and not to DNS protocol comparisons like RRset data equality or DNSSEC canonical form. (Note the sentence "Applications that interpret CAA records..." a few lines up.) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erratra rejection
There is no need to resort to doctrinal arguments about MUST/SHOULD, or imagine that the RFC6844 tail can wag the RFC1035 dog. Mark A's objection really points a fundamental contradiction in RFC6844 itself. RFC6844: 5.1.1. Canonical Presentation Format The canonical presentation format of the CAA record is: [snip] Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. [I assume "non-zero" really means "non-empty"] is incompatible with the text in 5.1: Tag: The property identifier, a sequence of US-ASCII characters. Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT contain any other characters. Matching of tag values is case insensitive. Tag values submitted for registration by IANA MUST NOT contain any characters other than the (lowercase) US-ASCII characters 'a' through 'z' and the numbers 0 through 9. which not only appears to imply the existence of two distinct species of tag identifiers, but has the bizarre consequence that not all tag identifiers are exactly representable using the canonical format prescribed by section 5.1.1 The same form of words, or at least compatible words, should be used in both places. RFC6844 offers no justification for case folding, so specifying exact matching would make the whole issue go away. Dick Franks On 10 March 2016 at 20:34, Mark Andrews wrote: > > I believe the erratra below was rejected incorrectly. > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
