Re: Anyone from AT&T here? (AT&T bogus DNSBL answers)
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. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
At 16:06 -0400 (GMT) 17/4/04, jlewis@lewis.org wrote:
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.
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." -- Steve Linford The Spamhaus Project http://www.spamhaus.org
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.
"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
On Apr 19, 2004, at 11:54 AM, Michael.Dillon@radianz.com wrote:
"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. -- TTFN, patrick
On Mon, 19 Apr 2004 Michael.Dillon@radianz.com wrote: 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>
On Mon, 19 Apr 2004 12:45:19 PDT, just me said:
On Mon, 19 Apr 2004 Michael.Dillon@radianz.com wrote:
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.
LDAP is on port 389. ;) 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....
On 19 Apr 2004, at 16:04, Valdis.Kletnieks@vt.edu wrote:
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
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. -- Paul Vixie
participants (9)
-
jlewis＠lewis.org -
Joe Abley -
just me -
Michael.Dillon＠radianz.com -
Patrick W.Gilmore -
Paul Vixie -
Raymond Dijkxhoorn -
Steve Linford -
Valdis.Kletnieks＠vt.edu