Hi! Please see an response to below to Michael’s email:
From: Daniel Migault <mglt.i...@gmail.com> Sent: Monday, October 31, 2022 9:02 AM To: Michael Richardson <mcr+i...@sandelman.ca> Cc: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org>; draft-ietf-homenet-front-end-naming-delegat...@ietf.org; homenet-cha...@ietf.org; homenet@ietf.org; stephen.farr...@cs.tcd.ie Subject: Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT) Hi Roman, This is just a follow-up. Currently we believe we have addressed your concerns, but we would like to double check if there are any other concerns/questions you would like us to address. Yours, Daniel On Thu, Oct 27, 2022 at 3:43 PM Daniel Migault <mglt.i...@gmail.com<mailto:mglt.i...@gmail.com>> wrote: On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> wrote: Roman Danyliw via Datatracker <nore...@ietf.org<mailto: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. [Roman] I’m not sure that I follow all of the trade-offs. Let me try to restate things at a higher-level. “Pre-HOMENET” Without HOMENET, home users relied on a approaches such as those described in Section 1.2 of -18 of this draft (this text has now been removed). One way I understood such configurations to work is that you might use dynamic DNS to map the carrier provided publicly routable IP address to a hostname. With IPv4, the CPE would then do “port forwarding” for that service to be accessible remotely since the home network likely only got one IP address. With IPv6, the home network would get a prefix so the machines behind the CPE would each have publicly routable IP addresses. CPEs might also provide an internal resolver to answer for the names assigned to the devices on the home network to serve users on the home network. DNS resolution for clients on the home network to access a home network server: -- … visible outside of the home network: NO -- … usable if CPE-to-carrier link goes down: YES “HOMENET solution” With all of the proposed roles and flexibility in the architecture, isn’t there increased visibility of previously private network behavior and reduced resiliency. DNS resolution for clients on the home network to access a home network server: -- … visible outside of the home network: YES -- … usable if CPE-to-carrier link goes down: NO I’m wondering if this name delegation approach could be deployed in a way to keep the “Pre-HOMENET” properties as described above? Roman
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
