COMMAND

    BIND

SYSTEMS AFFECTED

    most unices (and NT)

PROBLEM

    Chris Brenton  found following.   Recently he  ran into  a problem
    with Bind that can  allow an old ISP  to effect connectivity on  a
    domain after that  domain has moved  to another service  provider.
    The best way to describe the problem is through an example.

    - The domain  fubar.com has a  current ISP (old-isp.net)  who they
      are unhappy with, and decides to move to a new service provider
    - fubar.com changes all IP addressing per the new ISP (new-isp.net)
    - fubar.com submits a name server change to the InterNIC  (Network
      Solutions) changing  their name  servers from  ns1.old-isp.net &
      ns2.old-isp.net to ns1.new-isp.net and ns2.new-isp.net.
    - The InterNIC ACKs the change and claims it is complete
    - A check of the  whois database confirms that the  fubar.com name
      servers are listed as being ns1.new-isp.net and ns2.new-isp.net.
    - A check  of the root  name servers (via  nslookup) confirms that
      ns1.new-isp.net and ns2.new-isp.net are being handed out by  the
      root name servers

    Now, one would expect  that when the TTL's  handed out by the  old
    ISP have  expired, all  Internet based  systems would  learn about
    the move via  the InterNIC and  start using the  new name servers.
    In  other  words,  if  the  old  ISP  set  a TTL of 3 days for all
    records, one  would expect  that after  3 days  all DNS servers on
    the Internet would query the  root servers and learn the  location
    of the  new name  servers.   In fact  this is  not the  case.   If
    subsequent lookups have been performed by third party name servers
    (i.e.  all  name  servers  outside  of the domains old-isp.net and
    new-isp.net), Bind refreshes the TTL for the old name server if it
    continues  to  claim  authority.  Bind  skips the root name server
    check and goes directly back to the name server which gave it  the
    information last time.  This means that if it takes weeks for  the
    old ISP  to delete  the zone  info, it  can be  weeks before third
    party name servers are forced back up to the root name servers  to
    see that the authoritative name servers have changed.

    The result is a  pretty effective denial of  service.  If the  old
    ISP  considers  removing  zone  info  files  to be very low on the
    priority scale,  or even  worse if  they are  vindictive about the
    client changing ISP's, all they need  to do is leave the old  zone
    files in place  in order to  effect connectivity by  continuing to
    hand out  the old  IP addresses  information.   Bind systems  will
    continue to return to the old ISP's name servers when ever the TTL
    expires for any A record queries, instead of finding out from  the
    root  name  servers  that  the  authority  for the domain has been
    moved.  Of course  since we are talking  about a cache issue,  the
    remote  domains  most  likely  to  be  effected  are the ones that
    communicate  with  this  domain  on  a  regular  basis   (vendors,
    customers, etc.).

    It has been also confirmed  that this vulnerability exists in  the
    4.9.x port  of Bind  to NT.   Not sure  about Microsoft  DNS,  but
    Microsoft Proxy II exhibits this problem however so guess would be
    it exists in MS DNS as well.

SOLUTION

    This will be fixed in the next release (8.2.1).  The functionality
    of Bind 8.2.1  will be changed  so that it  does not refresh  name
    server TTL's  in the  same fashion.   This will  force remote name
    servers back up to the root servers in order to verify authority.

    Unfortunately, this is one of those problem where you need to rely
    on  the  rest  of  the  world  upgrading  their systems before the
    problem is resolved (since it effects remote name servers).   With
    this in mind  the only short  term fix is  to get control  of your
    name servers prior to  a move, or make  sure they are hosted  by a
    "trusted" party.  This is the only way to insure that the old zone
    files are  deleted once  the InterNIC  records have  been updated,
    thus forcing remote name  servers to learn that  the authoritative
    servers have changed.  If you have a specific name server that you
    know has old information, you can always clear it with a restart.