[94748] in North American Network Operators' Group
Re: what the heck do i do now?
daemon@ATHENA.MIT.EDU (Andrew - Supernews)
Sun Feb 4 21:37:15 2007
To: nanog@merit.edu
In-Reply-To: <9400B49E-8173-4C16-B6AB-CF83B0D912BA@kumari.net> (Warren
Kumari's message of "Sun, 4 Feb 2007 16:30:24 -0800")
Date: Mon, 05 Feb 2007 02:36:10 +0000
From: "Andrew - Supernews" <andrew@supernews.net>
Errors-To: owner-nanog@merit.edu
>>>>> "Warren" == Warren Kumari <warren@kumari.net> writes:
Warren> Sure, but if we could all agree that 127.255.255.255 (or
Warren> something) means that the BL has been shutdown then in the
Warren> future this sort of issue could be mitigated.
You don't need to agree on something - it's already possible to apply
automated checks to a DNSBL that detect all known methods of shutting
it down.
Applying these same checks in configuration tools would also prevent
users specifying things which are not live DNSBLs, thus avoiding a
lot of excess query load on nameservers that just happen to serve
domains that have been mistaken for DNSBLs.
The algorithm is very simple:
- if 1.0.0.127.dnsbl.example. is not NXDOMAIN, this is a hard failure.
- if 2.0.0.127.dnsbl.example. is NXDOMAIN or SERVFAIL, or lacks an
A record, or has an A record which is not 127.x.x.x, then this is a
soft failure.
- otherwise the test passes.
DNSBLs that soft-fail should be removed from use but continue to be
tested regularly, and at least optionally added back automatically if
they pass within a reasonable period (days, say) of failing - after
that they should be treated as hard failures and removed completely.
Warren> Yes, this doesn't fix Paul's problem (or anyone who setup a
Warren> blacklist before this is standardized) and there is no way to
Warren> enforce this, but it is bunch better than not doing
Warren> anything...
It has been possible all along, so why aren't people doing it already?
--
Andrew, Supernews
http://www.supernews.com
