Paul, Thank you for reviewing and the helpful comments. I've added responses inline below with [WAC]. Bill
On 3/2/25, 8:18 PM, "Paul Wouters via Datatracker" <nore...@ietf.org <mailto:nore...@ietf.org>> 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. Paul Wouters has entered the following ballot position for draft-ietf-regext-epp-delete-bcp-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-delete-bcp%2F ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clear description of the problem and the operational and security issues involved. I think this is good work to get a BCP for to reduce harm. Some of my comments I left below, I felt on the border of a DISCUSS or COMMENT. I chose to leave it as COMMENTS. 5.1.3.4. Renaming to Sacrificial Name Server This description does not seem to match the idea of "sacrificial" name server. It is more a dedicated nameserver maintained by the client/registrar. Maybe "Last Resort Name Server" is a better name? [WAC] We think it still falls under the definition of sacrificial name server from 5.1 but are open to clarifying it. SAC125 calls these "Per-Registrar Non-Registrable Sacrificial Namespace" (see https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-25-09-05-2024-en.pdf). The [risky-business] paper calls these "dedicated sink domains" (see https://doi.org/10.1145/3487552.3487816). Proposed change: - 5.1.3.4. Renaming to Sacrificial Name Server Host Objects Maintained by the Client + 5.1.3.4. Renaming to Client-Maintained Dedicated Sacrificial Name Server Host Objects The name server MAY provide any valid response. This one is tricky. Of the domain using the host object has other still valid nameservers, it would be better to ServFail. If there are no more other valid nameservers, resolving everything to a dedicated IP running a webserver hosting a message "no valid nameservers for this domain" could be useful. But such a message is harmful if the domain has other still functional nameservers. [WC] We previously had more specifics about responses (see https://www.ietf.org/archive/id/draft-ietf-regext-epp-delete-bcp-08.html#name-renaming-to-sacrificial-nam ) but were encouraged to make it more generic after the DNS Directorate review. We were concerned that returning SERVFAIL or REFUSED could lead to aggressive requerying in resolvers that are not compliant with RFC 9520 (see https://www.rfc-editor.org/rfc/rfc9520.html#name-motivation and https://www.rfc-editor.org/rfc/rfc9520.html#name-conditions-that-lead-to-dns). 5.1.4.2.1.2. Practice Detriments These TLDs are reserved for experimentation or testing. Their use is confusing and does not signal the client's intent. Their use may be prevented by policy. The first two sentences are not correct when ".invalid" is used. The last sentence seems a weak argument. I think ".invalid" would make a good solution here, and I would turn around the last sentence and make this document state that use of .invalid SHOULD NOT be prevented by policy. [WAC] Good catch, thank you. Proposed change: 5.1.4.2.1. Renaming to Reserved TLD Clients may rename host objects to use a reserved special-use ([RFC6761]) TLD as suggested in [risky-bizness]. ... 5.1.4.2.1.2. Practice Detriments The use of TLDs reserved for special purposes ([RFC6761]) may be confusing without a domain designated by the community for this purpose (see "sacrificial.invalid" in 5.1.4.3 and 6). In addition, their use may be prevented by EPP server policy. 5.1.4.3. Renaming to a Special-Use Domain Only after reading 5.1.4.3 do I realise that 5.1.4.2 meant only "invalid." as FQDN when it said ".invalid" and not SLDs inside .invalid. That is not obvious to the reader and I think should be explicitly stated. (Or 5.1.4.3 could be removed with some text moved into 5.1.4.4?) I think adding another name string Special Use Domains should be avoided. There are attempts to stop allowing Special-Use domains entirely, and taking up a "nice name" also takes that name away for real registration in the future. One could instead use something like invalid.arpa or broken-ns.arpa instead? (Oh, I see that is what 5.1.4.4 is doing) [WAC] Do you have a suggested change? We recommend the use of sacrificial.invalid, which would not require a new special-use TLD, as RFC6761 already includes "invalid" (ยง6.4). I feel Section 5.2 has little to do with IETF and protocols, and is much better handled in other venues? Like ccTLD orgs and/or ICANN ? It is harmless here, but any BCP guidance in this section is not protocol guidance but guidance for the RRR-model. [WAC] We felt that this is appropriate because it's a best practices document for EPP operations. I strongly dislike the term "sacrificial.invalid". Registrants will not have an intuitive grasp for what this means. For example "deleted-ns.invalid" would convey a much clearer signal of what has happened. Furthermore, "sacrificing" implies that this situation is about to change, which is almost never what is described here. It is a lasting change until the registrant or registrar fixes the domain delegation. [WAC] It seems like "sacrificial" has become a new term of art and may be useful for clarity in technical discussions. The first appearance of this usage that I can find is Gautam's 2020 "Unresolved Issues" paper (see https://ris.utwente.nl/ws/portalfiles/portal/237707459/Akiwate2020unresolved.pdf), but it has also been used in ICANN registrar communications (see https://www.icann.org/en/system/files/files/registrar-sacrificial-name-servers-use-risks-09jan23-en.pdf and SAC125). Can you clarify why you think it implies imminent change? It is difficult to predict registrant understandings. Registrants who notice the change will probably search for explanatory articles, whether their domain's new NS host shows up as [some string].sacrificial.invalid or [some string].deleted-ns.invalid. I am not sure if the document has properly taken into account whether queries in the "sacrifcial name" in the various solutions would be handled and eaten by the Recursive DNS or be forwarded to the root nameservers. This might depend on the name used as well. But for example, my unbound nameserver (and Quad9) seem to synthesis the .invalid response, thus suppressing queries to the root, while Google DNS and Cloudflare seem to return a SOA of the root zone, implying it might have actually sent the query to the root. This might cause quite some load if a popular domain were to end up in such a bad situation. [WAC] Yes, some leakage is possible, but we think it is less damaging than malicious domain hijacking. Our recommendation for sacrificial.invalid depends on caching resolver compliance with RFC6761 "Caching DNS servers SHOULD recognize 'invalid' names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve 'invalid' names." But if recursives return NXDOMAIN and the root's SOA record (which has a reasonable 86400 negative TTL), is that likely to be a problem? _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
