But this name we are encouraging use of. That makes it different. Delegate internal to the existing root servers with an insecure delegation. The zone contents are just the SOA record and the NS records. This zone is not signed. This breaks the DNSSEC chain of trust. Encourage .internal to be on every recursive resolver by default as an empty zone. This absorbs most of the leaked traffic for .internal. Encourage sites that use .internal to transfer the root zone so they have an up to date copy of the non existence proof of internal/DS. This will absorb most of the remainder of the traffic.
This gives those that want to use .internal the same stable base we give those that use 10.in-addr.arpa. Reserve the name or not but if it is reserved MAKE IT WORK. -- Mark Andrews > On 7 Feb 2025, at 06:07, Paul Hoffman <paul.hoff...@icann.org> wrote: > > On Feb 6, 2025, at 10:55, Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> (with no hats, and perhaps less sense) >> >> I agree .internal should be a special use name. I don't see why it's that >> big an issue. >> > > For me, it's a big issue because .internal is not in the root zone, just like > zillions of other names that are bit in the root zone. .internal has *no* > SUDN features that are at all different than those zillions. > > If there was a way to put a wildcard entry for the SUDN registry labelled > "Names that are not in the root zone", I agree that we should write one; my > reading of RFC 6761 is that such an entry is not permitted. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
