Subject: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-00.txt

From: [email-masked]
Date: Fri, 07 Jun 2013 15:37:40 +0900 (JST)

JPRS observed that DS queries for JP registered domain names have been
increasing and 3.5% of queries are qtype DS now.

I make a presentation about it at DNS-OARC 2013 Spring workshop and I
wrote a draft as a DNSSEC side effect.

Presentation material is here:
  https://indico.dns-oarc.net/indico/getFile.py/access?contribId=14&resId=0&materialId=slides&confId=0

Do you observe an increase of DS queries ?

Comments appreciated.

A new version of I-D, draft-fujiwara-dnsop-ds-query-increase-00.txt
has been successfully submitted by Kazunori Fujiwara and posted to the
IETF repository.

Filename:	 draft-fujiwara-dnsop-ds-query-increase
Revision:	 00
Title:		 Side effect of DNSSEC: an increase of DS queries
Creation date:	 2013-06-07
Group:		 Individual Submission
Number of pages: 5
URL:             http://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-ds-query-increase-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fujiwara-dnsop-ds-query-increase
Htmlized:        http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase-00

Abstract:
   A significant increase of periodic DS queries is observed at top
   level domain (TLD) DNS servers.  Currently, almost all of periodic DS
   queries come from DNSSEC validators and are queries for unsigned
   delegations.  The reason of the increase is low NCACHE TTL value and
   DS nonexistence.  This phenomena is DNSSEC protocol and DNS parameter
   issue.  DS queries will increase as DNSSEC validators will increase.

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

---

From: ice jew <[email-masked]>
Date: Fri, 7 Jun 2013 15:02:34 +0800

There is one confusing point in page 12 "– whose RR TTL is smaller than
NCACHE TTL"
Does this really matter? Because the  increased requests are to check the
DS RR's non-existence when NCAHCE for this DS RR exipres, so how is it
related to the RR's TTL?

On Fri, Jun 7, 2013 at 2:37 PM, <[email-masked]> wrote:

> URL:
> http://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-ds-query-increase-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-fujiwara-dnsop-ds-query-increase
> Htmlized:
> http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase-00
>
>
> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: [email-masked]
Date: Fri, 07 Jun 2013 17:38:12 +0900 (JST)

> From: ice jew <[email-masked]>

Because DNSSEC validation process does not start
if RR of popular names are in the cache.

One example is "www.nanog.org A".
It is not signed and its TTL is 14400.

www.nanog.org.          14400   IN      A       50.31.151.68

I made "www.nanog.org A" periodic queries to my validators,
the sending interval of "nanog.org DS" queries is not NCACHE TTL 900.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Jun 2013 07:33:57 -0400

Yes, this is a problem.  But I don't like any of the discussed solutions.  I don't think that is surprising, I figure they are just ideas and unfortunately they all have bad side effects.

(Possible Solution#) 1 - There are zones that promise new delegations to appear in less than X minutes.  Argue whether you think this is an abomination of nature or not, but it is a requirement from the business world that has been met by DNS for a decade. DNSSEC can't take away a "feature" like this anymore that it could take away round-robining answers.

2 & 3 - The document hints at this already : impractical.  DNS has got to maintain it's loose management nature. A sync'd DNS will sink.

4 -  Add a dummy DS won't work because that kills opt-out.  You can throw scaling to 100% out the window.

My thoughts, based on the DNS-OARC presentation, was that this can be better treated at the "client" side.

The trouble is we caved in and allowed recursive servers to use the NSEC{3} record to infer when they can send back an NXDOMAIN.  Instead of allowing a cache to only use the NSEC(3) proof for the (name,class,type) - which is what it should be for - we allow recursives to make use is the span in the NSEC{3) to say that nothing would be there so I'm not going to ask.

What I would suggest is restricting recursive servers to only using the proof for the name/class/type and in the case of the DS, in this rare case, boost the TTL used for the DS ncache'd answer to that of the NS set.  And I mean the remaining TTL of the NS set already in the cache (elsewhere).

Listening to the talk, I quickly realized that we have no degrees of freedom on the authority side, this has to be solved on the caching side.  In the spirit of a quick response, the above is offered as a suggestion, it might have holes in it.

>   issue.  DS queries will increase as DNSSEC validators will increase.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.