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.
On Jun 7, 2013, at 2:37, <[email protected]> <[email protected]> wrote:
> 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 protected]>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
