Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Warren Kumari <[e-mail]>]

On Sun, Jul 29, 2018 at 3:09 PM Steve Crocker <[e-mail]> wrote:
>
> Joe,
>
> As an individuals, you, I, or anyone else, can do whatever we like, of course.  On the other hand, as system designers we presumably look at the overall system and try to put in place an operational structure that anticipates and meets the likely needs of the users.
>
> The present and long-standing system provides the recursive resolvers with well-oiled and highly effective solutions to (a) finding the root servers and (b) getting highly reliable and highly responsive answers from them.

Nod.

> It seems to me reasonable and reasonably easy to sustain these attributes as we evolve toward downloading the entire root zone instead of individual pieces of it.

Vigorus nod.

> And by "evolution" we're necessarily talking about a lengthy period of hybrid operation.

Nod.

> There will likely be a growing set of recursive resolvers downloading the full root zone and but there will certainly be a very large set of recursive resolvers that continue to operate in the current model.

Nod...

> Even if there were to be an aggressive push toward hyper local root service, the existing service would have to remain as is for a long time.  And by "a long time" I'm guessing ten years is not enough, so I suspect it will be twenty years before one can imagine the current root service reaching twilight.

Nod (I would have said much more than 20 years, but ok).

>
> The heated concern of several years ago about the potential size of the root zone is behind us, I hope.  The root zone is not going to grow exponentially.  The whole zone will be in the single megabyte range, I think.  (Caution: I haven't looked at the actual size.  Apologies if I am off a bit.  But the overall point is still right.  Another round or so of gTLDs might double or even triple the current size of the root zone, but it will not grow by even one order of magnitude and certainly not by multiple orders of magnitude.)

Nod.
wkumari$ dig axfr . @b.root-servers.net > root.zone
wkumari$ ls -alh root.zone
-rw-r--r--  1 wkumari  staff   2.1M Jul 30 10:34 root.zone

2.1MB - close enough.

>
> Distribution of a megabyte or even a few megabytes to, say, a million recursive resolvers twice a day is a relatively modest endeavor on today's Internet.

Nod. 2.1MB times 1M resolvers is ~2TB (or the size of a medium
capacity SSD drive)

> If there are going to be problems, I suspect they won't be related to ad hoc fetching of the root zone from random untrusted sources.

Citation needed :-)

Regardless of where I get the root zone (trusted source, untrusted
source) I'd like to be able to make sure if it is accurate and
complete.
For example, I just fetched the root zone via AXFR from
b.root-servers.net in MIA, a server which, for various reasons I trust
implicitly. However, I'm not really sure I trust the network between
it and myself - and if I'm planning on using this zone in a production
environment I'd really like to be able to know that someone hasn't
monkeyed with it between b.root-servers.net and myself.
When I open the zone and it contains:
-----
aaa.                    172800  IN      NS      ns1.dns.nic.aaa.
aaa.                    172800  IN      NS      ns2.dns.nic.aaa.
aaa.                    172800  IN      NS      ns3.dns.nic.aaa.
aaa.                    172800  IN      NS      ns4.dns.nic.aaa.
aaa.                    172800  IN      NS      ns5.dns.nic.aaa.
aaa.                    172800  IN      NS      ns6.dns.nic.aaa.
aaa.                    86400   IN      DS      21707 8 1
6D92DD0D0DB0E392FA9D5F08EA15BBD297B8CBE2
aaa.                    86400   IN      DS      21707 8 2
4F74856F31B73F3BFCDF430985329F55AA655BC9E53C4BF9DC6B14CC E6780600
aaa.                    86400   IN      DS      28192 8 1
563200F63B8B1797B4D88D14BD6A672EA4D0CC0C
aaa.                    86400   IN      DS      28192 8 2
DCB5AA6EC2B73D3E8C82D481770151160B38BCF2DBF3B9CD587AAD38 8D3572D7
aaa.                    86400   IN      RRSIG   DS 8 1 86400
20180812050000 20180730040000 41656 .
9pGWZzPrVVFeqif5/PwqlO4BeFcTn2fvE1u5Mv5ADl5xn5vgm1WnWrnB
5Fxuk8TYIWFKhZ19DPk8RaU5Qk/kJpB/7A596x+XJ4IkaaMhlfAWYGYo
9C3cr5yj34FtLKlhU5tE3mSyt4lfyg558hSpwgo6cQPTj78KmkBkzjty
X/ZeYTcSZX+zcIK2pNB1bG5yU4IEJbqye4LrKUqVKJ48bJI3pa6tci+b
SFkGbqhotRfVdXSuNqZ/njLn+mH/vGIVKlMB5IwLe7Jf7lA1bFlMT4pP
BACKPMletFgDMlTaMocqmbRBhRUDHnf93+vSoqxykwB+GLO7A/J3k2FZ NqKDtg==
aaa.                    86400   IN      NSEC    aarp. NS DS RRSIG NSEC
aaa.                    86400   IN      RRSIG   NSEC 8 1 86400
20180812050000 20180730040000 41656 .
1MIOeZb204La5r+b71rZxl39WqfVFp4z0kDRh2xd881mW1OICp7zUS1Y
qOn/T3WTFQQG+39UVB2uQT+kcwL+rDLN2LGQhTFUzWLTom0oVEzO7rGu
zUzbvqMJ0YBtrVqqzxcGYQ0lzGwUgn2qWyFPe6tUXZX3LmJgTT0yHzYT
pG0cdEFc/7/7dnXgZIn7LSpOWc8m+Pxz7PSqjQ503cD+UqeJhYRpqTFy
YG+UWchXoVZrs0qF6qsqgxdIsGcoeD+0Mh7eondWl4IPNT6UZ1iIxM9q
hTNu5y/qyvEW/M20cRGVtY7B9h7RY7d6ASGAbYybeYljG2TBNqYyD9Bh GDg0ow==
ns1.dns.nic.aaa.        172800  IN      A       127.0.0.1
ns1.dns.nic.aaa.        172800  IN      AAAA    ::1
ns2.dns.nic.aaa.        172800  IN      A       127.0.0.2
ns2.dns.nic.aaa.        172800  IN      AAAA   ::2
ns3.dns.nic.aaa.        172800  IN      A       192.168.1.1
ns3.dns.nic.aaa.        172800  IN      AAAA    ::3
----
I'd really like to know if the 127.0.0.1 was there when the zone was
signed, and that it hasn't been "fixed" by something on path.

W


>
> Steve
>
>
> On Sun, Jul 29, 2018 at 11:50 AM, Joe Abley <[e-mail]> wrote:
>>
>> On Jul 29, 2018, at 12:19, Steve Crocker <[e-mail]> wrote:
>>
>> > It feels like this discussion is based on some peculiar and likely incorrect assumptions about the evolution of root service.  Progression toward hyper local distribution of the root zone seems like a useful and natural sequence.  However, the source of the copies of the root zone will almost certainly remain robust and trusted.
>>
>> I think you need to be more clear what you mean by "source".
>>
>> If you mean the original entity that constructs and first makes
>> available the root zone (e.g. the root zone maintainer in the current
>> system) then what you say seems uncontentious.
>>
>> If what you mean is "the place that any particular consumer if the
>> root zone might have found it" then I think you need to show your
>> working.
>>
>> Resolvers currently prime from a set of trusted servers (albeit over
>> an insecure transport without authentication, so we could quibble
>> about what "trusted" means even there) but it's not obvious to me that
>> this is a necessary prerequisite for new approaches.
>>
>> If I have a server sitting next to me that has a current and accurate
>> copy of the root zone and I am able to get it from there and assess
>> the accuracy of what I receive autonomously, why wouldn't I?
>>
>>
>> Joe
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf