It appears that Paul Wouters <[email protected]> said: >> _a1b2c3.example.com IN ... "whatever" >> _crudco.example.com IN ... "a1b2c3" > >Adding cryptogrpahically strong/long strings in the prefix seems >unwieldly and prone to problems - especially if the user has to put >these in via a webgui of mediocre quality.
That makes no sense. Why is it harder to copy a string to the name field in a cruddy web GUI than to the data field? It's copy and paste either way. >Also it makes manual >checking harder (eg to use the dig command). Same question, it's still copy and paste. But most importantly, you >already need a good prefix to identify the vendor and service No you don't. If you need a prefix to keep your 26 character randomly generated tag from colliding with my 26 character randomly generated tag, at least one of us needs a new random number generator. If you want to identify the vendor and service, that should be evident from the target of the CNAME. >and mucking up random strings there just seems the wrong thing to recommend >as BCP. It doesn't seem wrong to me. I would hope a BCP would be based on something more than "this seems ugly to me." >> If you use a fixed prefix, _crudco in this case, you should register it >> in the RFC8552 attrleaf registry. > >Since we are recommending these are easilly recognised to vendor and >service, these would be different for each vendoer. Sure, we can add >another prefix in between and put that in the attrleaf registry, but >that doesn't add any real value. No, that's not what I said. Each vendor should register its prefix with attrleaf, not an extra noise word. It's not like it's hard to register or there is a shortage of ASCII strings. >> I realize that RFC1034 says >> not to chain CNAMEs, but we all know that people chain CNAMEs and it >> works, e.g. www.microsoft.com goes through three CNAMEs and it works >> fine. > >I was not allowed this line or argumentation with you when talking >about the LHS of an email address :) There is so much wrong in that statement I don't know where to start. >People make mistakes with CNAMEs, let's not recommend CNAMEs so chances >that people get affected my mistakes is reduced. I have bad news. People make mistakes with TXT records too. In any event, this doesn't look like a BCP, it looks to me like someone's personal preferences, not well supported by much else. I would not publish it in anything like its current form. R's, John _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
