Subject: [DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 14 Feb 2019 13:05:21 +0800 (GMT+08:00)

Hello,

   A new draft about root data caching is proposed, which aims to solve the similar problem presented in RFC7706 and gives the DNS administrator one more option.
   
Thanks.

Jiankang Yao

-----原始邮件-----
发件人: [email-masked]
发送时间: 2019-02-14 08:13:44 (星期四)
收件人: "Jiankang Yao" <[email-masked]>, "Arnt Gulbrandsen" <[email-masked]>
抄送: 
主题: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt

A new version of I-D, draft-arnt-yao-dnsop-root-data-caching-00.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name:		draft-arnt-yao-dnsop-root-data-caching
Revision:	00
Title:		Decreasing Fetch time of Root Data by Additional Caching Rules
Document date:	2019-02-12
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-arnt-yao-dnsop-root-data-caching-00.txt
Status:         https://datatracker.ietf.org/doc/draft-arnt-yao-dnsop-root-data-caching/
Htmlized:       https://tools.ietf.org/html/draft-arnt-yao-dnsop-root-data-caching-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-arnt-yao-dnsop-root-data-caching

Abstract:
   Some DNS recursive resolvers have long round trip times to the
   nearest DSN root server, which has been an obstacle to DNS query
   performance.  In order to decrease root record fetch time without
   introducing a new source of errors, this document proposes a root-
   specific modification to the caching rules.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Finch <[email-masked]>
Date: Thu, 14 Feb 2019 13:58:58 +0000

Jiankang Yao <[email-masked]> wrote:
>
>    A new draft about root data caching is proposed, which aims to solve
>    the similar problem presented in RFC7706 and gives the DNS
>    administrator one more option.

How does this relate to:

https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
https://tools.ietf.org/html/draft-ietf-dnsop-7706bis

It looks like this new draft is actually a revision of:

https://tools.ietf.org/html/draft-yao-dnsop-root-cache

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Southeast 6 to gale 8. Moderate or rough. Fair. Good.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 14 Feb 2019 10:12:15 -0500

> https://tools.ietf.org/html/draft-wkumari-dnsop-hammer

... and our plan is to still (in our copious free time!) update this to
simplify it, and update it to be more of a "this is how implementations
have implemented this" -- the document is close to cooked, and we'd dearly
love a short bit from implementers describing how they did it...

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> 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

---

From: Benno Overeinder <[email-masked]>
Date: Thu, 14 Feb 2019 16:35:51 +0100

> On 14 Feb 2019, at 16:12, Warren Kumari <[email-masked]> wrote:
> 
> 
> 
> ... and our plan is to still (in our copious free time!) update this to simplify it, and update it to be more of a "this is how implementations have implemented this" -- the document is close to cooked, and we'd dearly love a short bit from implementers describing how they did it…
> 

<implementers hat on>

Noted.

— Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 14 Feb 2019 18:29:31 +0100

> https://tools.ietf.org/html/draft-ietf-dnsop-7706bis

It originates in various ideas Jiankang and I have chatted about.

I didn't like 7706, because I feel that the servers that have long ping 
times to the nearest root are more likely to have admins who make mistakes. 
Jiankang and I discussed alternatives when we met a while ago, and a few 
times since. Once we hit upon this possibility, we didn't discuss 
draft-wkumari-dnsop-hammer, perhaps because it's expired and we'd 
forgotten. Mental entropy.

Compared to the hammer draft, I should say that this is dead simple, has 
one fewer acronyms, and that both of those are intentional features.

I see your name is in the text. Why did you let it expire?

> https://tools.ietf.org/html/draft-yao-dnsop-root-cache

Probably correct. IIt was I who did the typing, and I prefer to start by 
editing something that already has the right XML stuff and at least some 
references etc.

Arnt

---

From: Bob Harold <[email-masked]>
Date: Thu, 14 Feb 2019 16:41:56 -0500

> editing something that already has the right XML stuff and at least some

The draft assumes typical TTL is a week, but what I see in the root zone is:
 the records for X.root-servers.net are 6 days (518400),
DS, NSEC, RRSIG, and SOA are 1 day (86400), and
 A, AAAA, DNSKEY, and NS are all 2 days (172800).
I assume the NS records are the most often used?

So I think the draft needs to recalculate the numbers with 2 days as the
typical ttl.

awk '{print $2,$4}' root.zone | sort | uniq -c
      2
   4159 172800 A
   3648 172800 AAAA
      3 172800 DNSKEY
   7269 172800 NS
      2 172800 RRSIG
     13 518400 A
     13 518400 AAAA
     13 518400 NS
      1 518400 RRSIG
   2903 86400 DS
   1536 86400 NSEC
   2926 86400 RRSIG
      2 86400 SOA
      1 <<>> 9.11.3-1ubuntu1.3-Ubuntu
      1 global +cmd
      1 Query 8197
      1 SERVER:
      1 WHEN: Feb
      1 XFR 22488

-- 
Bob Harold

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Feb 2019 13:48:53 +0100

> The draft assumes typical TTL is a week, but what I see in the root zone is:
...

I hoped noone would notice. It's good rather than bad, overall, but it 
complicates the description.

A good resolver verifies DNSSEC, so the two-day RRs tend to be kept alive 
for as long as the six-day RRs are. Once the six-day RRs are discarded from 
the resolver's cache, the two-day RRs are no longer needed for 
verification, and after about a month they cease being refreshed.

In effect, the six-day RRs (typically NS records) have an average lifetime 
of slightly less than three months after the last use, and the supporting 
DNSSEC RRs of slightly more than four months after the last time the NS is 
needed.

The SOA record is a special case, but IMO too minor to matter. The focus 
here is to eliminate root-zone queries as a significant delay factor for 
day-to-day DNS use, without introducing additional moving parts such as 
humans or crontabs downloading zone files. Caching one SOA too long or too 
short won't make much difference.

Arnt

---

From: Bob Harold <[email-masked]>
Date: Fri, 15 Feb 2019 09:13:55 -0500

> short won't make much difference.

No, the NS records and DNSSEC records only have two days.
There are no 6-day records,  except the X.root-servers.net
<http://x.root-servers.net/> entries, which do not apply here.

-- 
Bob Harold