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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
