On 2025-02-06 08:56 +01, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: >> What we all keep ignoring is that .internal DOES NOT WORK WITH >> BRING YOUR OWN DEVICE scenarios Reverse for RFC1918 addresses >> work with BYOD because we have public AS112 servers that serve >> UNSIGNED reverse zones. This breaks the DNSSEC chain of trust >> cleanly allowing the zones to be used by everyone. We have >> FAILED to do this for >> .internal. So either every device needs to know a priori that DNSSEC >> doesn't work for .internal which makes it a special use domain >> or we add .internal to the root with an insecure delegation to >> break the chain of trust cleanly. > > I think it is clear that IANA (or ICANN) do not want a delegation in the > root for internal. So we need to find another way. > > It is safe to say that the only software running on a host that needs > to be aware of .internal is software that does DNSSEC validation. Most stub > resolvers, non-validating forwarders, etc. They don't need to do anything > special. > > So the requirement we should place on validators in that they come by > default with a negative trust anchor for .internal.
[Dreaming of a future where every / most stubs do their own validation.] That is a very big hammer and I don't think we should do that. I agree that .internal will not work with BOYD but I'd argue that the majority of devices will not be brought to a place where they have to resolve .internal. I think having an NTA is surprising and nontransparent. It opens up devices that don't care about .internal to attacks. An insecure delegation in the root OTOH is at least transparent. > > So that would indeed make INTERNAL a special-use domain name. > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- In my defence, I have been left unsupervised. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
