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 -- ************************************** cbrentonat_private * 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:45:35 PDT