Top-reply to raise (IMHO) a major issue: This is not only a "publish vs discover" issue, it also is dangerously close to the IDNA rat-hole.
I wasn't around when the latter came up, but I think DNSEXT dodged a bullet very wisely, by making it the applications' responsibility to handle any/all case folding beyond ASCII. There are also scale issues, e.g. consider use cases where #users in a domain vary in order of magnitude. What works for O(10e3) does not work for O(10e6), and definitely does not work for O(10e9). There are implications to DNS resolution & caching, if you consider stub, recursive, and authoritative actors. It may be the case that multiple queries need to be done by the stub, regardless of approach. However, if policy discovery involves looking up a single common record per DNS zone (e.g. rhs of email address), then this is cacheable and reduces both the size of the publishing zone, as well as the number of queries by the recursive to the authoritative, per client query. I implore everyone to please consider the design: _casefolding RRTYPE RDATA as a way of allowing the zone owner to publish all the case-folding rules for the zone, and require the client to use this to discover the canonical (published) owner name for a given email address. Brian P.S. For those not familiar with it: The IDNA rat-hole involves case-folding of >2:1, as well as things like Greek language where there are lots of rules governing variant code points depending on context (first/last letter of a word). Putting that into DNS would have been an absolute nightmare, and pushing back on that request was IMHO the right thing to do. On Wed, Feb 25, 2015 at 11:15 AM, Viktor Dukhovni <[email protected]> wrote: > On Wed, Feb 25, 2015 at 02:01:38PM -0500, Paul Wouters wrote: > > > On Wed, 25 Feb 2015, Viktor Dukhovni wrote: > > > > >Once the client is making two queries, why accept collisions? Are > > >we (after all these years) finally defining RFC-822/2822/5322 local > > >parts to be case-insensitive? (Price of progress and all that?) > > > > > >Is a CNAME per-user really a major burden? > > > > It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul > > paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P > > One CNAME per case-insensitive name (if the preferred form is mixed > or upper case). Those other names you're mentioning if they all > share the same underlying keys would be CNAMEs you'd have to create > with or without my proposal for a mechanism to publish case-insensitive > names. > > > The client needs smart logic anyway, and the client at least has a user > > it can interact with. It can ask "A key for [email protected] does not > > exist but there is a key for [email protected]". > > Why ask the user, when the server can just publish the fact that > all upper/mixed-case veriants of "paul" are the same mailbox. > > > Needing to roll out between 2 and 4 different capitalizations for > > different [Ff]irstname.[Ll]astname makes everything more errorprone > > and the client still needs its logic and user interaction. > > The I don't how you get to "4". You can publish exactly one owner > for each case-insensitive "LocalPart", no CNAMEs required if you > are willing to accept clients making two queries to find keys in > your domain (space/time trade-off): > > SHA2-224(localpart@lowercase) IN <RDATA> > > Optionally, for faster queries, if the mailbox has a preferred > form: > > SHA2-224(LocalPart) IN <RDATA> > SHA2-224(localpart@lowercase) IN CNAME SHA2-224(LocalPart) > > If there's also a "Local.Part" and "local.part" to go with it, that > it is completely separate from my proposal which deals only with > handling case-insensitive matching. The overhead of supporting > case-insensitive matching is at most a second (CNAME) record for > each record that would be there in the absence of the proposal. > > -- > Viktor. > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
