With my implementors hat on, I do have a problem with second sentence here:
> The TTL [RFC1034] for Validation Records SHOULD be short to allow
> recovering from potential misconfigurations. These records will not
> be polled frequently so caching or resolver load will not be an
> issue.
This assumes no wrong doings, but the internet traffic is driven by mistakes
and miscreants, so the saying that "caching or resolver load will not be an
issue"
is actually not right.
On the contrary, I think the Security Considerations should address stuff like:
$ dig +noall +answer IN TXT shell.com | wc -l
85
I actually like the fact that the DCV records are kept under individual labels
and not stuffed into apex like the domain above, and I think this deserves
text into Security Considerations:
Amplification Attacks
Segmenting the Domain Control Validation tokens into individual per-service
Validation Record Owner Names has the advantage of making the individual
DNS responses smaller and thus reducing the potential of said TXT RRs to be
used in the DNS amplification attacks. It should be noted that expired and no
longer
usable tokens should be removed even from Validation Record Owner Name DNS
tree nodes to keep the DNS responses sizes at minimal level.
(Or smth-like that.)
Ondrej
--
Ondřej Surý (He/Him)
[email protected]
> On 13. 10. 2025, at 16:26, [email protected] wrote:
>
> Internet-Draft draft-ietf-dnsop-domain-verification-techniques-10.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-10.txt
> Pages: 19
> Dates: 2025-10-13
>
> 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.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-10.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-10
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
