Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

[Tony Finch]

Bob Harold  wrote:
>
> Reading these various ideas brings up a question in my mind.  If a server
> queries for the SOA of a zone and the serial number has not changed, can it
> then assume that all of the entries in its cache for that zone should still
> be valid now, and for the their original TTL value starting now?

As well as what Robert said, SOA serial numbers are (basically) only
relevant for the zone transfer protocol; if a zone is dynamically
synthesized you can expect to get different answers for its contents
without its serial number necessarily changing.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Shannon, Rockall: West or southwest, backing south, 6 to gale 8, increasing
severe gale 9 at times, then decreasing 4 or 5 later. Very rough or high,
occasionally very high. Occasional rain or showers. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

[Bob Harold]

On Tue, Sep 29, 2015 at 5:20 AM, Shane Kerr 
wrote:

> Jiankang Yao,
>
> I think a simpler approach that works in general is the "HAMMER"
> approach proposed by Warren Kumari, Roy Arends, and Suzanne Woolf a
> couple of years ago:
>
> https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
>
> Basically the idea is that if a query is made for a RRSET that is near
> expiration from the cache, then the resolver will answer normally but
> will also try to refresh the TTL by performing another query.
>
> Note that Unbound already implements something like this today, with
> the "prefetch" option:
>
> https://unbound.net/documentation/unbound.conf.html
>
> BIND 9 does as well, with "prefetch":
>
> https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache
>
> The "HAMMER" approach works for all domains, not just the root zone,
> and doesn't require any separate cache, or indeed any additional state
> at all.
>
> The approach you propose will have some small advantage if someone
> queries for an entry in the root zone that is not in cache. However
> given the long TTL of root zone entries, such a query will be rare so
> the benefit is quite small.
>
> Cheers,
>
> --
> Shane

...

>
> > Jiankang Yao
> >
> > From: internet-drafts
> > Date: 2015-09-29 12:20
> > To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong;
> Ning Kong
> > Subject: New Version Notification for draft-yao-dnsop-root-cache-00.txt
> >
> > A new version of I-D, draft-yao-dnsop-root-cache-00.txt
> > has been successfully submitted by Jiankang Yao and posted to the
> > IETF repository.
> >
> > Name: draft-yao-dnsop-root-cache
> > Revision: 00
> > Title: Decreasing Fetch time of Root Data by Improving the Mechanism of
> Root Data Cacheing
> > Document date: 2015-09-28
> > Group: Individual Submission
> > Pages: 10
> > URL:
> https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/
> > Htmlized:
> https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00
> >
> >
> > Abstract:
> >Many DNS recursive resolvers have long round trip times to the DNS
> >root server.  It has been an obstacle to increse the performance of
> >DNS query.  In order to decrease fetch time of DNS root data, this
> >document proposes a new mechanism by improving the mechanism of root
> >data cacheing.
>

Reading these various ideas brings up a question in my mind.  If a server
queries for the SOA of a zone and the serial number has not changed, can it
then assume that all of the entries in its cache for that zone should still
be valid now, and for the their original TTL value starting now?  If the
values had changed, wouldn't the serial # also change?  Seems like I must
be missing something here.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

[Robert Edmonds]

Bob Harold wrote:
> Reading these various ideas brings up a question in my mind.  If a server
> queries for the SOA of a zone and the serial number has not changed, can it
> then assume that all of the entries in its cache for that zone should still
> be valid now, and for the their original TTL value starting now?  If the
> values had changed, wouldn't the serial # also change?  Seems like I must
> be missing something here.

No inferences like that can be drawn based on the SOA SERIAL field,
because the serial number may have wrapped around to the same value that
was observed previously.  (Even if the time between queries is very
small, there is still a finite window of time during which the zone
publisher can fit as many zone updates into as needed -- at least
conceptually.)

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

[Shane Kerr]

Jiankang Yao,

