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

[Mark Stapp <[e-mail]>]

Would this be a reasonable summary of the discussion on this topic?

1. the looseness of the coupling among primary, secondary, and caching dns 
servers makes it unrealistic to guarantee that no query will see stale 
records. the deployment experience that we have does not indicate that this 
is a problem.

2. this section of the draft should make the issues about dns ttls and 
caching more explicit, so that it's clearer what the operational 
consequences of 'stale' records might be. I'll add text about the benefits 
to removing dhcp-added dns records when leases expire.

3. the simple ttl guidelines that are in the draft are present to give 
implementors (and administrators) some clue about reasonable ranges and 
defaults. the guidelines are meant to help folks avoid hare-brained 
configurations (what Robert calls "minimizing damage"); the guidelines 
aren't intended to provide a guarantee about how long it may be before 
changes to the dns become universally visible.

4. it's not worthwhile to impose new requirements on DHCP servers to put 
names or addresses in limbo in some way for some period of time after 
leases expire.

-- Mark

At 12:40 PM 6/19/2003 -0500, Ted Lemon wrote:
>On Thursday 19 June 2003 06:19, Robert Elz wrote:
> > That is, reworded, to make sure my understanding is correct, the
> > problem to be avoided is having a name referring to an address that
> > is now to be assigned to a different name ?
> >
> > Who cares?
>
>Let's say machine X has an SMTP listener, and machine Y also has an SMTP
>listener.   Machine X gets an IP address, Z, from the DHCP server.   Then the
>owner of Machine X wanders away, leaving the lease active.   The lease
>expires, and then machine Y gets the address.   But there is still an A
>record for machine X pointing at IP address Z.   So now, machine Q connects
>to Z because of that A record, and tries to drop mail for X on Y.   Y will
>either bounce it immediately, or bounce it after it notices that the A record
>for X is pointing at it.   So we'd really like it if the time that the A
>record goes away and the time that the lease goes away are fairly close
>together, so that the chances of this happening are slim.
>
>Of course, I would say that this is a broken configuration anyway - you 
>really
>want to use protocols that verify who they're talking to if you have a mobile
>computer.   But that's the basis for caring about this sort of thing, and
>while I don't think we can completely solve the problem, it's worth setting
>things up to minimize the damage that occurs in cases like this.
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg