TTL problems with Bind

[cbrenton () sover net (Chris Brenton)]

I recently 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. I'm hoping this post will keep others from ending up
in the same boat I did recently. I bounced this off the bind-users group
and it has been labeled as a "bug" which will be fixed in the next
release (8.2.1). 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.).

As mentioned, 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.

I've also confirmed that this vulnerability exists in the 4.9.x port of
Bind to NT. Not sure about Microsoft DNS as I do not have a system/time
to test it. Microsoft Proxy II exhibits this problem however so my guess
would be it exists in MS DNS as well.

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.

Cheers,
Chris
--
**************************************
cbrenton () sover net

* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet