> On 14 Feb 2025, at 07:04, Philip Homburg <[email protected]> wrote: > >> Logic behind this proposal follows: >> >> #1 I can't see any difference between the intended use of: >> - 10.in-addr.arpa. >> - internal. >> >> #2 RFC 6761 section 6.1 already established special rules for >> 10.in-addr.arpa. > > The draft has the following: > The "internal" top-level domain provides this purpose in the DNS. Such > domains will not resolve in the global DNS, but can be configured within > closed networks as the network operator sees fit. > > I think that is the difference between .internal and 10.in-addr.arpa. I > expect 10.in-addr.arpa. to resolve in the global DNS. RFC-1918 address do > leak and there is no reason to expect every piece of software to have > filter in place to catch reverse DNS lookups for those addresses. > > There seems to be an argument that for the convenience of DNSSEC, private > domains have to resolve in the global DNS. Maybe we need to actually > say that in some RFC. Or solve this issue in a different way.
We do for Locally Served DNS Zones (RFC 6303) even if IANA hasn’t yet organised all of the stub delegations yet. 6. IANA Considerations IANA has established a registry of zones that require this default behaviour. The initial contents of this registry are defined in Section 4. Implementors are encouraged to periodically check this registry and adjust their implementations to reflect changes therein. This registry can be amended through "IETF Review" as per [RFC5226]. As part of this review process, it should be noted that once a zone is added it is effectively added permanently; once an address range starts being configured as a local zone in systems on the Internet, it will be impossible to reverse those changes. IANA should coordinate with the RIRs to ensure that, as DNS Security (DNSSEC) is deployed in the reverse tree, delegations for these zones are made in the manner described in Section 7. 7. Security Considerations During the initial deployment phase, particularly where [RFC1918] addresses are in use, there may be some clients that unexpectedly receive a name error rather than a PTR record. This may cause some service disruption until their recursive nameserver(s) have been re-configured. As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet. Special-Use Domain 'home.arpa.’ RFC 8375 has 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT include a DS record and MUST point to one or more black hole servers, for example, 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. Discovery of Designated Resolvers RFC 9462 has by reference that an insecure delegation is required. Note there is an errata for this section. 6.4. Handling Non-DDR Queries for resolver.arpa DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under resolver.arpa with NODATA. People are too scared of internal. NS a.root-servers.net. ... internal. NS m.root-servers.net. being added to the root zone. Where the contents of the zone served is just the SOA and NS records and is NOT signed. @ 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 1 1800 900 604800 86400 @ 86400 IN NS a.a.root-servers.net. ... @ 86400 IN NS m.a.root-servers.net. The same machines are returning NXDOMAIN for everything under internal. They return a NODATA response for all types other that SOA and NS for “internal”. Root zone politics has got in the way of good management of the DNS in the root zone. If people are expected to use a name locally then there needs to be a clean break in the DNSSEC chain of trust. Mark > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