I think a simpler approach that works in general is the "HAMMER"
approach proposed by Warren Kumari, Roy Arends, and Suzanne Woolf a
couple of years ago:

https://tools.ietf.org/html/draft-wkumari-dnsop-hammer

Basically the idea is that if a query is made for a RRSET that is near
expiration from the cache, then the resolver will answer normally but
will also try to refresh the TTL by performing another query.

Note that Unbound already implements something like this today, with
the "prefetch" option:

https://unbound.net/documentation/unbound.conf.html

BIND 9 does as well, with "prefetch":

https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache

The "HAMMER" approach works for all domains, not just the root zone,
and doesn't require any separate cache, or indeed any additional state
at all.

The approach you propose will have some small advantage if someone
queries for an entry in the root zone that is not in cache. However
given the long TTL of root zone entries, such a query will be rare so
the benefit is quite small.

Cheers,

--
Shane

On Tue, 29 Sep 2015 12:28:06 +0800
"Jiankang Yao"  wrote:

> 
> Dear all,
> 
>   I submit a draft about Decreasing Fetch time of DNS  Root Data.
> 
>Many DNS recursive resolvers have long round trip times to the DNS
>root server.  It has been an obstacle to increse the performance of
>DNS query.  In order to decrease fetch time of DNS root data, this
>document proposes a new mechanism by improving the mechanism of root
>data cacheing.
> 
>Pls kindly help to review it and give the comments.
> 
>   I would also like to apply 10 minutes slot to introduce this idea in 
> the  next IETF meeting
> 
> thanks a lot.
> 
> 
> 
> 
> Jiankang Yao
> 
> From: internet-drafts
> Date: 2015-09-29 12:20
> To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong; Ning 
> Kong
> Subject: New Version Notification for draft-yao-dnsop-root-cache-00.txt
> 
> A new version of I-D, draft-yao-dnsop-root-cache-00.txt
> has been successfully submitted by Jiankang Yao and posted to the
> IETF repository.
> 
> Name: draft-yao-dnsop-root-cache
> Revision: 00
> Title: Decreasing Fetch time of Root Data by Improving the Mechanism of Root 
> Data Cacheing
> Document date: 2015-09-28
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt
> Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/
> Htmlized:   https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00
> 
> 
> Abstract:
>Many DNS recursive resolvers have long round trip times to the DNS
>root server.  It has been an obstacle to increse the performance of
>DNS query.  In order to decrease fetch time of DNS root data, this
>document proposes a new mechanism by improving the mechanism of root
>data cacheing.
> 
>   
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

[Jiankang Yao]

Dear all,

  I submit a draft about Decreasing Fetch time of DNS  Root Data.

   Many DNS recursive resolvers have long round trip times to the DNS
   root server.  It has been an obstacle to increse the performance of
   DNS query.  In order to decrease fetch time of DNS root data, this
   document proposes a new mechanism by improving the mechanism of root
   data cacheing.

   Pls kindly help to review it and give the comments.

  I would also like to apply 10 minutes slot to introduce this idea in the  
next IETF meeting

thanks a lot.




Jiankang Yao

From: internet-drafts
Date: 2015-09-29 12:20
To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong; Ning Kong
Subject: New Version Notification for draft-yao-dnsop-root-cache-00.txt

A new version of I-D, draft-yao-dnsop-root-cache-00.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name: draft-yao-dnsop-root-cache
Revision: 00
Title: Decreasing Fetch time of Root Data by Improving the Mechanism of Root 
Data Cacheing
Document date: 2015-09-28
Group: Individual Submission
Pages: 10
URL:
https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt
Status: https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/
Htmlized:   https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00


Abstract:
   Many DNS recursive resolvers have long round trip times to the DNS
   root server.  It has been an obstacle to increse the performance of
   DNS query.  In order to decrease fetch time of DNS root data, this
   document proposes a new mechanism by improving the mechanism of root
   data cacheing.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop