Hi John, On 17 Jun 2025, at 17:56, John Levine <[email protected]> wrote:
> It appears that Petr � pa� ek <[email protected]> said: >> This is provably incorrect. 10.in-addr.arpa is an insecure delegation >> which with network-dependent content, and it works for decades. ... > > I dunno about you, but on all the systems I use the local cache substitutes > a stub for 10.in-addr.arpa so it doesn't matter what the global DNS says. 10.IN-ADDR.ARPA exists in the global namespace, and is an insecure delegation from the IN-ADDR.ARPA zone. INTERNAL does not exist in the global namespace, and its non-existence is provable using DNSSEC. These things are not quite the same. My understanding is that some people are worried about: - mobile device, regularly roams between different networks - device has its own resolver cache, but uses network-provided nameservers - device does its own validation - device manages to cache the non-existence of .INTERNAL while using nameservers that do not reveal the existence of that domain - device subsequently relocates to a network whose local nameservers do serve responses under .INTERNAL - device fails to accept .INTERNAL names because they contradict with the signed non-existence in the cache - hilarity ensues I have not seen this use-case myself but I can appreciate that the imagined device in this example might have an ambiguous situation to deal with. > I don't see any way to reconcile those. The draft we just submitted and that I just sent a clickbaity message about proposes a lightweight method to reduce the ambiguity. https://datatracker.ietf.org/doc/draft-jabley-dnsop-zone-cut-to-nowhere/ Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
