Telstra ADSL

Drake Diedrich dld at coyote.com.au
Wed Aug 7 11:01:06 EST 2002


On Tue, Aug 06, 2002 at 09:27:15PM +1000, Matthew Hawkins wrote:
> 
> I'm fairly certain that the authentication token to update the remote
> DNS server is encrypted with an MD5 or SHA1 hash when transmitting over

   The dyndns client (ddclient) doesn't do anything of the sort.

Depends: perl5, debconf (>= 0.5.0)

require 5.004;
use strict;
use Getopt::Long;
use Sys::Hostname;
use IO::Socket;

 ...

> the wire.  Check out the options in the configuration of (for example)
> BIND v9.

   Dynamic DNS has been around a long time, well before bind9's beginning
stab at Secure DNS.  Bind 8 has full support for dynamic zones, and no
crypto code.

   The bind9 secure dynamic update code is also unfinished, and no clients
or services that I'm aware of are exercising it yet.

        ... This library is considered experimental and
        is not a complete replacement for the BIND 8 resolver library.
        Applications that use the BIND 8 res_* functions to perform
        DNS lookups or dynamic updates still need to be linked against
        the BIND 8 libraries. ...

> 
> DNS should be THE most secure service on your network.  When DNS is
> broken, pretty much everything else breaks.  When the public A records
> for your company's web servers are mysteriously altered to
> 209.242.124.241 (or whatever), you'll care.


   The actual requests to the server are normal DNS requests with one bit
(UPDATE) set.  Updates are then allowed from only one host (localhost) which
runs another daemon (ddtd for example) that handles the remote traffic, a
host-password database, etc.  The protocol with the embedded password is not
DNS.  ddtd has per-machine passwords, not per-zone, so it shouldn't be
updating your static servers.  Typically you would allow updates on a
separate dynamic zone, which doesn't have to be running on your main DNS
server.  The ddt server can also send keep-alives, and remove the DNS record
(or sets it to a known unreachable value) when the host vanishes.
The free dyndns servers tend to disable this feature for economic reasons.

   Signed requests are a more secure way to handle the update, but the
update requests (today) don't typically go across any wires.

    Dynamic DNS is a shortcut to locate hosts somewhere on the Internet
that's faster than probing 2^32 machines.  Once located, you still need to
verify that you're *really* talking to the machine you think you are. DNS
doesn't address this last problem, only speeds you to it.  Public keys are
the basis for identification of hosts.  At worst, a denial of service attack
means you can't locate a host via DNS, and have to search old addresses,
wait for an incoming packet, search suspected networks, etc.  I've had to do
this when dyndns broke on a remote machine, it's a hassle but not terribly
difficult (wait for a cron-inspired email from the lost machine, and slogin
back to it from the address in the headers).  At that point you could change
the DNS password on the machine if a denial of service was the problem, or
switch to using an SSH tunnel or something like that for your ddt traffic to
the ddt server.





More information about the linux mailing list