--On Thursday, September 24, 2015 16:28 -0400 Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> wrote: > On Sat, Sep 12, 2015 at 08:18:49AM +1000, Mark Andrews wrote: >> And the DNS is supposed to preserve the case of entered >> labels. > > […] > >> Later versions of BIND 9 do that to the RRset level and it >> would be possible to do it to the RR level if needed. > > I am not confident that doing it to the RR level would be a > good idea in the DNS, and I'm not sure that the DNS protocol > is sufficiently carefully described that making the > distinction between RRs and the RRset in this way would be > successfully interoperable. Certainly, this is an area that's > underspecified, >... Speaking as someone who, in this area, is far more qualified to be a victim than an expert, can we please get things that affects what people can and cannot reasonably expect written down somewhere, perhaps as an update to RFC 2181? It seems to me that differences in expectations, inconsistent implementations, and inconsistent interpretations of what the standards actually require, turn rather quickly into fundamental interoperability issues (and those often turn into security vulnerabilities), rather than mere issues of different choices. Expectations about case preservation under different scenarios, with comments about how strong those expectations should be given various implementations (including but not limited to earlier versions of BIND) would seem to be candidates. I don't know how many DNS implementations are now taking U-labels or even UTR-46-conformant strings, and input for zone files, but some comments about expectations there, especially when a label is mostly, but not entirely, ASCII characters, may be in order too [1]. I assume that you, Mark, the leadership of DNSOP, and others have much longer list [2]. best, john [1] It is very clear in the IDNA documents, but IDNA was written so that DNS implementations didn't need to pay attention to it and apparently, some haven't. [2] I observe that one recent document got all the way through a DNS-related WG and into IETF Last Call with an included assumption that it was not possible to put a non-ASCII character in a DNS label, something that I think is very clear in 1034 but that 2181 makes even more explicit. The DNS expert community clearly has got some education to do, both inside and outside the IETF.