Anyone from AT&T here? (AT&T bogus DNSBL answers)

Mailman List Mirror (Read Only)
1

Steve Linford wrote:

AT&T customers have contacted us saying they can't reach any of our
DNSBLs, seems AT&T have defined a fake sbl.spamhaus.org zone in their
DNS servers so when AT&T customers ask AT&T's NS 12.149.189.2 for
sbl.spamhaus.org they get:
...

I was looking at this some more last night, and noticed this appears to
have been some kind of mistaken identity issue. Check the whois and
PTR for 12.149.189.2. It certainly doesn't appear to be an AT&T
maintained DNS server.

If there really are/were AT&T customers who couldn't resolve the various
popular DNSBLs, I wonder, was the issue caused by something else? Are
they setup to query the wrong DNS servers...perhaps 12.149.189.2 used to
be an AT&T DNS server before 2001-09-05, but since then, it's been an AT&T
customer's machine. Maybe that customer is getting hammered with queries
from old AT&T customers and is trying to encourage them to go elsewhere
for DNS service.

2

No mistake, although 12.149.189.2 is a customer's NS it uses AT&T's NS as the resolver. We've have complaints from other AT&T users about the same thing, as does another DNSBL (SpamCop), and there's now an answer from AT&T to one of their customers who forwarded AT&Ts response:

"I finally talked to someone who knows what the problem is. Your sbl sites
have been blocked by the standard DNS forwarders supplied by ATT. This is
due to the workload being generated on them from mailservers."

3

Hi!

No mistake, although 12.149.189.2 is a customer's NS it uses AT&T's
NS as the resolver. We've have complaints from other AT&T users about
the same thing, as does another DNSBL (SpamCop), and there's now an
answer from AT&T to one of their customers who forwarded AT&Ts
response:

"I finally talked to someone who knows what the problem is. Your sbl sites
have been blocked by the standard DNS forwarders supplied by ATT. This is
due to the workload being generated on them from mailservers."

Duh! This is really dumb.

Will they also block microsoft in their forwarders when there are new
patches like last week, thats also generating NS traffic...

Unbelievable.

Bye,
Raymond.

4

> "I finally talked to someone who knows what the problem is. Your sbl

sites

> have been blocked by the standard DNS forwarders supplied by ATT. This

is

> due to the workload being generated on them from mailservers."

Duh! This is really dumb.

It's not dumb at all.

DNSBLs are using the DNS to do general purpose database
lookups instead of using a generic database lookup
protocol like LDAP. It's not surprising that this sort
of ugly hack has unintended side effects. After all, people
who build DNS infrastructure intend it to be used to
for generic DNS translations, not generic database lookups.

Funny thing is that most mailer software that uses
DNSBLs also supports LDAP database lookups so there is
really no good reason why DNSBLs exist in the first
place.

IMHO, the DNSBL experiment has proved the usefulness
of having a variety of blacklist/whitelist/greylist databases
for mail servers to query. It's high time that folks
shift these databases onto a protocol that does not interfere
with the Internet's critical DNS systems and I believe that
LDAP is that protocol.

--Michael Dillon

5

"I finally talked to someone who knows what the problem is. Your sbl

sites

have been blocked by the standard DNS forwarders supplied by ATT. This

is

due to the workload being generated on them from mailservers."

Duh! This is really dumb.

It's not dumb at all.

Yes, it is.

It is not only dumb, it is a disservice to their customers. AT&T is intentionally distributing known bad information. Worse, they hid this fact from their customer. When customers called the AT&T support line to find out what happened, they were told nothing was wrong and it must be on the customer side. My understanding is this was an intentional lie. Lying to your customers is a Bad Thing [tm], IMHO.

Perhaps it was just a bunch of front line people who did not know / understand, but considering that they made a change which they knew - they *KNEW* - would break things, they should have made damned sure each and every front line person was prepared for the customer calls. They did not, so they are at best guilty of pathetically poor customer service, and possibly guilty of outright lying to their customers.

If I paid AT&T for name service (even as part of a larger package of offerings - e.g. transit), I would be *VERY* upset.

DNSBLs are using the DNS to do general purpose database
lookups instead of using a generic database lookup
protocol like LDAP. It's not surprising that this sort
of ugly hack has unintended side effects. After all, people
who build DNS infrastructure intend it to be used to
for generic DNS translations, not generic database lookups.

A DNS query is a database lookup. It is probably the most widely distributed, robust database ever designed an implemented. But it is a database, and the DNSBL queries are well formed DNS queries. The only difference between a DNSBL query and a normal host lookup is the source zone file and rate.

I wonder if Google gets too many DNS hits if AT&T will decide to filter that zone?

