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

[John R Levine <[e-mail]>]

On Tue, 23 Jul 2024, Shumon Huque wrote:
> 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.

That should be fine.

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

Yes, but ...

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

The issue is that a wildcard will match every possible owner name.  If you 
are confident that there is enough entropy in the tokens that no verifier 
will ever be confused, OK.  But since the token is supposed to be the only 
thing at the _prefix name, how about saying that if a verifier sees more 
than one record or a junk record, it gives up rather than trying to guess 
which is the right one.

If the token is time limited you'd might get a new one for the existing 
name but I don't think there should be a case when you'd need to publish 
both new and old.  As soon as you have the new one you install it and 
throw away the old one.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly