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

Olafur Gudmundsson <> Wed, 05 March 2014 14:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E3841A01C3 for <>; Wed, 5 Mar 2014 06:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wl5tD4wSjAVJ for <>; Wed, 5 Mar 2014 06:10:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9518C1A0122 for <>; Wed, 5 Mar 2014 06:10:43 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (SMTP Server) with ESMTP id E7D713D0B0E; Wed, 5 Mar 2014 09:10:39 -0500 (EST)
X-Virus-Scanned: OK
Received: by (Authenticated sender: with ESMTPSA id B87613D068A; Wed, 5 Mar 2014 09:10:38 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Wed, 5 Mar 2014 14:10:39 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1510)
Subject: Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Mar 2014 14:10:45 -0000

On Mar 5, 2014, at 10:23 AM, wrote:

> Dear Chairs and WG participants,
> I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.
> 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:
> Please comment to the draft.
> 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 
JP side NS has TTL of 1 day but 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 
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"