On Thu, Oct 27, 2022 at 3:43 PM Daniel Migault <mglt.i...@gmail.com> wrote:
> > > 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? >> > We finally put it to MUST while reviewing the SHOULD status - as requested by Murray ;-). The reason I was insisting on SHOULD is that I was reading MUST as mandating to implement the mechanism. I was literally ignoring the condition "IF you want to provide resilience ...". I apologize for the multiple round trips. > >> 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 > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
