Moin! On 2 Dec 2024, at 20:29, Carroll, William wrote: > [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. I am not saying you introduce new behavior here, but you could describe what the result in DNS is for the referral response when you re name the host object. There must be some or maybe not, but I am not well versed in how registries work as I mostly work on the recursive DNS side these days. Let’s take the example from section 4. The referral for domain2.example normally would look like this: ;; AUTHORITY SECTION: domain2.example. 172800 IN NS ns1.domain1.example. domain2.example. 172800 IN NS ns2.domain2.example. ;; ADDITIONAL SECTION: ns1.domain1.example. 172800 IN AAAA 2a01:db8:1:1f::24 ns2.domain1.example. 172800 IN A 192.0.2.2 Now after renaming ns1.domain1.example. to ns1.example.org. would it look like this: ;; AUTHORITY SECTION: domain2.example. 172800 IN NS ns1.example.org. domain2.example. 172800 IN NS ns2.domain2.example. ;; ADDITIONAL SECTION: ns2.domain1.example. 172800 IN A 192.0.2.2 Is this correct or if not how would it look and does renaming always have to be outside of the TLD or can it be inside as well (making lookups potentially faster)? > [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). A resolution service for me normally is a recursive service which is defined in 5.1.3.3 to MUST NOT. So I found that wording a bit strange as we want an authoritative answer. Answering NXDomain or 127.53.x.x IMHO is bad as the resolver will try to look it up again or follow it (asking itself ;-). Refused has been the correct answer since 2009 at least when Peter Losher gave this talk at NANOG: https://archive.nanog.org/meetings/nanog45/presentations/Wednesday/Losher_light_harmful_N45.pdf and even he refers to this being an old discussion as I am pretty sure that all the authoritative servers I ran in the 2000s answered refused for zones they were not responsible for. A lot of TLDs do answer REFUSED today and see no ill effects, otherwise we would have heard at DNS-OARC and having a defined response IMHO for this is better then having lots of different responses, unless there are compelling reasons for different responses. So long -Ralf ——- Ralf Weber -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
