On Mon, Mar 3, 2025 at 2:05 PM Carroll, William <wicarr...@verisign.com> wrote:
> > > 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 > I still think the "sacrificial" term is weird. When I think of a sacrifice, it is something that is "used up". It vanishes. But these nameservers are 'permanent'. But if the ICANN terminology uses the term, then I guess the ship has sailed. So I think the proposed change improves it as best we can now. > 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 > ). > Perhaps something can be said about both these things in the Operational Considerations section? > 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. > Sounds good. > 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). > Perhaps just removing the suggestion of adding a new Special Use top level domain? > 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. > Sure. > 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. > See above. I think the term is wrong on the context it is used, but if it is all over ICANN docs, it is too late to change it and it is better to sync up the terms used there and here. Although I personally still prefer not using it in the FQDN, and prefer "deleted-ns.invalid" I recognise that is a personal preference. 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? > You are right. I guess if those DNS resolvers get too many of these, they might finally properly implement the .invalid resolving issue :) Paul
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
