It appears that Shivan Kaul Sahib <shivankaulsa...@gmail.com> said: >-=-=-=-=-=- > >Hi folks, we (finally) published a new version of the domain verification >techniques draft, now as intended-BCP. We've had some feedback from >providers but would love for folks to review, especially people who would >actually use it.
While I think it would be good to publish some best practices in this area, this draft still seems scattered and makes some assertions that seem to me to be somewhere between unsupported and mistaken. I think we agree that the goal is there are two parties, call them owner and verifier, and the verifier gives the owner a random token that the owner puts in its DNS to show it owns the domain. There are a bunch of different aspects that one can look at independently. One is where the token goes, in the name or contents of the owner's record. I think we agree that putting the token at the owner's host name is a bad idea, but either of these can work, with a1b2c3 being the random token: _a1b2c3.example.com IN ... "whatever" _crudco.example.com IN ... "a1b2c3" If you use a fixed prefix, _crudco in this case, you should register it in the RFC8552 attrleaf registry. Another is what record type to use. I find the arguments against CNAME unpersuasive, basically saying that if you do something dumb, it won't work, which is true, but it's always true. 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. If you use a _name in the attrleaf registry or a _random prefix I would think the changes of a CNAME colliding with something else are low, and a verifier presumably controls its own DNS and can keep CNAME chains short. So any of these could work: _a1b2c3.example.com IN TXT "crudco" _a1b2c3.example.com IN CNAME verify.crudco.wtf. _crudco.example.com IN TXT "a1b2c3" _crudco.example.com IN CNAME _a1b2c3.crudco.wtf. As you sort of note in one of the appendices, you can have different tokens in the name and the content if for some reason that is useful. For the length of time the token is valid, there seem to be only two: five minutes for a one-off verification like for ACME, or forever for someone who is doing continuing analysis of something in your domain, typically web analytics. While I can see aesthetic reasons to get rid of expired one-off tokens, I don't see the point of putting an expiration time in them, nor any particular harm in leaving them there if they are at _name and not the main host name. You might also say something about TTLs, e.g., not to have a 12 hour TTL for a token you plan to remove in a few minutes. There are some other minor points. You say to generate 128 random bits, but then to hash them to 256 which I don't understand. (As RFC 4086 sec 6.2 notes, strong random bits often are already hash output.) If 128 bits is enough, use 128 bits, if you need 256, generate 256. Either way I'd do base32 rather than base64 encoding to make the result more robust against helpful software that does you a favor by case folding. Overall, I'd lay out the options, and point out the advantages or disadvantages of each rather than just saying "do this" without a strong basis not to do it the other ways that work fine in practice. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
