Domain Name System (DNS) Case Insensitivity Clarification
RFC 4343
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Margaret Cullen; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) (was Discuss) No Objection
My Discuss was written 3/30, the revision appeared 7/20, and I guess
due to my travel and vacation schedule I did not respond to the tracker
notes of update. I've cleared my Discuss on a message from Margaret showing
the changed text, 9/9/05. The changed text handles my concern very well:
The handling of DNS label case is not CLASS dependent. With the
original design of DNS, it was intended that a recursive DNS resolver
be able to handle new CLASSes that were unknown at the time of its
implementation. This requires uniform handling of label case
insensitivity. Should it become desireable, for example, to allocate
a CLASS with "case sensitive ASCII labels" for example, it would be
necessary to allocate a new label type for these labels.l
My comment from March 30 seems not addressed, have
asked if a note to the RFC Editor is possible:
In the Security Considerations, the term "RP" should
be expanded, and the reference to RFC 1183 (if that's
the best one) given.
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
Comment from the Ops directorate by (Pekka Savola) (Mar 30 17:47:13 PST 2005): Allison raises a good point about whether we want to force this behaviour on all the future CLASSes as well or not. I don't have strong opinion either way, but it would seem that differently aged implementations would probably result in inconsistent behaviour if the type case insensitivity (or not) was CLASS-specific (because implementations don't require changes to serve new CLASS types, while the case insensitivity per class would break that model). Major issue: - the document seems to be suggesting very dubious procedures, leading to inconsistent results. Unless I'm misunderstanding something, we should NOT accept something like this. Section 4.2 says, "Thus the case of ASCII labels is preserved if they are for nodes being created. However, when a name label is input for a node that already exist in DNS data being held, the situation is more complex. Implementations may retain the case first input for such a label or allow new input to override the old case or even maintain separate copies preserving the input case." If I read this correctly, the zone file could include "foo.example.net A 1.2.3.4" and "FOO.example.net A 5.6.7.8", and depending on the case of the query, the results could be very inconsistent. This problem is amplified by the fact that the output case insensitivity is not preserved. So, for example, caching resolvers or root/xTLD servers could end up changing the case pretty arbitrarily, without the stub resolver being able to do anything about it. This appears to be an unacceptable situation. Instead, the existing case should be kept or updated, but there never ever should be two different casings for the same name. This may call for a MUST NOT. ..... Not quite as major: - section 2 is a nice introduction to the topic but left me wondering.. because the text has very little to do with case insensitivity as such. It seems that maybe thename of the document be changed to something more generic like "DNS Name Presentation and Processing Clarifications", and ripple through the abstract and introduction ? This is important particularly because the document is not clear enough which parts of the document are meant as normative (updating 1034/1035) and which parts are just informative text. If section 2 has normative elements, the fact should be more clearly presented in the name of the document as well. Editorial issues: - the document uses a number of non-example.com/192.0.2.0 addresses/names, but in this case this seems justifiable - the IPR boilerplates and disclosures at the end are missing - the historical note in section 3 could probably be removed. This is not the 70's anymore, and the original specs also talk about character case. Or if you want to keep it because that's why it may be written in the [ASCII] reference, just say something like "upper case ("majuscule" in [ASCII]) ..." - this sentence in 4.1, especially the start of it, is difficult to follow. Consider rephrasing: ASCII output is as if a name was marshaled by taking the label on the node whose name is to be output, converting it to a typographically encoded ASCII string, walking up the tree outputting each label encountered, and preceding all labels but the first with a period ("."). - in references, draft-ietf-dnsext-unknown-rrs-05.txt has been published 18 months ago as RFC 3597. (Kinda speaks of the amount of review..) - the changelogs at the end should be clearly marked to be removed by the RFC-editor before publication.
(Jon Peterson; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Scott Hollenbeck; former steering group member) No Objection