Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[Shumon Huque <[e-mail]>]

On Mon, Jul 17, 2023 at 7:20 PM Paul Wouters <[e-mail]> wrote:

> On Jul 17, 2023, at 14:12, John R Levine <[e-mail]> wrote:
>
> > The only somewhat plausible argument I see against stuffing the apex is
> that if people are sloppy, they might invent tokens that could be confused
> with each other.
>
> This is an important point and what got me involved with the draft.
>
> > But people have been putting tokens at the apex for years and I have
> never, ever, heard of token confusion.
>
> It’s literally what happened to me in the first week of my current
> $dayjob. I found 5 tokens that no one knew what they were, whom they were
> for and whether or not they were still needed.
>

I'm glad you found out about an issue well known to many DNS administrators
at large organizations! :)

"Stuffing" data for unrelated applications into the same DNS record
(whether at the apex or further down in the zone) has at least the
following other issues:

* Verifiers can't query for the specific data they need from the DNS. They
need to get a potentially large blob of data and look for what is
applicable to them by examining the rdata for each record in the RRset.
This is not a new issue. It is the well known record subtyping problem that
was advised against in RFC 5507 (IAB; "Design Choices When Expanding the
DNS"). That advice was targeted to new RR type design, but it applies just
as well to this type of use of TXT RDATA resident at the same name.

* You can't delegate the (application specific) domain validation record to
a 3rd party.

* Even if you don't delegate the name to another party, you may have a
shared DNS zone where you need to be able to provide record level
permissions to the specific team that is responsible for the application in
question. This can't be done if all the apps share the same domain name.

Shumon.