[WC] Can you clarify the question? I'm not sure how the IPs are relevant. When an object (e.g., ns1.to-be-deleted.com) is renamed, requests for the previous name should receive a non-existent response as the previous name is no longer in the zone. Do we need to specify that if ns1.to-be-deleted.com is renamed to ns1.sacrificial-ns.org, then here are no assurances that ns1.sacrificial-ns.org will resolve, offer DNS service, or respond to queries for to-be-deleted.com with a positive or negative response (see RFC 2308 and RFC 9520)? It seems like we are not introducing any new behavior there, but maybe I'm misunderstanding the question. Second on section 5.1.3.4 the text on if I should run an resolver or an authoritative answer for the sacrifical name server host and what the answer actually is. Now there might have been discussions about that that I am not aware of and there may be a reason for the text, but if so it should be noted. My rather simple view on this if I had to run such a server I would answer REFUSED to all the queries I got. [WC] We deliberately left it somewhat open to the operator: "The sacrificial name server should run a DNS resolution service capable of responding with an authoritative non-error, non-failure response for requests made for associated domains. The service SHOULD provide responses that indicate problems with a domain's delegation, such as non-existence or include controlled interruption IP addresses." REFUSED could be problematic (at least until all recursives are RFC 9520 compliant-see RFC 9520 §2.2). Not related to this draft, but I am happy that the so far proposed DELEG solutions will solve the problem as there no longer is a need for a host object, but as we are not there yet this document is badly needed, so please keep up the good work and if there is anything I can help please reach out. So long -Ralf -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
