On Tue, Jul 11, 2023 at 07:06:49PM +0000, Hollenbeck, Scott wrote:
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>
> The draft includes descriptions of current known practices and
> suggests that some should be avoided, some are candidates for "best",
> and there are others that haven't been used that might also be
> candidates for "best". The authors would like to learn if others agree
> with our assessments and/or can suggest improvements.
Thanks for reaching out, I'll do my best to share what I hope is a
sensible perspective. But first some followups to already posted
feedback.
On Tue, Jul 11, 2023 at 03:22:40PM -0700, Brian Dickson wrote:
> For example, the registrar for the domain that is the parent of a host
> entry, should be able to "disavow" a particular reference (delegation
> to said host). It would be the responsibility of the other registrar
> (for the domain being disavowed) to clean up the broken delegations.
> This is basically giving authority to the DNS operator as a party to
> the situation, even if only indirectly.
Just checking the intent here, I think you're saying the "disavowal" is
potentially a case-by-case option. So that e.g. at the time that DNS
service for a domain is discontinued, the DNS operator (perhaps via
their registrar) should be able to break drop NS records from a
*particular* delegation.
This is an interesting proposal. It reasonably aligns with the
operational reality that it takes mutual agreement between two parties
to provide working DNS for a domain that isn't self-hosted.
In the DANE/DNSSEC survey, I am tracking almost ~350k zones (out of
~22.8M) with no SEP, roughly half of which are just lame delegations
(the listed servers return "REFUSED"), but for various reasons it is
difficult for the former DNS operator to get the delegations terminated.
The chief difficulty here is that this does not work for "external"
nameserver objects. If we're really going to solve this problem, the
solution should I think also work for the case when the nameserver and
the client zone live in different registries.
We need a protocol by which such disavowal can happen regardless of
where the nameserver might be found.
Of course if that's too difficult to solve in a timely manner, and we
can reduce barriers in host object management within a registry, that's
fine too, and the larger goal need not hold up progress on the more
focused problem.
> Maybe having the otherwise dangling or otherwise blocking references
> converted to their respective in-bailiwick names might be a solution. E.g.
> if domain2.example had an NS record pointing to ns1.domain1.example, and
> domain1.example were deleted (or ns1.domain1.example were deleted), having
> the reference converted (by whom??) to ns1.domain2.example would suffice.
> But, that would also require picking a new IP address to use for the glue
> for that (new) host object. It's a thorny problem, a real can of worms.
In the most typical situation, the servers in question will have for
some time already discontinued DNS service for the objects to be
removed, and the dependent domain loses nothing (only gains!) from
having the no longer willing nameservers deleted.
Therefore, my take is that the delegation NS record should be simply
removed from the dependent zone. No renaming, or other steps to paper
over the issue. Subsequent replacement is up to the owner of the
dependent zone. Indeed if everything was done optimally, the dependent
delegations would have proactively switched to working nameservers
first.
Now we do want to prevent accidents, and so deletion of host objects
that are still used as nameservers by zones not being deleted should
perhaps require some form of confirmation that some dependencies are
being forcibly broken. How to do that, and whether confirmation should
actually require the requesting party to submit a second request, ...
is user interface design that should be discussed with care. I don't
claim to have the right answer on how to balance safety vs. usability.
> This means that unrelated glue records could point at the same IP
> address, even if the host records are distinct with different owners.
> First-to-register does not guarantee that the correct ownership could
> be determined by creation time (i.e. it's a race condition without a
> stronger mechanism.)
Explicit disavowal should be able to solve this too, if the IP addresses
targetted can be reasonably safely (multiple samples over a period of
time, or a confirmed request from the point of contact for the IP space,
...) determined to be refusing service for the disavowed zones.
So my own position is that:
- The host object owner should be able to delete it at will, with
any friction solely to help avoid difficult to recover accidents,
rather than prevent the nameserver owner/operator from
discontinuing service.
- The dependent zones would then have the corresponding nameserver
entries deleted (not renamed, ...).
- Of course nameserver operators should have a communication channel
with contact persons the domains they serve, and should first prod
them to move to alternative arrangements when service is slated to
be discontinued.
- When a delegation is still listing stale nameservers, the
best-practice communication process has broken down somewhere
along the way, and we're no longer in the realm of
"best-practice".
- Disavowal of specific relationships, well short of removing the
host object for everyone is IMHO a good idea. This should work
across, not just within, registries. And should work for
IP-aliased servers.
- That is, a target nameserver whether by name or IP address should
be able within a reasonable timeframe to drop a delegation to
which it no longer consents.
The last two items are of course more of a wish list for a future state
than a current "best-practice". The earlier items could be practicable
today.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
