[DNSOP] Re: Is .INTERNAL a special use domain name?

[Mark Andrews <[e-mail]>]

> On 14 Feb 2025, at 07:04, Philip Homburg <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]