Re: [dns-operations] root? we don't need no stinkin' root!

[Ondřej Surý]

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ý
ond...@sury.org



> On 26 Nov 2019, at 14:41, Mark Allman  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
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Petr Špaček]

On 26. 11. 19 16:04, Roy Arends wrote:
> 
> 
>> On 26 Nov 2019, at 12:46, David Conrad  wrote:
>>
>> It would appear a rather large percentage of queries to the root (like 50% 
>> in some samples) are random strings, between 7 to 15 characters long, 
>> sometimes longer.  I believe this is Chrome-style probing to determine if 
>> there is NXDOMAIN redirection. A good example of the tragedy of the commons, 
>> like water pollution and climate change.
> 
> Yep.
> 
> https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/chrome/browser/intranet_redirect_detector.cc
> Line 79: "// We generate a random hostname with between 7 and 15 characters.”
> 
> https://ithi.research.icann.org/graph-m3.html
> Table "Queries to frequently found name patterns” shows that the frequency 
> distribution for queries between 7 and 15 characters are near flat (around 
> 5.2% per character length) AND an order higher than ANY other queries.
> 
> “Coincidence? I think NOT!”  
> 
> https://youtu.be/MDpuTqBI0RM?t=53

FYI there is also an issue about this in their tracker:
https://bugs.chromium.org/p/chromium/issues/detail?id=946450#c1

-- 
Petr Špaček  @  CZ.NIC
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Keith Mitchell]

On 11/26/19 7:40 PM, Mark Allman wrote:
> I wonder if we're ever allowed to just decide this sort of thing is 
> ridiculous old shit and for lots of reasons we can and should just 
> garbage collect it away.

To some extent, "get rid of ridiculous old sh*t" is kind of what the DNS
Flag Days are working on, though with rather more baby steps than I
suspect you are conceiving. Even these small, rational proposals have
met with push-back in some sectors. It's quite a lot of work to
deprecate stuff in a way that minimizes operational fall-out.

> To me, this whole notion is that we can in fact get rid of this
> giant network service.  If we don't get rid of it then what is the 
> incentive to move one's own resolver away from using the root 
> nameservers?

On garbage-collecting crap traffic, it's worth looking at AS112. Mostly
this runs on a bottom-up community-driven basis, where the incentive to
run an AS112 node comes from the simple self-interested economic basis
of not wanting this crap taking up capacity on one's own outbound
infrastructure.

While AS112 makes a difference, it is far from ubiquitous or optimal.
Probably there are gains to be made from more aggressive co-ordination
and advocacy (*), but I suspect these would need stronger resource
support from a more top-down source. It's far from the whole problem
space, but makes some difference at the root for sure.

Keith


(*) every so often I get a stark reminder of how low awareness of AS112
is...no, we don't want to buy transit for it, thanks..
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Petr Špaček]

On 27. 11. 19 9:53, Ondřej Surý wrote:
> 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.

I think there is even more fundamental problem:
Someone has to pay operational costs of "the new system".

Personally I do not see how transition to another root-zone-distribution system 
solves the over-provisioning problem - the new system still has to be ready to 
absorm absurdly large DDoS attacks.

Example:
Have a look at https://www.knot-dns.cz/benchmark/ . The numbers in charts at 
bottom of the page show that a *single server machine* is able to reply *all* 
steady state queries for the root today.

Sure, we have speed-of-light limits, so let's say we need couple hunderd 
servers in well connected places to keep reasonable latency. That's not a huge 
cost overall (keep in mind that these local nodes could be pretty small *if we 
were ignoring the over-provisioning problem*).

Most of the money is today spent on *massive* over-provisioning. As an 
practical example, CZ TLD is over-provisiong factor is in order of *hunderds* 
of stead-state query traffic, and the root might have even more.

Once we have similarly resilient HTTP system it is matter of simple 
configuration :-D
https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling

-- 
Petr Špaček  @  CZ.NIC
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Petr Špaček]

