[DNSOP] Re: Requesting feedback on draft-ietf-dnsop-integration

["Kaizer, Andrew" <[e-mail]>]

Thanks for the feedback, Henry!  We will work on some updates to see how we can add some of these thoughts in.

 

Cheers,

Andrew

 

 

From: Henry Birge-Lee <henry=[e-mail]>
Date: Wednesday, February 4, 2026 at 5:51 PM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] [DNSOP] Re: Requesting feedback on draft-ietf-dnsop-integration

 

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

Hi all, 

 

I reviewed this document and think it's a good draft.

 

One clause I noticed that I don't take issue with but wanted to comment on is:

3.2.  Domain Control Validation

"Some examples of domain control
   validation include storing data in DNS
   [I-D.ietf-dnsop-domain-verification-techniques] or storing evidence
   on a server referenced by a domain name, e.g., at a well-known
   endpoint as described in [RFC8615]."
In the PKI community, there is a subtle difference between webserver control and DNS control. 
For example, DCV methods that use evidence from web servers (e.g., http-01) are not permitted for the use of subdomain certificates.
Some would argue that evidence in the .well-known dir of a webserver proves control of the HTTP(S) server at that domain but not control of the domain itself. Since the draft is about DNS names
in applications, I think there are some applications where that type of control (webserver control) is not appropriate (or at least would not be sufficient evidence for the CAB/F).
I think the cleanest stance would be to recommend control be established in DNS and not other channels.
This text is also very vague and there are a bunch of ways of showing domain control that we no longer think are good ideas, although vagueness does allow the draft to avoid being prescriptive with this aspect.
 
 
Best,
Henry
 
https://henrybirgelee.com/