Hi Ralf, Thanks for the clarifications! My responses are inline with [WC2]. Bill
On 12/3/24, 3:50 PM, "Ralf Weber" <ralf.we...@akamai.com <mailto:ralf.we...@akamai.com>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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)? [WC2] That looks correct to me, but I would be reluctant to add this much detail. Other EPP RFCs do not (as far as I can tell) give this level of DNS response details and do not describe the details of renaming operations. How registries handle the renaming of a host object and its address records may vary according to registry policy. For example, some registries require an address record for every internal namespace host (even if they are not in-bailiwick or necessary as glue). They may also require that those address records be explicitly deleted (as part of the same update) when the host is renamed to an external namespace. -- > [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: [URL] 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. [WC2] I think there's evidence of problems with REFUSED. From RFC 9520: "In 2021, Verisign researchers used botnet query traffic to demonstrate that certain large public recursive DNS services exhibit very high query rates when all authoritative name servers for a zone return refused (REFUSED) or server failure (SERVFAIL) responses." The RFC is referring to a presentation by Duane Wessels and Matt Thomas at DNS-OARC (compare NXDOMAIN on slide 18 to REFUSED on slide 19): https://indico.dns-oarc.net/event/38/contributions/841/attachments/809/1430/verisign-sinkhole.pdf If I'm reading their slides correctly queries-per-second (QPS) increased from 100-300 QPS with NXDOMAIN/NOERROR/NODATA to 10,000 - 40,000 QPS with REFUSED. Would this change be acceptable to you? (thanks to Duane for suggested language on the first sentence) "The sacrificial name server should resolve to one or more IP addresses and the client should operate an authoritative DNS name server on those addresses. The name server SHOULD provide responses that indicate problems with a domain's delegation, such as non-existence or controlled interruption IP addresses." I think a REFUSED response would also qualify as indicating problems. _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
