Subject: ddns and failover protocol

From: "David Erdmann" <[email-masked]>
Date: Tue, 5 Oct 1999 17:48:45 -0400 (EDT)

Hi,

I have a concern that relates to both the DHCP-FAILOVER
(draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS
(draft-ietf-dhc-dhcp-dns-10.txt) draft.

Consider that you have a DHCP server whose objective is to make sure
that a DNS server has all of the FQDN->IPaddr information about clients
that it has given addresses to.  This is done through the DDNS defined
in DHCP-DNS.

Assume that the DNS server is down for the moment.  The DHCP server
should be trying to update the DNS server indefinitely.  If the DHCP server
restarts for some reason, I would expect it to continue trying to update the
DNS server with the information that has not yet been updated to the DNS
server.

Has anyone considered the implications to the DHCP-FAILOVER draft?  From a
network reliability point of view I could envision the Primary passing
whether
it has updated the DNS server to the backup, and the backup trying to do
any incomplete DDNS updates.

Should the FAILOVER draft specifically be addressing issues like this,
or should it be the DHCP-DNS draft that should address this?

-Dave
----------------------------------
Dave Erdmann
Nortel Networks, NetID Group
mailto:[email-masked]

---

From: Rob Stevens <[email-masked]>
Date: Tue, 5 Oct 1999 20:34:53 -0400 (EDT)

>or should it be the DHCP-DNS draft that should address this?

David
I don't have any answer, but I too was wondering about
this (or something very like it anyway) and I had it on
my short list of things for the ad-hoc failover discussions
that we are having. It didn't seem to fall into any of the
major topics, and I was going to suggest a "Miscellany"
to round out the discussion on Thursday.
(perhaps I should have suggested it today - it's the first
  time I can remember that one of these groups finished
  early, and without my feeling completely effete).

Kim, could you add this to Thursday's agenda: a miscellaneous
topics roundup?

Rob

---

From: Bernie Volz <[email-masked]>
Date: Tue, 5 Oct 1999 23:28:46 -0400 (EDT)

David:

This does sound like a useful issue to discuss. And, since Mark Stapp
is authoring the document and partipating, we can resolve where to
document this and what to do.

I believe, but I could be corrected, that binding updates should be
done as DDNS occurs to make sure that both servers are aware of the
state of the DDNS requests. See section 6.2.7 and 7.1.1 of the 04
draft.

Clearer language around exactly what each partner should do with DDNS
and updating the FQDN information seems required.

As Rob suggested, this is a good topic for either the end of the 2nd
(if time) or 3rd conference call.

- Bernie Volz

From: "David Erdmann" <[email-masked]>
Subject: ddns and failover protocol

Hi,

-Dave

---

From: "David Erdmann" <[email-masked]>
Date: Wed, 6 Oct 1999 09:58:42 -0400 (EDT)

Hi Diana,

Thanks for commenting on my posting. :)

> While it is important for the DHCP server's dynamic updates to be
> processed,
> it is possible for those updates to stack up to the point where
> they become
> more of a problem than if they had simply been dropped in the first place.
> Consider the case of a fairly lengthy outage with many clients hitting the
> backup server (RENEWs, a storm of DISCOVERs, etc.)  Add to that volume of
> requests to be processed the backlog of DNS updates and it may be that the
> backup becomes so busy updating DNS that it, too, falls behind on serving
> clients.  At some point, a certain percentage of the incomplete
> DNS updates
> may become outdated as the IP addresses involved are assigned to
> new clients.

There should be some exponential back-off for trying DDNS updates.  If
people have
DDNS turned on, then I can only assume that they are interested in the DNS
server
getting updated.  I don't think that it is safe to assume that we can just
drop
DNS updates.  I do agree however that we should consider the performance
implications.

When you assign an address to a new client you should be cancelling the
previous
DNS update, and trying to update the new address.

> I think the idea of preserving some of the DNS updates yet to be
> performed is
> good, but perhaps they should be dropped either after a certain
> period of time
> (at what point should they become "stale?") or when server load reaches a
> certain percent of "maximum capacity."

If DHCP is the only way of updating DNS servers I would be wary of expiring
DNS
updates (of course after the lease expires we should stop).  As for server
load
reaching a certain maximum, I agree that it would be a good idea for a
server
to not do too many simultaneous updates, and queue the updates...I don't
think
that we should be dropping the updates altogether.

> IP addresses for existing clients
> will tend to remain constant, so DNS records pertaining to those
> clients will
> be unnecessary.  Perhaps the backup should only update records for those
> clients that start out at DISCOVER, not for those RENEWing
> existing leases.