On 26. 11. 19 12:46, David Conrad wrote:
> On Nov 26, 2019, at 11:33 AM, Jim Reid  > wrote:
>>> On 26 Nov 2019, at 09:16, Florian Weimer >> > wrote:
>>>
>>> Up until recently, well-behaved recursive resolvers had to forward
>>> queries to the root if they were not already covered by a delegation.
>>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>>> was just how the protocol was expected to work.
>>
>> So what? These RFCs make very little difference to the volume of queries a 
>> resolving server will send to the root. QNAME minimisation has no impact at 
>> all: the root just sees a query for .com instead of foobar.com 
>> . A recursive resolver should already be supporting 
>> negative caching and will have a reasonably complete picture of what's in 
>> (or not in) the root. RFC8198 will of course help that but not by much IMO.
> 
> It would appear a rather large percentage of queries to the root (like 50% in 
> some samples) are random strings, between 7 to 15 characters long, sometimes 
> longer.  I believe this is Chrome-style probing to determine if there is 
> NXDOMAIN redirection. A good example of the tragedy of the commons, like 
> water pollution and climate change.
> 
> If resolvers would enable DNSSEC validation, there would, in theory, be a 
> reduction in these queries due to aggressive NSEC caching.  Of course, 
> practice may not match theory 
> (https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf).
>  

The discussion after the talk (including hallway :-) was also interesting, and 
with all respect for Geoff's work, these slides should be read with some 
sceptism.

Main points:
1) Load-balancer with N resolver nodes behind it decrease effectivity of 
aggressive cache by factor N, it *does not* invalidate the concept.

In other words, a random subdomain attack which flows through resolver farm 
with N nodes has to fill N caches with NSEC records, and that will simply take 
N times longer when compared with non-load-balanced scenario.

The aggressive cache still provides upper bound for size of NXDOMAIN RRs in 
cache, which is super useful under attack because it prevents individual 
resolvers from dropping all the useful content from cache during the attack.


2) Two out of five major DNS resolver implementations used by large ISPs did 
not implement aggressive caching (yet?), so it needs to be expected that 
deployment is not great. Also the feature is pretty new and large ISPs are 
super conservative and might not deployed new versions yet ...

I forgot the rest so I will conclude with: Watch the video recording and think 
yourself! :-)
Petr Špaček  @  CZ.NIC


> 
> Of course, steady state query load is largely irrelevant since root service 
> has to be provisioned with massive DDoS in mind. In my personal view, the 
> deployment of additional anycast instances by the root server operators is a 
> useful stopgap, but ultimately, given the rate of growth of DoS attack 
> capacity (and assuming that growth will continue due to the stunning security 
> practices of IoT device manufacturers), stuff like what is discussed in that 
> paper is the right long term strategy.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Wessels, Duane via dns-operations]

--- Begin Message ---


> On Nov 25, 2019, at 2:19 PM, Florian Weimer  wrote:
> 
> * Jim Reid:
> 
>>> On 25 Nov 2019, at 20:54, Florian Weimer  wrote:
>>> Is it because of the incoming data is interesting?
>> 
>> Define interesting.
> 
> The data could have monetary value.  Passwords that are otherwise
> difficult to come by might be leaking.

Hi Florian,

I can assure you that Verisign does not monetize the root server data.  If
any other operators do, I'm not aware of it.

We do utilize root server data for research purposes from time-to-time.
Recent examples include the KSK rollover and name collisions.  Less recent
examples include understanding TTL/caching behavior and preparing for the
root ZSK size increase.  When DDoS attacks happen, we often analyze the
data to see if we can understand how and why it happened, and to be better
prepared for the next one.

DW




smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Wessels, Duane via dns-operations]

--- Begin Message ---


> On Nov 25, 2019, at 1:23 PM, Bill Woodcock  wrote:
> 
>> On Nov 25, 2019, at 9:54 PM, Florian Weimer  wrote:
>> The query numbers are surprisingly low.  To me at last.
> 
> Duane Wessels did a good study some time ago of queries to the root.  I 
> believe over 99% were bogus, not real queries for resolvable things.

