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

From: [email-masked]
Date: Fri, 12 Jul 2013 16:06:43 +0900 (JST)

Thanks, Ed, and sorry too late response.

> 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.

I agree. All solutions are not good.

> 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).

It is different from DNS/DNSSEC protocol.
Authoritative side cannot control validator implementations.

> 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.

So, I happened to have thought dummy DS idea.

It is not good, but may solve this issue without changing DNS/DNSSEC
protocols and existing validators.

I will update the draft to add your suggestion.

Regards,

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