Thanks, Ed, and sorry too late response.
> From: Edward Lewis <[email protected]>
> 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 protected]>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
