On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson <mcr+i...@sandelman.ca>
wrote:
>
> 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.
>
There are cases - quite common - where the Homenet Authoritative server
does not exist. In such cases, the Homenet Resolvers just caches what is
published outside.
>
> > 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.
>
> We do mention in the version 21 that going outside has some privacy
implications. Note also that the resolver only goes outside once the TTL
has exceeded so that is not every time a DNS request is received.
> [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.
>
> Yes. answers and tradeoffs are indeed quite numerous and we can hardly go
beyond such a recommendation. Consider that the homenet an authoritative
server may not exist or the Homenet Naming Authority may play multiple
roles. Also keep in mind that our document is mostly focused on the Homenet
Naming Authority and Distributed Manager, not so much on the naming
architecture of the home network. As a result, strong recommendations
regarding the resolver may be a bit out of scope of the document.
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
