I agree: transferring records blindly from a previous owner of a domain would be bizarre. However, the draft currently says:
> Subsequent validation actions using an already disclosed token are no > guarantee that the original owner is still in control of the domain (https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-07.html#section-4.3-2) This sentence is only true if the old record could have persisted after a change in ownership. Evidently, the idea that records are not preserved across ownership transfers is not obvious to everyone. That's why I think we need to make it explicit. --Ben ________________________________ From: John Levine <[email protected]> Sent: Wednesday, June 11, 2025 6:28 AM To: [email protected] <[email protected]> Cc: Ben Schwartz <[email protected]> Subject: Re: everything bagels, Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques) It appears that Ben Schwartz <[email protected]> said: >-=-=-=-=-=- > >I think this PR is a fine direction, but it still seems to contain a certain >amount of internal confusion. If the security "relies on the >causal relationship", then how can it be secure for persistent validation? >What is the value of knowing that "either the DNS >Administrator of the domain has not chosen to remove the Validation Record or >that a new owner of the domain has re-introduced the >Validation Record"? > >In my view, the core problem is that the draft is dancing around an unstated >but essential requirement, for all DNS zones on the internet: > >0. We define Validation-Controlling Entries (VCEs) as any records or >delegations at underscore-prefixed or wildcard names. >1. Zone owners MUST NOT allow other parties to add or modify a VCE unless the >owner name's next label is uniquely assigned to that party. >2. Zone owners MUST NOT add a VCE without understanding and approving its >function. >3. When acquiring a zone, the new owner MUST promptly remove all VCEs whose >function is not understood and approved. I don't think any of this is wrong per se, but I also think it is vast overkill, the threats are largely if not entirely hypothetical, and this will add a lot of complication that distracts from the goal of this draft, to provide a consistent form for these records so you can tell where they're from and if they're likely still to be useful. For example: >3. When acquiring a zone, the new owner MUST promptly remove all VCEs whose >function is not understood and approved. I dunno about you, but when I have bought or sold domain names, the transfer has never ever included a copy of the existing DNS zone. The new owner has new nameservers and sets up all new DNS. One time I persuaded a buyer to keep my MX for a while to help move mail users but that was a one-off and totally manual. While I believe that one might in theory do an on-path attack to do fake DCVs, unless someone can show some real examples I would not confuse people by talking about it. It's no different from faking any other DNS record. R's, John
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