For the record, the number from that study (2003!) was 98%.  I believe it has 
since been reconfirmed to be about the same level in a number of subsequent 
studies by others.

DW




smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Fred Morris]

I've been following this thread, and I'm well aware of the massive amounts 
of NXDOMAIN stuff. I don't know enough about this specific issue.


But there are things which happen in Browser Land which would lead me to 
naively conclude the people making browsers don't understand DNS. Two 
recent (actually ongoing) examples:


1) Firefox still (years now, although I haven't filed a bug) doesn't
   understand that it's perfectly ok to have a trailing dot on an FQDN;
   and it serves a purpose. (It's not supposed to be included in the TLS
   Host: header though.)

2) In spite of implementing their own DNS resolvers, browsers seem unable
   to block domains cloaked by CNAMEs (the third party trackers accessing
   first party cookies trope, RPZ works just fine for some odd reason).

On Wed, 27 Nov 2019, Petr Špaček wrote:

[...]
“Coincidence? I think NOT!” 


https://youtu.be/MDpuTqBI0RM?t=53


FYI there is also an issue about this in their tracker:
https://bugs.chromium.org/p/chromium/issues/detail?id=946450#c1


As I understand it these are unadorned labels, unit of one. Two 
parts to this.



What's Chrome's point with this? They've trained monkeys that URLs are for 
Boomers, just type a search string in there. Wild guess here, it goes 
something like this:


User types an undotted hostname on their network. Chrome searches and 
returns a bunch of shopping and social media sites. Ok, that makes monkeys 
upset. Well, we'll go off the reservation (we really hate doing this) and 
see if our operating environment resolves it before searching. Oh drat! 
The operating environment is doing a search! Some monkeys are upset either 
way. Prod Mgr: They're interfering with our search! They don't understand 
the one true way! Dev: I think we should agressively probe the operating 
environment with garbage, the best defense is a good offense. Prod Mgr: 
Let's call it a "friendly" probe and I'm good with it.


Fine, you may not like my personalizations, but is that it? I don't 
believe these people are idiots with no knowledge of DNS operation.


To riff off of an old South Park episode, there seems to be a lot of smug 
in the air. It's not just one thing. It's a pattern of engineering around 
the DNS. Poorly.


Since I don't use Chrome, could somebody please type a local hostname (one 
label) with a trailing dot into the thing and see what happens? Nothing 
good, I'm sure. Those who know the purpose of the trailing dot will know 
that this should outright fail to resolve (probably sends a request to the 
root for the label as a TLD).


Since they're already engineering around the DNS and the trailing dot has 
been a casualty for some time, would it be unthinkable for them to 
repurpose it as a declarative: this label needs to be sent to the 
operating environment resolver (without the dot). Search lists... 
everybody hates search lists.



Let me put it to you this way: which do you hate more, search lists or 
unary labels hitting the roots?


Shouldn't what happens be that they spew their probe at the operating 
environment resolver, it appends things from the search list and tries 
those?


If there's a shared engineering problem here, isn't it that when these 
fail, the resolver tries the naked label? Or tries it first, but in any 
case, tries it.


Isn't the proliferation of "valid" TLDs contributing to this embarrassment 
of riches by making approaches such as selectively whitelisting TLDs so 
increasingly impractical as to obviate consideration?


Should local resolvers reject attempts to resolve single labels as TLDs 
unless RD=0?



I apologize, none of this is fully baked, but the debate doesn't seem to 
be encompassing the entirety of the system.


--

Fred Morris
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[David Conrad]

Petr,

> I think there is even more fundamental problem:
> Someone has to pay operational costs of "the new system”.

The “new system” is simply the existing network of resolvers, augmented to have 
the root zone.  As far as I can tell, the operational cost would be in (a) 
ensuring the resolver is upgraded to support obtaining the root zone and (b) 
dealing with the fetch of the root zone with some frequency.

There would be an additional cost, that of making the root zone available to 
myriads of resolvers, but I believe this is an easily handled issue.

