COMMAND

    Dynamic DNS

SYSTEMS AFFECTED

    Those using Dynamic DNS

PROBLEM

    'Jethro Tull'  found following.  The following  is taken  directly
    from RFC2136:

      8.1. In the absence  of [RFC2137] or equivalent  technology, the
        protocol  described  by  this  document  makes it possible for
        anyone who  can reach  an authoritative  name server  to alter
        the contents of any zones on  that server.  This is a  serious
        increase  in  vulnerability   from  the  current   technology.
        Therefore it is very  strongly recommended that the  protocols
        described in this  document not be  used without [RFC2137]  or
        other equivalently strong security measures, e.g. IPsec.

      8.2. A denial of service  attack can be launched by  flooding an
        update  forwarder  with  TCP  sessions containing updates that
        the  primary  master  server  will  ultimately  refuse  due to
        permission problems.  This arises due to the requirement  that
        an  update  forwarder  receiving  a  request  via  TCP  use  a
        synchronous TCP  session for  its forwarding  operation.   The
        connection  management  mechanisms  of  [RFC1035  4.2.2]   are
        sufficient to prevent large scale damage from such an  attack,
        but not to prevent  some queries from going  unanswered during
        the attack.

    All Dynamic DNS services are vulnerable.  It is a trivial task  to
    spoof a packet (UDP  or TCP) with RR  data in the format  this RFC
    specifies.  In  other words, anyone  can manipulate RR  records by
    sending bogus data  because the only  authentication is IP.   Good
    old juggernaut should be enough for that.

    Currently most inplementations of Dynamic DNS or "DDNS" rely  upon
    only client  IP addresses  in an  access list  for authentication.
    The impact is  that anyone can  spoof update packets  from a false
    source address and the server will happily accept them.  Below  is
    the URL to a tool that  can be used to exploit the  vulnerability.
    Hopefully  vendors  will  strive  to  do  what's right in a timely
    fasion.  Spoofer Utility:

        http://www.3xt.org/projects

    Download ddns.tar.gz from there.

SOLUTION

    Well, RFC2137 and RFC1035 (4.2.2) should be enough.