Subject: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

From: [email-masked]
Date: Wed, 05 Mar 2014 19:23:56 +0900 (JST)

Dear Chairs and WG participants,

I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.

  http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase

Recent DS traffic increase seems not high, I did not request time slot
of WG meeting. However, Increasing is a fact. 

Recent DS query graph is here:
  http://member.wide.ad.jp/~fujiwara/files/DS_graph_20140305.pdf

Please comment to the draft.

What should I do about this draft from now on?  

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Mar 2014 12:28:31 +0000

It is an interesting draft and I can see why the problem concerns you. The dummy DS is a clever work-around, but it is a pity about the validation bug in Google public DNS.

I wonder about the possibility of adjusting the rules for caching delegations. Would it make sense to remember that a referral is insecure for the lifetime of the NS RRset, instead of the lifetime of the negative DS answer?

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

> On 5 Mar 2014, at 10:23, [email-masked] wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 5 Mar 2014 14:10:39 +0000

> What should I do about this draft from now on?  

This is not a protocol issue this, is an implementation choice when a resolver is optimizing for speed of resolving by 
fetching any possible missing information 

Increasing the negative TTL will to large extend address the issue but has other implications

Dummy DS  an option for the high query volume domains you do not need it for most. 
If some validators have problem with them report it as bugs and hopefully it will be fixed quick.  

Your calculations on the amplification are good illustration, but assume that the resolvers use
the parental provided NS set, not the child side provided NS set. 
In the case of google.co.jp. 
JP side NS has TTL of 1 day but google.co.jp side has is 96 hours (4 days) 
Unbound resolver has by default of MaxTTL 1 day thus it does not matter in the case of google.co.jp 
which NS set is stored, but other resolvers do different things. 

In short I think the simple conclusion is 
"signed domain will see increased DS traffic for unsigned child domains" 

	Olafur

---

From: [email-masked]
Date: Fri, 07 Mar 2014 02:57:55 +0900 (JST)

> From: Tony Finch <[email-masked]>

Thanks. I'm not sure that the validation error is a bug or not.

> I wonder about the possibility of adjusting the rules for caching delegations. Would it make sense to remember that a referral is insecure for the lifetime of the NS RRset, instead of the lifetime…

This idea requires updating RFC 2308.

I'm afraid that when newly registered DS RR will be used if the
negative DS answer is cached.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 06 Mar 2014 18:00:30 +0000

Hi,

I believe there may of been some take away from Vancouver on direction. 
I have a hand written note on this, but it was lost in the discussion on 
Key Exchanges.

I will followup with you after tonight's meeting, and apologies for 
dropping this.

tim

---

From: [email-masked]
Date: Fri, 07 Mar 2014 03:03:40 +0900 (JST)

> From: Olafur Gudmundsson <[email-masked]>

Thanks. Some domain names use shorter NS TTL values.

> "signed domain will see increased DS traffic for unsigned child domains" 

Agree.

I would like to know whether the increase of DS queries are observed
commonly or not. (with small NCACHE TTL value)

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 6 Mar 2014 15:58:13 -0300

On Fri, Mar 07, 2014 at 03:03:40AM +0900, [email-masked] wrote:
...
> commonly or not. (with small NCACHE TTL value)

We are observing around the same % of qps but still need to confirm
the other characteristics.

Fred