[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt

[Shumon Huque <[e-mail]>]

On Tue, Jul 9, 2024 at 2:25 PM John Levine <[e-mail]> wrote:

> It appears that Tim Wicinski  <[e-mail]> 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:
>

Thanks John ..

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.
>

The simplest thing to do would be to follow the precedent of SPF,
DKIM, etc TXT using protocols and state that multiple TXT strings
(if present) need to be concatenated before use. We can state
this.

In practice, given entropy requirements, verification tokens are typically
small enough compared to the max TXT string length, that even with
some other key=value metadata things, they are unlikely to spill over into
multiple strings. But I agree, we need to address that possibility and state
what to do.

Wildcards can cause some annoying problems, notably that a wildcard
> will match any tagged name so queries for tagged names can get junk
> answers.


Can you elaborate on what you mean? A wildcard TXT match may yield
an answer with a verification record rdata string which is nonsensical
because no-one will be looking to verify such a record. Other than it
(possibly) being annoying, is there a practical problem? This situation
is certainly not unique to this draft.


> 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.
>

I don't think this is necessary. Some applications do this today, but
I suspect it is to make it easier to identify the application from the
sea of verification TXT records at the zone apex. Since the draft
recommends application specific validation record "owner names",
that seems to be a better place to make this identification.


> 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.
>

Yes, that was a mistake. I see that Tim Wicinski already followed up
on fixing this.

Shumon.