Roman Danyliw via Datatracker <nore...@ietf.org> wrote:
> [per -18] I’m not sure if this my misreading of the behavior of
> internal clients. To clarify, the (internal) Homenet DNSSEC Resolver
> will “... resolves the DS record on the Global DNS and the name
> associated to the Public Homenet Zone (myhome.example) on the Public
> Authoritative Servers.”? Why would the internal resolver serving a
> request for an internal client for an internal service go to the Global
> DNS if the information if it could come from the internal Homenet Zone
> it is already configured with?
Because it needs the glue records to prove it is authoritative.
> As an operational consideration, why go
> outside of the network if you don’t need to? As a privacy
> consideration, why leak the request to an outside entity if the network
> already has the information.
> [per -20] Thanks for the revised text: On the other hand, to provide
> resilience to the Public Homenet Zone in case of WAN connectivity
> disruption, the Homenet DNSSEC Resolver SHOULD be able to perform the
> resolution on the Homenet Authoritative Servers.
> -- Is there a reason this can’t be a MUST?
If the resolver and cache have been offline for long enough, any cached chain
of DS/NS/DNSKEY records from . down to the myhome.example might have expired.
(Consider a DNSSEC resolver on a host behind the gateway)
What to do in this situation has many answers with different tradeoffs.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
