[Dnsmasq-discuss] Dynamic DNS

/dev/rob0 rob0 at gmx.co.uk
Fri Jun 25 18:38:22 BST 2010


On Thu, Jun 24, 2010 at 09:32:01PM +0200, clemens fischer wrote:
> /dev/rob0 wrote:
> 
> > On Thu, Jun 24, 2010 at 09:51:57AM +0100, Alberto Cuesta-Canada wrote:
> >
> >> are there any plans of implementing Dynamic DNS for dnsmasq? 
> >>  
> >> There is a perl script that adds that functionality here:
> >> http://psydev.syw4e.info/new/dynamic-dnsmasq/dynamic-dnsmasq.pl
> > 
> > I don't understand all the desire to invent new protocols for dynamic 
> > DNS. RFC 2136 handles it quite well. If dnsmasq were to add another
> > protocol, it should be RFC 2136. Dyndns.org's protocol is not a 
> > standard.
> > 
> > Some years back, before I really understood 2136, I wrote a perl/CGI 
> > frontend for nsupdate(8) which does something similar without 

Clarification: if I had known then what I know now, I would have 
solved my issue by generating a key and using nsupdate(8) over the 
Internet, rather than HTTP. As per below, I do NOT know enough about 
2136 to figure a way for it to scale.

I'm not sure I understand enough about Alberto's issue to offer any 
suggestions, but perhaps the 2136/nsupdate idea would help. He 
mentioned in followup that a Kerberos-based authentication server 
might be under consideration, and that sounds promising.

FWIW, Alberto, Windows clients do speak 2136. I think they do it by 
default, regardless of the type of nameserver they're contacting.

A confusing thing about Alberto's description is the apparent idea 
that dnsmasq does not support dynamic DNS. On the contrary, that's 
what it does, exceptionally well, by combining the DHCPd with the 
nameserver. Dynamic DNS for DHCP clients is a strong point for 
dnsmasq.

> > exposing another root-owned TCP socket to the world. By means of 
> > permissions on a copy of the key, I was able to allow the httpd(8) 
> > user to run nsupdate after authenticating the user.
> 
> I just skimmed through RFC 2136.  From a practical standpoint, it has
> a serious flaw in sections 3.3.1 and 3.3.2:
> 
>   3.3.1. Next, the requestor's permission to update the RRs named in
>   the Update Section may be tested in an implementation dependent
>   fashion or using mechanisms specified in a subsequent Secure DNS
>   Update protocol.
> 
> What good is such a drastic DNS operation when no authentication is
> defined?  Other than that the RFC reads like a stripped down version of

Hmm? You can use dnssec-keygen(8) keys for authentication. I admit, I 
don't know as practical a way to do it in the real world; DynDNS's 
protocol and my HTTP+nsupdate hack are handy for associating one 
user's records with one authentication credential.

I guess a secure way to do it is to give each user his/her own key 
and a separate zone. But that would not scale. I don't know how to 
link a key with only one RR name. I could ask the BIND folks.

> nsupdate's technical manual (if such a thing exists).  The benefit to
> not defining it there is that any mechanisms can be used.  Arriving at
> this conclusion leaves us looking at eg. dyndns's protocol.  I think
> it's one of the worst alternatives in this context:  dnsmasq often runs
> in local link areas, where people can easily snoop the credentials, and
> it mocks up an HTTP server, which is quite complicated for this task.

That's why I think my HTTP+nsupdate hack was better than DynDNS's 
protocol. No special client needed, just a web browser (or a 
scriptable HTTP client like wget(1).)

> A much simpler approach would be for the client to send the
> base64(sha1("user:password:hostname")) (a hash of user, password and
> desired, preregistered hostname) to some special host and maybe wait for
> the ACK.  That could be decoupled from dnsmasq, which is propably not
> the right place to implement it.

Agreed. I can think of many hacks, any of which would be preferable 
to adding a non-standard protocol to dnsmasq.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header



More information about the Dnsmasq-discuss mailing list