Autodetection of IP address for nsupdate of A record

/dev/rob0 rob0 at gmx.co.uk
Sun Apr 24 14:08:35 UTC 2011


On Sun, Apr 24, 2011 at 10:32:39AM +0200, Jan-Piet Mens wrote:
> > Now I want to do it right, but I don't see a way for nsupdate
> > to do what httpd does: autodetection of client IP address for 
> > nsupdate of its A record.
> > 
> > I can script something on the client end to get the IP address, 
> > but if possible I'd prefer autodetection, which would be OS-
> > and shell-agnostic. Is that possible?
> 
> No, that isn't possible. As you say, you'd have to script
> something around it on the client side.

(Another agnosticism I forgot to list: NAT router.) My dynamic DNS 
service is private, but over the years I have offered it to friends 
and family, some of whom are non-technical. So while I can augment 
it, I will not be able to replace my CGI webform with this plan.

Over the years I wondered why public dynamic DNS services reinvented 
these wheels, with custom clients rather than using nsupdate. Now it 
makes sense. While indeed, RFC 2136 had *me* covered, it didn't scale 
well to provide this service to the masses.

(That said, I think my approach of using Web form authentication 
scales far better than custom software clients. My Unix users run a 
simple wget in boot and/or cron scripts. A Windows user can make/use 
a Web "shortcut." Any browser can keep a bookmark.)

> > So if I wanted my home server to be able to nspdate with a SIG(0) 
> > key, that works, but I can't have my named use that key to AXFR
> > or IXFR my zones?
> 
> Correct. Bv9ARM section 4.5.5 specifies that ACL definitions for
> allow-{query|transfer} have been extended to allow TSIG keys, but
> there is no mention of SIG(0) keys.
> 
> I use SIG(0) for granting updates, and TSIG for restricting AXFR.

Good enough. Makes sense, anyway, not to expect too much from a 
single key. I'll do this as well.

Thanks for taking the time to reply.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header



More information about the bind-users mailing list