Re: [DNSOP] Measuring DNS TTL Violations in the wild

[Lanlan Pan]

Mukund Sivaraman 于2017年12月2日周六 下午10:39写道：

> On Fri, Dec 01, 2017 at 05:16:47PM +, Ólafur Guðmundsson wrote:
> > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane 
> > wrote:
> >
> > >
> > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson <
> ola...@cloudflare.com>
> > > wrote:
> > > >
> > > > I strongly disagree with your "terminology", TTL is a hint about
> maximum
> > > caching period, not a demand or a contract.
> > >
> > > You say its just a hint.  If you put a TTL of 1 hour on your data, and
> I
> > > have a recursive name server that reuses it for 2 hours, 12 hours, 5
> > > days... thats okay?
> > >
> > > If its just a hint then we are we spending all this effort on "serve
> > > stale"?
> > >
> > > DW
> > >
> > >
> > Strictly speaking yes, it is the same as when a Secondary does not update
> > the zone for a long time.
>
> An authoritiative server operator knows what the consequence of setting
> SOA RDATA fields is. It isn't the same as a cache extending TTL as it
> sees fit, in spite of the loose coherency among primary and secondaries.
>
> I don't agree a downstream cache has authoritiative say about extending
> TTLs (except exceptional circumstances where the authority is
> unreachable ~serve-stale).
>

Some authorititatives set the NS RR TTL<60s, they don't follow the best
practice guide.
Authoritatives think they "do the right thing" to spread latest NS RR.
Needless to say A RR.

Some resolvers  extend all RR's TTL<60s  to 3600s，just to reduce the
queries, when the authority is reachable.
Resolvers think they "do the right thing", too.


> Mukund
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain

[Mark Andrews]

The text for "in-bailwick" is too restrictive, it doesn’t just cover NS records 
or
glue records.

In-bailwick refers to records that in the normal course of DNS resolution
would have been requested of by the server the current response is from.
e.g. if you are querying a .com server then all records in the response that end
with .com are in-bailwick.

Mark

> On 5 Dec 2017, at 5:27 am, Paul Hoffman  wrote:
> 
> Greetings again.
> 
> Some of the new terms added to the terminology-bis draft 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 
> 7719 can be a bit tricky. This week, we hope you will look at the definitions 
> in the draft for:
> - In-bailiwick
> - Out-of-bailiwick
> - In-domain
> - Sibling domain
> Please review these terms and comment on the list if you think the 
> definitions should change.
> 
> --Paul Hoffman
> 
> [[ As a reminder, we asked the following last week, but got no reply: For the 
> past many versions of the terminology-bis draft 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), Section 
> 2 has definitions of "Global DNS" and "Private DNS", based on the facets 
> listed in "Naming system". This was discussed heavily on the list earlier, 
> but it is also a pretty big change, so we want to be sure that it is what the 
> WG wants. Please review these terms and comment on the list if you think the 
> definitions should change. ]]
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Measuring DNS TTL Violations in the wild

[神明達哉]

At Sat, 2 Dec 2017 20:09:25 +0530,
Mukund Sivaraman  wrote:

> > Strictly speaking yes, it is the same as when a Secondary does not update
> > the zone for a long time.
>
> An authoritiative server operator knows what the consequence of setting
> SOA RDATA fields is. It isn't the same as a cache extending TTL as it
> sees fit, in spite of the loose coherency among primary and secondaries.
>
> I don't agree a downstream cache has authoritiative say about extending
> TTLs (except exceptional circumstances where the authority is
> unreachable ~serve-stale).

+1.  I'd accept some level of liberty that an implementation can take,
such as ISC BIND 9 extending a 0-TTL of glue to 1 second:

/*
 * Glue with 0 TTL causes problems.  We force the TTL to
 * 1 second to prevent this.
 */
if (rdataset->ttl == 0)
rdataset->ttl = 1;

but it should be limited to a quite small range.  How much is
acceptable may be debatable, but I wouldn't consider "Stretching TTL
from 1 Hour [...] for 10% or 10 minutes" to be acceptable at the
discretion of an implementation.

--
JINMEI, Tatuya

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

Re: [DNSOP] Measuring DNS TTL Violations in the wild

[Andrew Sullivan]

On Sat, Dec 02, 2017 at 08:09:25PM +0530, Mukund Sivaraman wrote:
> I don't agree a downstream cache has authoritiative say about extending
> TTLs (except exceptional circumstances where the authority is
> unreachable ~serve-stale).

I will note that this WG spent a fair amount of effort on RFC 7583.
That text is actually bad advice if you are supposed to expect
resolvers to extend the TTL on RRsets, because the Ready state depends
on caches expiring.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Measuring DNS TTL clamping in the wild

[Stephane Bortzmeyer]

On Fri, Dec 01, 2017 at 01:12:34PM -0500,
 Steve Crocker  wrote 
 a message of 41 lines which said:

> Shortening TTLs increases the amount of traffic between the recursive 
> resolvers and authoritative resolvers and lengthens the response time for 
> some queries.  However, I don’t think there is any service guarantee with 
> respect to an individual query that is violated by shortening the TTL.
> 
> Lengthening a TTL, on the other hand, does change one of the service 
> guarantees.  When there is a change in the entry in the authoritative server, 
> what is the maximum time until that change is guaranteed to be propagated 
> throughout the net?  This depends primarily on the TTL.  However, when the 
> TTL is lengthened by the recursive resolvers, the upper bound for propagation 
> of a change is similarly increased.

I fully agree about this very important difference (which is
completely missing in the RIPE Labs article). Lengthening the
TTL is a protocol violation (otherwise, we wouldn't discuss about
draft-ietf-dnsop-serve-stale). Shortening it systematically is bad
manners, and is selfish but is not a protocol violation.

We should not discuss the two in the same thread: they are very
different practices.

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