Wandering Thoughts archives


Why it is hard to decommission a DNS blocklist

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

spam/DNSBLDecommissioningProblem written at 23:53:12; Add Comment

What protects the strength of a ssh connection's encryption

Here is a suddenly burning question: what protects the strength of a ssh connection's encryption?

The answer is that the connection encryption is protected only by the strength of the random numbers chosen for the initial Diffie-Hellman key exchange that arranges the session key. This protection depends on both the server and the client using strong random numbers; if an attacker can guess the random number for either side, they can immediately recover the session key simply by acting out that side of the exchange.

The server's host key doesn't get involved in the actual Diffie-Hellman key exchange; it is merely used to sign a shared secret in order to verify that the server is who it says it is. This means that a weak server key doesn't weaken the connection encryption (although it enables man in the middle attacks), but also that a strong server key is no protection if either side is using weak random numbers.

(This comes from RFC 4253, section 8.)

The answer to the next burning question is that OpenSSH gets its random numbers (at least for Diffie-Hellman) from the OpenSSL libraries.

tech/SshEncryptionProtection written at 00:17:54; Add Comment

By day for May 2008: 1 2 3 4 5 6 7 8 9 11 12 13 15 17 18 19 20 21 23 24 25 26 28 29 30 31; before May; after May.

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.