> On 5 Feb 2025, at 6:50 am, Joe Abley <[email protected]> wrote: > > Hi Geoff, > > On 5 Feb 2025, at 12:34, Geoff Huston <[email protected]> wrote: > >>> By my reading, RFC 6761 and the registry it created are all about how a >>> domain name should be used, not its provenance. There's no special handling >>> required by clients, stub resolvers, recursive resolvers, forwarders or >>> authoritative servers for names in the INTERNAL domain, >> >> You may assert as such Joe yet section 5.1 of the draft makes such a case >> using the criteria of RFC6761.. Accordingly, I fail to appreciate your >> assertion, unfortunately. > > I found Paul's list of answers to the 6761 questions quite accurate. I > presume you did not, or you would presumably agree that the associated > criteria are not met. Can you say more about why you disagree with Paul's > summary? > > I don't think section 5.1 of the draft provides good guidance to the > contrary, either. I'll show my working: > > Q1: there is nothing special about how these names are used by end-users > > Q2: there is nothing special about how these names are used by applications > > Q3: there is nothing special about how these names are used by name > resolution APIs and libraries > > Q4: there is nothing special about how these names are used by resolvers > > Q5: I disagree with the text in the document; the described special handling > is in fact completely standard handling; I see nothing special about how > these names are used by authoritative servers. > > Q6: Similarly to Q5, this is completely standard behaviour. There is nothing > special about .INTERNAL here; the text describes precisely what I might do > with the zone INTERNAL.STRANDKIP.NL which does not exist in the public DNS > but which might well have meaning inside my home network. > > Q7: There is also nothing special here: registries and registrars cannot > possibly allow someone to register a name in a TLD that does not exist. > > RFC 6761 section 3: > > [...] if declaring a given name to be special would result in > no change to any implementations, then that suggests that the name > may not be special in any material way, and it may be more > appropriate to use the existing DNS mechanisms [RFC1034 > <https://www.rfc-editor.org/rfc/rfc1034>] to provide > the desired delegation, data, or lack-of-data, for the name in > question. > > This all seems quite clear to me; neither the INTERNAL name itself nor any > name in the INTERNAL domain is "special in any material way".
Hi Joe Obviously, the text in the draft in section 5.1 differs here from your assertion about "nothing special" in a number of points, but It would be kinda pointless here for me to cut and paste, as its already in the draft. The draft also helpfully notes how this case is aligned to similar previous cases (RFC6762, and sec 6.5 RFC6761). I found the text in the draft that describes the user expectation regarding non-uniqueness of these names, the particular caveat about applications' use of cookies, the advice that server operators should configure that auth DNS servers to act as authoritative for these domains if they are using such domains, and the strictures placed on DNS registries/registrars to be substantive in terms of requirements for special handling, and based on previous cases used for listing in RFC6761 it forms an adequate case that meets the criteria as described in RFC6761. But even this paraphrasing falls perhaps too close to merely cutting and pasting from the draft so I'll stop here.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
