[DNSOP] Re: Request Feedback: draft-sheth-dns-integration

[[e-mail]]

Hi Swapneel,

This is a valuable work. Some remarks below:

4.1.  Domain Name Lifecycle / 4.5.  Identifier Attribution

I would add any other changes to the technical configuration which might 
affect the integration (such as change of delegation).

Also an aspect of an owner of a domain name being blocked from usage of 
the name at an integration should be mentioned in both cases if the 
ownership would change but also if the integration would not verify at 
all and allow blocking names as a result.

One additional observation that might be mentioned is that DNS and 
domain registration ecosystem is currently lacking an effective 
mechanism of assuring this recommendation other than polling over 
existing protocols (WHOIS/RDAP/DNS) to figure out any change that might 
have happened. Even this would be limited only to visible changes and 
not all changes if some data would be redacted.

4.2.  Domain Control Validation

The draft mentions "storing evidence directly on a server referenced by 
a DNS domain name". Later it indicates the intention to verify that the 
current registrant is performing the integration. I think at least some 
text should be added about the level of indirection that domain control 
validation should accept as well as the goal of the validation. Even 
with the usage of DNS there is the TLD registry which actually deals 
with the "current registrant" and the Nameserver handling the zone which 
may be already controlled by other party who would be able to 
successfully complete the validation. Next level of indirection to a 
(web) server would be one additional step away from the registrant. Some 
integrations would just have a goal to assure technical control over the 
name in DNS or webserver, others would really seek to have a 
confirmation from the registrant, so maybe the text should account for that.

The scope of the validation, which is very broadly described in 
ietf-dnsop-domain-verification-techniques shall also here be taken into 
consideration.

4.3.  Completeness

This part could also express a stronger wish to support all names 
allowed in DNS to avoid confusion and negative domain owner experience. 
Otherwise an integration might decide "out of technical reasons" to only 
support ascii domains, which won't be in line with universal acceptance 
efforts.

4.5.  Identifier Attribution

DNS hijacking is specifically mentioned, however I think this can be 
generalised accordingly to the control validation used. If https server 
is used then new possibilities of change of control over an identifier 
outside of DNS can be open.

4.6.  Variety of DNS Management User Interfaces

Domain Connect draft-kowalik-regext-domainconnect may be mentioned as 
one of the methods of dealing with this particular issue.

Kind Regards,

Pawel

On 05.08.24 18:04, Sheth, Swapneel wrote:
 >
 > DNSOP,
 >
 > Just before IETF 120 we published a draft "Integration of DNS Domain 
Names into Application Environments: Motivations and Considerations" 
along with co-authors from Bluesky and Ethereum Name Service.  You may 
have seen us socializing it at the hackathon and HotRFC or heard the 
request for feedback during Thursday's DNSOP session when the chairs 
mentioned it during the "Drafts of Note" of section.
 >
 > During IETF 120 we received a lot of good feedback around this draft 
and would like further feedback!  Since the initial 00 version, we have 
changed the draft to informational and are in the process of evaluating 
how best to incorporate the other feedback we received.
 >
 > The goal of this draft is to provide informational guidance to 
communities who are trying to incorporate DNS domain names into their 
applications.  The draft currently provides motivations for why 
applications opt to utilize domain names and qualities that applications 
should consider as they build and maintain their integrations, e.g., 
having processes in place to account for domain name lifecycle events or 
DNS protocol evolution.  We would appreciate feedback on the current 
draft and other motivations/qualities we should consider including that 
would make this draft as useful as possible to these communities.
 >
 > We would be happy to take feedback here on the mailing list.
 >
 > Thanks,
 > Swapneel Sheth