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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Jul 7, 2025 at 9:29 PM <[e-mail]> wrote:

> Internet-Draft draft-ietf-dnsop-domain-verification-techniques-09.txt is
> now
> available. It is a work item of the Domain Name System Operations (DNSOP)
> WG
> of the IETF.
>
>    Title:   Domain Control Validation using DNS
>    Authors: Shivan Sahib
>             Shumon Huque
>             Paul Wouters
>             Erik Nygren
>             Tim Wicinski
>    Name:    draft-ietf-dnsop-domain-verification-techniques-09.txt
>    Pages:   18
>    Dates:   2025-07-07
>
> Abstract:
>
>    Many application services on the Internet need to verify ownership or
>    control of a domain in the Domain Name System (DNS).  The general
>    term for this process is "Domain Control Validation", and can be done
>    using a variety of methods such as email, HTTP/HTTPS, or the DNS
>    itself.  This document focuses only on DNS-based methods, which
>    typically involve the Application Service Provider requesting a DNS
>    record with a specific format and content to be visible in the domain
>    to be verified.  There is wide variation in the details of these
>    methods today.  This document provides some best practices to avoid
>    known problems.
>

Thanks for putting this together.  A few points to raise as you head toward
WGLC:

(1)  Section 5.1 says multiple RDATAs are to be treated as concatenated.  I
assume that means this sort of setup, for example:

_example_service-challenge.example.com.  IN   TXT  "3419...3d206c4"
    IN TXT "rbviluteebttjhihtvfbtrbjcdiihibu"

Maybe I'm not remembering correctly, but could these not be returned in
arbitrary order, making the result non-deterministic?

If you actually mean multiple "character-string"s are to be concatenated,
isn't that what RFC 1035 says anyway?

(2) The ABNF in Section 5.1.2 needs to be broken apart (i.e., it's
formatted funny in this version, or at least it renders funny in HTML).

(3) The SHOULD in Section 5.2 is curiously constructed.  I would suggest
something like "names SHOULD be registered".

Also, I wonder if some sort of hierarchical naming might be helpful here.
It might be tedious for IANA (or whoever) to register everything one might
want to verify, versus registering provider names only and letting them use
any sub-name they choose without registration.

(4) In Section 5.1.2, the ABNF for "value-char" lists "+" twice.  Also I
suggest considering importing a key-value ABNF pair that's already used
someplace else that's more general, maybe DKIM or MIME.  If you decide you
want to include a comma someday, for instance, this will all have to be
revised, but why not anticipate it and make this more general?

(5) Nearly all of the SHOULDs in here had me asking "Why isn't this a
MUST?"  For instance, why would you not do the base32 encoding thing that's
currently a SHOULD?  Or what's the impact if you don't?

(6) For Section 5.1.2, is there any benefit to registering known metadata
keys to avoid collisions in meaning?

Thanks for your consideration,

-MSK