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
