Hi Swapneel, This is a valuable work. Some remarks below:
4.1. Domain Name Lifecycle / 4.5. Identifier AttributionI 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 ValidationThe 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. CompletenessThis 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 AttributionDNS 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 InterfacesDomain 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
