Why it is hard to decommission a DNS blocklist

May 15, 2008

Every so often some ex-DNSBL makes the geek news because its ex-operators have gotten tired of people still trying to use it years after it was taken out of service, and to fix this they make their ex-DNSBL return positive answers for every query, thereby blacklisting the world and insuring that email systems that still use the ex-DNSBL will bounce everything until they are fixed. Which should happen fast, because people generally notice when they are not getting email.

(Not always, though.)

When this happens, people invariably fume that the ex-operators should have decommissioned things in a more graceful manner. Unfortunately, there isn't really a more graceful way that deals with the underlying problem, namely that the ex-operator's DNS servers are still getting pummeled by DNSBL lookups done by all those systems that are still using the DNSBL.

(And of course the ex-operators probably no longer have all that infrastructure of volunteer secondary DNS servers to distribute the load that they had when the DNSBL was live.)

You can't get rid of these DNS queries by removing the DNSBL subzone; that just changes the load from A record lookups in your DNSBL zone to NS record lookups as systems try to find the nameservers for the zone. If you're willing to be evil you can try answering with bogus NS records with very long TTLs, but I'm not sure that this will always work (plus, you are being evil so people may howl anyway).

(Also, you can't do this if you have an informative web page that needs to show up at root of the DNSBL subzone, as was common at one point; then you still need to answer some queries for the subzone.)

You can probably spend money to make this someone else's problem, by paying your domain registrar or a DNS service providers to handle your domain's DNS for you. But I suspect that many ex-DNSBL-operators do not feel too enthused about spending their money so that other people can continue to not fix their problem (among other reasons not to cede control of your domain's DNS to a third party).

Written on 15 May 2008.
« What protects the strength of a ssh connection's encryption
Why we're interested in many ZFS pools »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu May 15 23:53:12 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.