> Personally I do not see how transition to another root-zone-distribution 
> system solves the over-provisioning problem - the new system still has to be 
> ready to absorm absurdly large DDoS attacks.

Two ways:
- greater decentralization: there are a lot more resolvers than the number of 
instances root server operators are likely to ever deploy. While an individual 
resolver might melt down, the impact would only be the end users using that 
resolver (and it is relatively easy for a resolver operator to add more 
capacity, mitigate the attacking client, etc).
- the cost of operating and upgrade the service to deal with DDoS is 
distributed to folks whose job it is to provide that service (namely the ISPs 
or other network operators that run the resolvers).  Remember that the root 
server operators have day jobs, some of which are not particularly related to 
running root service, and they are not (currently) being compensated for the 
costs of providing root service.

> Have a look at https://www.knot-dns.cz/benchmark/ 
>  . The numbers in charts at bottom of the 
> page show that a *single server machine* is able to reply *all* steady state 
> queries for the root today.
> ...
> Most of the money is today spent on *massive* over-provisioning. As an 
> practical example, CZ TLD is over-provisiong factor is in order of *hunderds* 
> of stead-state query traffic, and the root might have even more.


Yep. As mentioned before, steady state is largely irrelevant.

In my view, the fact that root service infrastructure funnels up to a (logical) 
single point is an architectural flaw that may (assuming DDoS attack capacity 
continues to grow at the current rate or even grows faster with crappy IoT 
devices) put the root DNS service at risk.  One of the advantages of putting 
the root zone in the resolver is that it mitigates that potential risk.

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)


signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Florian Weimer]

* Mark Allman:

> 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?

What's the change rate for the root zone?  If there is a full
transition of the name server addresses for a zone, how long does it
typically take from the first change to the completion of the sequence
of changes?

If the answer, “this has never happened”, then using a fairly static
data source should probably be okay (similar to how the browser PKI is
maintained).  Due to the way DNSSEC works with its periodic renewal of
signatures, validating non-recursive resolvers will automatically
verify the freshness of the local root zone copy.  Even if there are
few such clients, I expect that for most operators, it will
effectively prevent undetected decay due to a stale root zone (where
more and more stale delegations accumulate until performance is
seriously impacted, and fresh bootstrap using external data is
needed).

The other question is whether that data source will make it harder for
ICANN or someone else to hand over control over the TLD in a
unilateral manner.  And then it's not even clear whether that's a good
thing or not.

Other uncertainties relate to the size of the root zone.  It seems
that the phase of aggressive growth is more or less over.  But
hard-coding an assumption that resolvers can load the root zone into
memory is on a different level because it limits policy basically for
forever.

I've thought a bit whether the root domain list should be pushed into
(non-validating) stub resolvers, but I don't think that's possible
because people really like to use local domains.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Jared Mauch]

> On Nov 27, 2019, at 5:26 PM, Florian Weimer  wrote:
> 
> What's the change rate for the root zone?  If there is a full
> transition of the name server addresses for a zone, how long does it
> typically take from the first change to the completion of the sequence
> of changes?

There are regular changes. 

Resolvers regularly have old data. Survey for old root hints to see how bad 
they are. 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Solved] (not just) Quad9 denial of existence for _25._tcp.mx1.p01.antagonist.nl IN TLSA

[Viktor Dukhovni]

Root cause found, the antagonist.nl domain has 3 listed nameservers:

ns1.antagonist.nl.
ns2.antagonist.net.
ns3.antagonist.de.

but the IP address returned by the actual antagonist.de zone:

ns3.antagonist.de. IN A 139.162.173.192

differs from the glue record returned from the .DE zone:

ns3.antagonist.de. IN A 66.228.42.134

And it is this 66.228.42.134 (returned in the .DE glue) nameserver that is
serving freshly signed denial of existence for _tcp.mx1.p01.antagonist.nl.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Questions on private nameservers registration

[Wesley Peng]

Another more question, can I put DE glues into other domain registry's 
zone? For example, the COM's.


