unsuccessful update of A record

David W. Hankins David_Hankins at isc.org
Tue Apr 4 17:01:13 UTC 2006


On Tue, Apr 04, 2006 at 07:42:37AM +0000, Simon Hobson wrote:
> IIRC the query sent to do the update is something like :
> IF <name> A a.b.c.d does NOT exist
>   OR <name> TXT <some long text key> does exist
> THEN
>   ADD <name> A a.b.c.d
>   ADD <name> TXT <some long text key>

There is no logical-OR in dynamic dns updates.  There are only prerequisite
statements.

First we send a packet that looks something like this:

	PREREQ:	[name] NONE A
	ADD:	[name] IN A	a.b.c.d
	ADD:	[name] IN TXT	"magic hashed string here"

IF result is success, you're done.
IF result is YXDOMAIN, you send another packet:

	PREREQ:	[name] IN TXT	"magic hashed string here"
	DELETE:	[name] ANY A
	ADD:	[name] IN A	a.b.c.d

That second update has a tendency to fail unless you configure
one-lease-per-client, I suspect because what we actually get is
YXRRSET rather than YXDOMAIN (I think the author understood that
he could ask "IN.A" in a prereq with another field he passed to the
update mechanism set to NXDOMAIN and expect to hear YXDOMAIN in
response...what actually happens is not what he anticipated...the
NXDOMAIN/NXRRSET set on that field passed to the software that makes
the packets just decides wether the class field for the prereq RR is
set to NONE or ANY, so that is lost).

I've left that bug the way it is because the problem is larger than
that.

Let me explain.  I think 'delete all A records for this binding' (the
DELETE does that) is not the way this should work.  I think any A
records that are valid for a given binding should remain on the zone,
not merely the most recent one.  You should have to configure something
to get the other behaviour, where only one binding exists at any given
time.

Which is what one-lease-per-client means.  Expire any other bindings,
on other networks, if a client gets a new binding elsewhere.  That's
not safe in the general, reference case.


So we're rewriting this in 3.1 (along with several other changes to
sync up with recent IETF standards actions).

We'll actually have a few 'algorithms' to choose from at config time
if I get my way:

1) Default - add DHCID/A bindings if NXDOMAIN.  Add A bindings on
YXRRSET checking for the DHCID.  Delete specific A bindings upon
expiry, form a second packet to delete DHCID only if no A/AAAA bindings
remain.

	- clients get multiple addresses in forward mapping
	- they drop out as they expire (or are released).
	- but there's some risk that stale A records will persist on
		the name (timeouts etc).  we'll have to see what we can
		do about that.
	- the DHCID is never removed unless no A/AAAA bindings
		remain.

2) Current behaviour (fixed) - same as above, but delete all A/AAAA
bindings to add a new one, and delete DHCID so long as the current
correct A is still up there (along with all A bindings).  We assume
other agents deleting AAAA bindings will do the same.

	- clients get their most recently known to be correct single
		address.
	- less recent addresses do not expire out the more recent one.
	- the client is cleaned up after when the last lease expires,
		and also when the next lease begins.
	- so there's never any staleness
	- but, the client will also only get one: A or AAAA.  in order
		for this to work, you have to delete all AAAA to add an
		A, and delete all A to add a AAAA.
	- but who uses ipv6 anyway, right?

3) "Stake a Claim" - same as default, except DHCID is not deleted
unless the client explicitly RELEASEd their lease.  The DHCID stakes
a "claim" on that name that survives client addressing changes, so
no one can steal your favorite name while you're offline.

	- much of the same as the default case
	- only now it's also known that stale DHCIDs will exist as
		people forget to release before they change their
		names (or retire boxes).
	- oh, and they have to release /all/ their active leases,
		since the DHCID delete will still look for other
		rrsets as a prereq.


So at this point we're talking about a complete rewrite, and so a
feature release.

Since the one-lease-per-client hack works today for everyone who's
had this problem, I see no reason to spend time fixing up the existing
code, time which could be spent on the rewrite effort.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins


More information about the dhcp-users mailing list