On Thu, Nov 9, 2023 at 10:21 AM Marc Blanchet <[email protected]> wrote:
> Hello, > I presented draft-many-dnsop-dns-isolated-networks Tuesday at the end of > dnsop meeting. Thanks for letting me present. Wanted to come back to a few > points raised. > > - About use cases, I see the dnsop Zulip chat that some people were > interested in the topic, noting about additional use cases (antarctic for > example). I guess I did not touched enough on this because of limited time, > but there are many « mostly isolated, often unconnected » networks use > cases being discussed in various wgs. I think the best place to see those > are in the Time-Varying Routing wg requirements and use cases documents > (draft-ietf-tvr-requirements, draft-ietf-tvr-use-cases). Examples such as > solar energy powered networks, power savings networks, remote networks, > many are the resource constrained networks where connectivity is not > permanent, others having dynamic reachability. These drafts were not > written for the purpose of DNS, but routing, but they all applied almost as > is to the need of what is discussed in the isolated-networks draft. > - local names: as these networks are in fact sometimes connected > (sometimes meaning more than exceptional), names need to be global so that > both networks are able to resolve names. Local scope names may be in > addition to global names, but not a replacement. > - while some use cases like deepspace will take time to be deployed, those > organizations involved are planning years ahead and need stable technical > references that are used as requirements to vendors, RFPs, designs, etc…. > In fact, it is useful now. Some other use cases could benefit it right away > for implementing. > I feel it is hard to provide generic solutions without knowing the actual requirements, and solutions can widely vary depending on those requirements. Are the "isolated network" actually stable on the other side? or can they also be subject to poor network quality? Are the lion share of queries internal to that possibly isolated network, or external connections are quite prevalent? Are we talking about operators trying to access resources, or machines needing to talk to each other? For the latter they can be a case where one may want to avoid the extra dependency on DNS because then you have a critical system in a hard to access environment that possibly relies on an extra piece of infrastructure to be operational to operate. That being said, it is probably possible to bucket a set of requirement sets and work from there. My gut feeling is that whatever is in those remote networks needs to be self-sufficient to operate, and this probably call for a dedicated sub-zone/local domain used and served locally and authoritatively in the remote side with some form of push/zone xfr from the stable network. If the remote network may occasionally need resources from across the unreliable link, stale-answers probably go a long way, with a dash of prefetching to keep things as up-to-date as possible. TL;DR, IMHO, concrete use-cases requirements should be enumerated before a solution can be crafted. Manu > Regards, Marc. > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