Perhaps a refinement of this idea would be to only do a DNS update if the
DHCP server
is handing out a new address.  Thus if we already know that this client has
a specific
IP and we hand out the same IP again to the same client, we do not have to
update
DNS.

> Diana Lane
> Wal-Mart Stores
> [email-masked]

-Dave

---

From: Diana Lane <[email-masked]>
Date: Wed, 6 Oct 1999 10:34:03 -0400 (EDT)

I sent this out last night but I don't believe it made it to the list.  Please forgive me if this is a duplicate.

Thanks!

Diana Lane
IP Research & Development
Wal-Mart Stores, Inc.
501/277-3177
Be gentle to all, and stern with yourself. - Teresa of Avila

------- Forwarded Message
Delivery-Date:	Tue Oct  5 17:35:49 1999
	>From diana  Tue Oct  5 17:35:49 1999
To:	[email-masked] <mailto:[email-masked]> 
cc:	Multiple recipients of list <[email-masked] <mailto:[email-masked]> >, diana
Subject:	Re: ddns and failover protocol 
Date:	Tue, 05 Oct 1999 17:35:36 -0500
From:	Diana Lane <[email-masked] <mailto:[email-masked]> >

	> mailto:[email-masked] <mailto:[email-masked]> 

While it is important for the DHCP server's dynamic updates to be processed, it is possible for those updates to stack up to the point where they become more of a problem than if they had simply been dropped in the first place.  Consider the case of a fairly lengthy outage with many clients hitting the backup server (RENEWs, a storm of DISCOVERs, etc.)  Add to that volume of requests to be processed the backlog of DNS updates and it may be that the backup becomes so busy updating DNS that it, too, falls behind on serving clients.  At some point, a certain percentage of the incomplete DNS updates may become outdated as the IP addresses involved are assigned to new clients.  I think the idea of preserving some of the DNS updates yet to be performed is good, but perhaps they should be dropped either after a certain period of time (at what point should they become "stale?") or when server load reaches a certain percent of "maximum capacity."  IP addresses for existing clients wi!
 ll tend to remain constant, so DNS records pertaining to those clients will be unnecessary.  Perhaps the backup should only update records for those clients that start out at DISCOVER, not for those RENEWing existing leases.
I also felt that the conference call today was productive.  It was certainly different from the majority of large conference calls I have encountered!
Diana Lane
Wal-Mart Stores
[email-masked] <mailto:[email-masked]> 

------- End of Forwarded Message

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Oct 1999 10:35:55 -0400 (EDT)

A DNS update that doesn't actually cause a change doesn't increment
the zone serial number or cause a write to disk, so it's relatively
cheap.   It still may be worthwhile to try to optimize out unnecessary
updates, but maybe it's not as crucial as one might think.

			       _MelloN_

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 6 Oct 1999 12:22:18 -0400 (EDT)

David,

I agree with Bernie, we do need to discuss this.  Let's see if we
can work it into Thursday's talk, else we'll have to discuss it
in the 3rd conference call.

My approach in the draft was to try to pass this information in
the client-fqdn option between the two server, which would send
both the name and the DNS update status between the two systems,
but I think I wasn't too clear about this, as with many things.

However, there may be a better way to handle DNS naming data
transmission between servers.

One thing that I feel strongly about is that either server should
be able to update DNS either as part of the initial lease, or if
the name changes later or the client releases the name.

Cheers -- Kim

>state of the DDNS requests. See section 6.2.7 and 7.1.1 of the 04

         I agree.

---

From: Mark Stapp <[email-masked]>
Date: Wed, 6 Oct 1999 15:50:52 -0400 (EDT)

David,

Yes, I agree that it's worth addressing ddns at some point in our 
discussions. Thanks for bringing this up, David: it sounds as if several of 
us have had this on our minds. Can I propose a couple of guidelines as a 
starting point?

1) The server which *grants* a new lease initiates a dns update. This 
server obeys its administrator on matters such as resolving conflicts, and 
determining whether to allow a client to perform its own A RR update. The 
leasing server indicates to its partner that it has or will initiate an 
update, and which records it will attempt to add, as part of the BNDUPD. 
When the dns update is completed, the leasing server indicates to its 
partner whether the update was successful in another BNDUPD. It also 
conveys the domain name that it used: this might be different from the 
domain-name that it originally attempted to use, if the server was 
configured to resolve domain-name conflicts by modifying the hostname.

2) The server which makes a lease *available* initiates a dns update to 
remove any dns records which may have been added on the client's behalf.

I believe that the 'client-fqdn' option (6.2.7 of the -04 draft) can convey 
the info. that's necessary; I can propose a set of flags values to indicate 
the types of records involved and the status of the update.

These two lease state transitions have special properties which make them 
the natural points at which to perform dns updates. This is a conservative 
list: there are some cases where one server may have initiated but not 
completed some dns update, and where the other server could 'finish' the 
update. I'm reluctant to build this case into the failover protocol draft, 
though, given the lack of field experience that we (collectively) have.

-- Mark

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Thu, 7 Oct 1999 07:31:12 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
--------------------------------------------------------------------------
> or should it be the DHCP-DNS draft that should address this?

While it is important for the DHCP server's dynamic updates to be processed,
it is possible for those updates to stack up to the point where they become
more of a problem than if they had simply been dropped in the first place.
Consider the case of a fairly lengthy outage with many clients hitting the
backup server (RENEWs, a storm of DISCOVERs, etc.)  Add to that volume of
requests to be processed the backlog of DNS updates and it may be that the
backup becomes so busy updating DNS that it, too, falls behind on serving
clients.  At some point, a certain percentage of the incomplete DNS updates
may become outdated as the IP addresses involved are assigned to new clients.
I think the idea of preserving some of the DNS updates yet to be performed is
good, but perhaps they should be dropped either after a certain period of time
(at what point should they become "stale?") or when server load reaches a
certain percent of "maximum capacity."  IP addresses for existing clients
will tend to remain constant, so DNS records pertaining to those clients will
be unnecessary.  Perhaps the backup should only update records for those
clients that start out at DISCOVER, not for those RENEWing existing leases.

I also felt that the conference call today was productive.  It was certainly
different from the majority of large conference calls I have encountered!

Diana Lane
Wal-Mart Stores
[email-masked]

---

From: Diana Lane <[email-masked]>
Date: Wed, 13 Oct 1999 16:57:37 -0400 (EDT)

-----Original Message-----
	From:	David Erdmann [SMTP:[email-masked]]
	Sent:	Wednesday, October 06, 1999 9:00 AM
	To:	Multiple recipients of list
	Subject:	RE: ddns and failover protocol

	Hi David,

	I have attempted to comment inline.  I have absolutely no idea what Outlook is going to do with this message; so far I see about four different kinds of quoting mechanisms in this!  So, please bear with me.  I am better with plain old UNIX "mail!"

	> (at what point should they become "stale?") or when server load reaches a
*	certain percent of "maximum capacity."
*	By "stale" I meant the following situation (seen with certain print servers...):
*	Client receives a lease
*	DHCP server is unable to update DNS server
*	Client is reconfigured and drops to DISCOVER
*	Client receives a new IP address (not sure if it sends a DHCPRELEASE before it DISCOVERs)
*	DHCP server queues a new set of updates for Client
*	...etc.
*	First set of updates (still unsent) is "stale."

	Yes, I like that idea.  That is more along the lines of what I was trying to express; sometimes I seem to have trouble conveying what I mean.  I would not like to see updates dropped for clients who have changed their IP address or domain, but at the same time if the client has renewed its lease on the same IP address three times, there should not need to be three sets of DNS updates.

	-Dave

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Oct 1999 12:34:13 -0400 (EDT)

> Yes, I like that idea.  That is more along the lines of what I
> was trying to express; sometimes I seem to have trouble conveying
> what I mean.  I would not like to see updates dropped for clients
> who have changed their IP address or domain, but at the same time if
> the client has renewed its lease on the same IP address three times,
> there should not need to be three sets of DNS updates. 

The ISC DHCP server (version 3.0) actually performs dynamic updates
this way currently - the DDNS update information is stored in the
lease database, and if a new lease assignment does not change the
information, no update is attempted.   Tragically, I think this could
become difficult to do with failover, because there is no way for the
DHCP servers to be absolutely certain anymore that a lease has in fact
expired.   This probably got talked about yesterday - I'm sorry I
didn't make it to the meeting.   :'(

			       _MelloN_

---

From: Rob Stevens <[email-masked]>
Date: Fri, 15 Oct 1999 19:14:20 -0400 (EDT)

>didn't make it to the meeting.   :'(

I was interested to read this, because for quite a while we have
been doing this also. We track locally the (name,IP,MAC)
triple. We always avoid trying to update DNS whenever
possible because of the expense. I would not like to
see all this go out of the window with failover.

I was glad to see that in the failover protocol the authors
had allowed for sending ip-name binding info, but I'm
also concerned about the question of servers having
different ideas about the lease expiration. Any desire
to make DNS
records have SIGs which expire with the DHCP lease
is more difficult. I think that to make this work efficiently
quite a bit more effort will need to be expended on
discussing dynamic DNS-DHCP.