[192271] in North American Network Operators' Group
Re: Dyn DDoS this AM?
daemon@ATHENA.MIT.EDU (LHC)
Mon Oct 24 04:25:38 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <20161023224258.3569F576E7D7@rock.dv.isc.org>
From: LHC <large.hadron.collider@gmx.com>
Date: Mon, 24 Oct 2016 08:25:09 +0000
CC: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
All this TTL talk makes me think=2E
Why not have two ttls - a 'must-recheck' (does not expire the record but f=
orces a recheck; updates record if server replies & serial has incremented)=
and a 'must-delete' (cache will be stale at this point)?
On October 23, 2016 3:42:58 PM PDT, Mark Andrews <marka@isc=2Eorg> wrote:
>
>In message
><CADJJukkadFbOYvWVan_8pdR=3DfxenqGRsyisiKBH6vpyDse6JrQ@mail=2Egmail=2Ecom=
>
>, Masood Ahmad Shah writes:
>> >
>> > > On Oct 21, 2016, at 6:35 PM, Eitan Adler <lists@eitanadler=2Ecom>
>wrote:
>> > >
>> > > [=2E=2E=2E]
>> > >
>> > > In practice TTLs tend to be ignored on the public internet=2E In
>past
>> > > research I've been involved with browser[0] behavior was
>effectively
>> > > random despite the TTL set=2E
>> > >
>> > > [0] more specifically, the chain of DNS resolution and caching
>down to
>> > > the browser=2E
>> >
>> >
>> > Yes, but that it can be both better and worse than your TTLs does
>not
>> > mean that you can ignore properly working implementations=2E
>> >
>> > If the other end device chain breaks you that's their fault and out
>of
>> > your control=2E If your own settings break you that's your fault=2E
>> >
>>
>> +1 to what George wrote that we should make efforts to improve our
>part of
>> the network=2E There are ISPs that ignore TTL settings and only update
>their
>> cached records every two to three days or even more (particularly the
>> smaller ones)=2E OTOH, this results in your DNS data being inconsistent
>but
>> it=EF=BF=BD=EF=BF=BD=EF=BF=BDs very common to cache DNS records at mult=
iple levels=2E It's an
>effort
>> that everyone needs to contribute to=2E
>
>For TTL there is a tension between being able to update with new
>data and resiliance when servers are unreachable=2E For zone transfers
>we have 3 timers refesh, retry and expire to deal with this tension=2E
>If we were doing DNS from scratch there would be at least two ttl
>values one for freshness and one for don't use past=2E
>
>Additionally a lot of the need for small TTL's is because clients
>don't fail over to second addresses in a reasonable amount of time=2E
>There is no reason for this other than poorly designed clients=2E A
>client can failover using sub-second timers=2E We do this for Happy
>Eyeballs=2E This strategy is viable for ALL connection attempts=2E
>
>Mark
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