Regards.

on 2019/11/26 9:41, Wesley Peng wrote:

John,

on 2019/11/26 9:35, John W. O'Brien wrote:

Are ns{1,2}.wsly.de authoritative for wsly.de? Then glue is required in
DE. Otherwise probably not [0].


Yes I plan to setup ns{1,2}.wsly.de to be wsly.de's auth-nameservers.
Thank you for pointing out that.

Regards.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Florian Weimer]

* Jared Mauch:

>> On Nov 27, 2019, at 5:26 PM, Florian Weimer  wrote:
>> 
>> What's the change rate for the root zone?  If there is a full
>> transition of the name server addresses for a zone, how long does it
>> typically take from the first change to the completion of the sequence
>> of changes?
>
> There are regular changes. 

But does anyone swap out the name servers for a TLD over the course of
five days?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Ondřej Surý]

> On 27 Nov 2019, at 23:08, Florian Weimer  wrote:
> 
> What's the change rate for the root zone?

https://twitter.com/diffroot

O.
--
Ondřej Surý
ond...@sury.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Florian Weimer]

* Ondřej Surý:

>> On 27 Nov 2019, at 23:08, Florian Weimer  wrote:
>> 
>> What's the change rate for the root zone?
>
> https://twitter.com/diffroot

Selective quoting does not help to further the discussion.  Raw change
rates do not tell us if zones keep at least of some of their servers
at constant addresses over really, really long periods of time.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Ondřej Surý]

> On 28 Nov 2019, at 08:09, Florian Weimer  wrote:
> 
> * Ondřej Surý:
> 
>>> On 27 Nov 2019, at 23:08, Florian Weimer  wrote:
>>> * Mark Allman:
>>> 
 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?
>>> 
>>> What's the change rate for the root zone?
>> 
>> https://twitter.com/diffroot
> 
> Selective quoting does not help to further the discussion.

Including cruft also does not help to further the discussion, but fair enough, 
I reinstated
the rest of your email into the reply.

> Raw change
> rates do not tell us if zones keep at least of some of their servers
> at constant addresses over really, really long periods of time.

.bank
- deleted NS {ac1|ac2}.nstld.com. and added NS {a|b|c}.nic.bank. on November 20
and
- deleted NS {ac3|ac4}.nstld.com. and added NS {d|e|f}.nic.bank. on November 23

Does that answer your question?

That doesn’t include changes to GLUE records which are equally as important, so 
the
only value you can work with and rely on is the TTL. (172800 - 48h).

The TTL on DS is 1 day and is even more important to get the updated DS early
when there’s a breach and DS needs to be swapped as early as possible.

>> If there is a full
>> transition of the name server addresses for a zone, how long does it
>> typically take from the first change to the completion of the sequence
>> of changes?
>> 
>> If the answer, “this has never happened”, then using a fairly static
>> data source should probably be okay (similar to how the browser PKI is
>> maintained).  Due to the way DNSSEC works with its periodic renewal of
>> signatures, validating non-recursive resolvers will automatically
>> verify the freshness of the local root zone copy.  Even if there are
>> few such clients, I expect that for most operators, it will
>> effectively prevent undetected decay due to a stale root zone (where
>> more and more stale delegations accumulate until performance is
>> seriously impacted, and fresh bootstrap using external data is
>> needed).
>> 
>> The other question is whether that data source will make it harder for
>> ICANN or someone else to hand over control over the TLD in a
>> unilateral manner.  And then it's not even clear whether that's a good
>> thing or not.
>> 
>> Other uncertainties relate to the size of the root zone.  It seems
>> that the phase of aggressive growth is more or less over.  But
>> hard-coding an assumption that resolvers can load the root zone into
>> memory is on a different level because it limits policy basically for
>> forever.
>> 
>> I've thought a bit whether the root domain list should be pushed into
>> (non-validating) stub resolvers, but I don't think that's possible
>> because people really like to use local domains.


Ondrej
--
Ondřej Surý
ond...@sury.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations