Dynamic DNS

[Irina Goble]

> 
> Interesting.  I wonder how they work (not enough to dig into the source
> mind you.  :-)  I wonder what/how/when they are supposed to be pruned. 
> I would imagine that named needs to keep track of where each of a zones
> slaves is with regard to ixfers and trim every now and then.
> 
	I did not dig it either. But as named starts xfer/ixfr by calling
named-xfer it needs these files.

> > 	However, Scott Dudley uses RH 6.0 and it seems the "/dev/null" staff
> > does not work as it should there.
> 
> Hmmmmm.  I have ixfr turned on between a pair of servers here.  I have
> not actually sniffed between the two of them to see what passed though. 
> Maybe I will turn a tcpdump on.
> 

	I'll check this /dev/null stuff at home on Slackware and let know
how it works in Linux.

> BTW:  I was looking at your TSIG DDNS stuff.  There is a key component
> missing in the resolver that I have made that makes your code a lot
> easier.  I always liked the idea of res_nupdate() figuring out the NS to
> send updates to all by itself.  To that end, I wrote an
> res_nupdatesigned() that works just like res_nupdate() however takes an
> additional parameter: the key to sign with.
> 
	Really I like res_sendsigned() because it is not so expensive.
Just imagine a few dns requests off! 
What I meant in the tsig patch is to have an internal cache of authoritative
NS for every zone. There are some problems:
	1. if the primary server from a SOA RR (aka a primary master) is not 
	listed in NS RRs.
	2. there are some subdomains, the patch will not recognize them.
	(if "test.example.com" is in the cache, the patch will send requests
	for "dhcp.test.example.com" zone to the primary for "test.example.com")
It just needs more code to check for rcode="not authoritative".
	
> I currently have queries in with bind-workers to find out if there was
> good reason res_nupdatesigned() was omitted or if it was just an
> oversight.
> 
> What are your thoughts on that?
> 
	I grew up and now understand that ddns transactions for forward and
reverse names should be independent.
It is logical to have FQDN in the lease structure as the dhcp-dns draft
introduces the client FQDN option (code 81). With this option updates for
forward (if any) and reverse domain names can be done independent.
	I have a question. If an administrator wants to control hostnames
(assign a fixed name or use a pattern, wharever). There is a host-name option
but how can I use it without "on commit if dns-update"? 
What is a scope of the host-name option?

> b.
> 
> 
> --
> Brian J. Murrell                              InterLinx Support Services, Inc.
> North Vancouver, B.C.                                             604 983 UNIX
>         Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD

Thank you,
Irina Goble