Funny thing is that most mailer software that uses
DNSBLs also supports LDAP database lookups so there is
really no good reason why DNSBLs exist in the first
place.

Have the mailers always supported LDAP? Do all firewalls which work as MTAs in many 1000s of corporations allow LDAP queries by default? Perhaps the creators and maintainers of the DNSBLs like to use DNS and do not like LDAP?

There are many, many possible "good reasons" for the DNSBLs to exist.

IMHO, the DNSBL experiment has proved the usefulness
of having a variety of blacklist/whitelist/greylist databases
for mail servers to query. It's high time that folks
shift these databases onto a protocol that does not interfere
with the Internet's critical DNS systems and I believe that
LDAP is that protocol.

That is possible, and much more reasonable than claiming that they have no good reason to exist in the first place.

If you believe this so fervently, perhaps you should put in effort to make it happen, instead of discarding out of hand the effort, time, and money the current maintainers have donated out to make the community better.

6

After all, people who build DNS infrastructure intend it to be
  used to for generic DNS translations, not generic database
  lookups.

Wait. What's the difference? I must have missed something.

matt ghali

--matt@snark.net------------------------------------------<darwin><
   Flowers on the razor wire/I know you're here/We are few/And far
   between/I was thinking about her skin/Love is a many splintered
   thing/Don't be afraid now/Just walk on in. #include <disclaim.h>

7

LDAP is on port 389. :wink:

DNS is intended for "give me the A record for the hostname FOO".

LDAP is a more proper tool for "Give me the list of hosts that user
Q-Froob is allowed to post mail from on Tuesdays after 5PM".

Unfortunately, some of the anti-spam proposals look more like the
latter than the former....

8

DNS is intended for "give me the A record for the hostname FOO".

DNS is currently used for "give me the resource record set of type X for the query key Y".

LDAP is a more proper tool for "Give me the list of hosts that user
Q-Froob is allowed to post mail from on Tuesdays after 5PM".

DNS has the advantages that its scaling properties are fairly well-known, it distributes easily across servers and administrative boundaries, records can be cached, and the delegation points can provide some measure of confidence that the server you're obtaining data from have some authority to dispense it (confidence ranging from "a little bit, maybe" to "high" if zones and delegations are signed, and there's a secure entry point to the chain somewhere). There are also few devices in the world that speak IP and don't already include a resolver.

DNS has lots of disadvantages too, and is cumbersome and obtuse for distribution of many types of data.

The general rule that "if it's not for associating addresses with host names, LDAP is better" is flawed though, I think.

Joe

9

i consider myself an expert on the question, "what dns is not". for
example, dns is not a directory service, or, dns is not a load balancer,
or, dns is about fact rather than policy. so, when Michael Dillon wrote
about this topic today, i decided to pay attention:

DNSBLs are using the DNS to do general purpose database
lookups instead of using a generic database lookup
protocol like LDAP.

dns is a distributed, reliable, autonomous, hierarchical database. any
data you can map into rrsets and ownernames is "fair game." see the
second half of rfc1101 (the part that goes beyond network naming) to see
what the inventor had in mind. dns blackhole lists (of which eric
ziegast invented the first one as a way to encode the first RBL into a
format sendmail could read) are an excellent example of what i call "DNS
Services". just as the web has all kinds of things on it that aren't
web pages (or web browsers) and we call those "Web Services".

It's not surprising that this sort of ugly hack has unintended side
effects. After all, people who build DNS infrastructure intend it to
be used to for generic DNS translations, not generic database lookups.

just because it isn't gethostbyname() or gethostbyaddr() and isn't
replacing the use of YP/NIS or /etc/hosts or HOSTS.TXT, does not make
it inappropriate for dns. indeed, RFC1034 2.1, 2.2 and especially 2.3
go into this in detail, so you don't need to read the (later) RFC1101
document to get the full flavour of the inventor's intentions for DNS.

Funny thing is that most mailer software that uses DNSBLs also
supports LDAP database lookups so there is really no good reason why
DNSBLs exist in the first place.

at the time the first DNS blackhole list was invented (here, by ziegast),
there was no support for LDAP in the version of sendmail we were running.

now that there are a hundred or more diverse/disparite DNS blackhole lists,
i think the likelihood of changing the way blackhole data is delivered to
be LDAP rather than DNS should be considered a "very long range" goal, or
worse.

IMHO, the DNSBL experiment has proved the usefulness of having a
variety of blacklist/whitelist/greylist databases for mail servers to
query. It's high time that folks shift these databases onto a protocol
that does not interfere with the Internet's critical DNS systems and I
believe that LDAP is that protocol.

re-inventing a distributed, hierarchical, autonomous, reliable database
just to avoid using DNS as its inventor intended it, seems like a great
waste of time, IMHO.