It appears that Tim Wicinski <tjw.i...@gmail.com> said: >This is one of those DNSOP documents that may not be relevant to those who >implement DNS, or those who operate DNS infrastructure. It is relevant to >Applications that use the DNS, and those who focus on what actually DNS >records exist in zones.
I took a look and it is indeed greatly improved. Here are some implementation issues that may or may not be worth addressing: It says to put everything in a text record which is fine, but it doesn't say anything about how to encode it. There are two competing approaches. One says that the string boundaries in the record don't matter, so combine all of the strings into one string. The other is to treat each string as a token or expression, and the string boundaries are the token or expression boundaries. The examples suggest the former way, but it should say so. Alternatively, people checking domain verification records need to say which way they're doing it. Wildcards can cause some annoying problems, notably that a wildcard will match any tagged name so queries for tagged names can get junk answers. A) Should verification records have a tag at the front of the data to identify the record type? There's plenty of prior art for this, e.g., the 63 text records at stanford.edu. Or you might say that a sufficiently long random token in the interesting part will prevent false positives so there's no need. 2) If you put records at a tagged name that is supposed to be unique and a query returns some junk records and some plausibly good records, what do you do? Use what you can? Ignore it all because you probably stepped on a wildcard? Minor nit: why are the CNAME targets quoted? I've never seen a quoted target name and when I look at RFC 1034 it doesn't look like it's valid. R's, John _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
