Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length

[robert campbell]
> What do clients see from tinydns?  Eg, for a record of 'dying.example.com'
> which should expire at T+1500, would it be:
> 
>   Client A requesting 'dying.example.com' at time T receives:
> 	dying.example.com 1500  IN A 192.168.1.2
> 
>   Client B requesting 'dying.example.com' at time T+100 receives:
> 	dying.example.com 1400	IN A 192.168.1.2
> 
> ?
> 
> So, Client A and Client B have _nearly_ the same RR set, just with
> different TTLs.

no.  ttl does not affect rrset identity.  per [rfc2136 1.1.1] et al.

> The end effect is that both Client A and Client B will drop the record
> from their cache at the appropriate time.  This is good, right?

yes.

> So, the next question is, since Client A and Client B received different
> (authoritative) responses, does that mean that there were different
> versions of the zone 'example.com' at time T and T+100 ?

no.  see above.

> If yes, there were different versions of the zone at T and T+100, then
> the SOA serial needs to be updated, with the consequent flurry of AXFR
> requests from the 'example.com' slaves when they noticed the SOA
> having changed.

no.  any authoritative server could clamp its ttl's for local policy reasons
without affecting zone identity.  they can't be made longer but they could
absolutely be made shorter without invalidating the zone soa:content mapping.

> Section 3.4.2 of Vixies 1996 draft (related to implementation of
> time-to-die) has the wording:
> 
>    3.4.2 - TTL Half Life
> 
>    Each time an RR's expiry reaches half of its previous value, that RR's
>    TTL will be reduced to half of its previous value, until the TTL reaches
>    a value less than or equal to sixty (60), i.e., one minute of real time,
> 
>    <snip>
> 
>    Whenever the TTL is automatically reduced by this process, the zone will
>    be considered ``changed'' for the purpose of automatic SOA SERIAL
>    increment (see [UPDATE 3.6]) and real time zone slave notification (see
>    [NOTIFY]).
> 
> You could probably do wording such that the only time an SOA serial change
> occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the
> version of the zone on your non-time-to-die-internal-magic slave is
> correct), but you've still got the problem of differing clients getting
> differing versions of RRs ...

they aren't differing versions of rr's.  ttl is not considered in rr
comparisons.

> ... in the zone without SOA serial change, which is not a good precedent.

see also [rfc2136 3.6].

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg