Mark,
I believe that any distributed system that won’t have a fallback to the RZ
is inevitably doomed and will get out of sync.
The RFC7706 works because there’s always a safe guard and if the resolver
is unable to use mirrored zone, it will go to the origin.
Call me a pessimist, but I’ve yet to see a loosely often neglected distributed
system
that won’t get out of sync.
So, while the idea of distributing the full RZ to every resolver out there,
there are two
fundamental problems:
1. resilience - both against DoS and just plain breakage
2. the old clients - while the situation out there is getting better, we will
still be stuck with
old codebase for foreseeable future
What we can do is to make the load on RZ servers lighter, but we can’t make
them just go.
Ondrej
--
Ondřej Surý
[email protected]
> On 26 Nov 2019, at 14:41, Mark Allman <[email protected]> wrote:
>
>
> Let me try to get away from what is or is not "big" and ask two
> questions. (These are legit questions to me. I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
>
> (1) Setting aside history and how things have been done and why
> (which I am happy to stipulate is rational)... At this point,
> are there tangible benefits for getting information about the
> TLD nameservers to resolvers as needed via a network service?
>
> (2) Are there fundamental problems that would arise in recursive
> resolvers if the information about TLD nameservers was no longer
> available via a network service, but instead had to come from a
> file that was snarfed periodically?
>
> Thanks!
>
> allman
>
>
> --
> https://www.icir.org/mallman/
> @mallman_icsi
> _______________________________________________
> dns-operations mailing list
> [email protected]
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
