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).


Comments on this page:

By Dan.Astoorian at 2008-05-16 10:24:54:

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[...]

Unless there is somehow still a substantial number of clients out there which do not implement DNS NCACHE, the load from the NS record lookups should be much, much smaller than the load from A record lookups--especially if the DNS NCACHE TTL for the subzone can be tuned upwards (and if it can, there's nothing particularly evil about that).

--Dan

From 62.231.149.155 at 2008-05-16 12:19:40:

I was involved with the former opm.blitzed.org DNSBL and we still see a reasonable query load -- around 300 req/s at the moment.

Currently we have a multi-level setup whereby the zone itself has a special nameserver which then returns NS records pointing at an invalid IP for the first octet (e.g. 1.opm.blitzed.org, etc). This takes some load off the real nameservers for blitzed.org as well as keeping the website at opm.blitzed.org accessible, the downside is it probably results in more query traffic.

Interestingly we even saw RHSBL queries -- although I am now returning a positive answer for those; people who can't read what the DNSBL they are using does are unlikely to notice anything less than a slap in the face..

BTW if you haven't seen it this is discussed in the DNSBL BCP document: http://www.ietf.org/mail-archive/web/asrg/current/msg13471.html

--David Leadbeater

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, View Normal, Add Comment.
Search:
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.