[FYI: I'm mostly just observing, letting the discussion run... But this
deserved comment in terms of the intent behind the BCP]
Douglas Otis wrote:
On Feb 9, 2007, at 6:31 AM, Bill Cole wrote:
I think not. DNSBL operators seem to be very fond of rbldnsd, which
does not implement zone transfers. I can't speak for how Spamhaus
moves zones to its authoritative servers or in from primary sources
like the CBL, but their data feeds to big users are via rsync of
When a DNSBL is successful at blocking bad actors controlling perhaps
thousands of systems, defending against a DDoS becomes a major concern.
Yes, but I don't think anything in the BCP predisposes compliant
operators putting themselves at risk of DDOS or any other hazard more
than is minimally necessary to provide the service in the first place.
As a general principle, we tried to avoid anything that would do that.
It would seem that this DNSBL draft might be more
concerned about seeing DNSBLs go away. This might be sooner than anyone
may have wanted. Having them go away "gracefully" still means someone
is paying for bandwidth without any benefit.
DNSBLs going away ungracefully has been a source of considerable adverse
press about them. The suggested process appears to be the best way to
reduce bandwidth (both for the DNSBL and third parties) without listing
the world. You seem to prefer the blacklist the world concept
(wildcarding results). That's a VERY VERY bad idea because reality
causes everyone shutting down that way to be perceived as irresponsible
idiots, and damages the reputation of DNSBLs in general. The ripples of
the OSIRUS and Monkeys shutdowns are still reverberating and smear all
The intent of the described process is this:
1) The registered domain remains useful and unflooded with DNS queries
(whether regular queries or wild resolvers). (This was an issue with
both Osirus and Monkeys)
2) The TLD servers aren't flooded (for each query or wild resolvers)
3) the world isn't blacklisted
4) The user of the DNSBL eventually notices, without suffering a
complete loss of email.
By doing the DNSBL's base zone below the registered domain, you can have
a NS server separate from the registered domain. You can shut down
such a DNSBL by setting the DNSBL's NS to point somewhere in 127/8
(other than 127.0.0.0/24, say[+]). Since the NS TTL has been set high,
a DNSBL query won't requery it (off the registered domain's NS) very
frequently. Since no NS responds from the 127/8 address, the query
times out. Causing the user's email to be delayed by the query timeout,
not 100% blacklisted. The user's admins eventually notice the delay,
and remove the entry.
It's been suggested that setting the DNSBL's NS record to "." would do
the same, but there seems to be indications that some resolvers don't
handle that well.
One of the things we have to consider is that once a DNSBL becomes
popular, its name becomes somewhaet of a deadzone for a very long time.
If you let the registered domain expire as a way of killing the DNSBL,
wildcarding (perhaps by a domain squatter acquiring the domain, or
Verisign deploying whatever that was again) will have catastrophic
results. In some cases, you might have to keep the domain registered
forever to avoid something nasty.
[Try doing DNSBL queries against letter transpositions of "spamhaus.org"
some day. You should find several typosquatters wildcarding to their
web sites which means 100% blacklisting to some DNSBL query clients].
[blars.org appears to have simply been allowed to expire recently. But
it's way too much a marginally used DNSBL to draw conclusions on what
would happen if, say, spamhaus.org went away.]
You did mention that the TXT record should include contact and/or
explanatory info (as in a link). We obviously forgot that, and it
should be added as a "SHOULD" or at least "RECOMMENDED".
I'm not sure what the discussion about zone transfers is all about. I
don't think many DNSBLS support real DNS zone transfers anymore. An
AXFR transfer of a DNSBL like the XBL is hideously expensive. Most
DNSBLs have settled on rsync, and other forms (various DNS protocol
methods, wget, ftp etc) have been disappearing over time. It might be
worth mentioning rsync as the "defacto standard DNSBL bulk transfer
mechanism", but leave it at that.
[+] Putting the NS on 127.0.0.1, say, could be extremely dangerous - the
MTA using the DNSBL may be coresident with a DNS resolver that returns
wierd results that we can't predict the MTA can handles properly.
Asrg mailing list