what the heck do i do now?

bear with me, this appears to be about DNS but it's actually about e-mail.

maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing.
i've tried just about everything to get traffic toward the old domain name to
stop... right now there's a DNAME but it made no real difference. i've taken
the maps.vix.com domain away. i've set its NS to "localhost". i've put long
TTL's on both good and bad data. the traffic continues. clearly this is my
pennance for starting MAPS, and i hear you giggling about it, but i need some
advice. once upon a time, someone more insane than myself wanted to close an
RBL and did so by replacing it with a wildcard entry. we all hated that since
it caused a lot of mail to bounce. (all mail that would otherwise have been
received by that RBL's subscribers, in fact.) it did however have the effect
of causing the subscribers to reconfigure their mailers to stop querying the
now-dead RBL in question. what's the current thinking on this?

oh and even though this isn't about bgp i can put some numbers in so that it
will seem on-topic. out of 100K DNS queries received by a vix.com nameserver
(which is about five minutes worth), here are the toptalkers for maps.vix.com.
(and we all know by now that public shaming and notification won't work, i'm
not sure why this is relevant, but it looks good, so here it is.) "thoughts?"

2208 68.216.187.10
2156 192.106.1.99
1348 213.239.240.162
1024 192.106.1.100
808 192.106.1.1
742 216.156.2.29
659 216.55.144.5
594 192.203.136.10
592 80.247.227.1
556 24.111.1.180
535 217.18.160.2
523 87.127.246.222
438 192.106.1.9
430 192.203.136.1
384 69.20.2.227
378 213.249.17.10
355 87.98.222.35
353 216.218.185.16
331 213.251.136.18
319 72.41.223.229
274 216.65.0.148
264 61.194.193.9
257 200.75.51.132
251 213.234.128.211
248 213.251.134.167
222 69.38.230.2
208 219.232.224.89
193 213.249.17.11
178 200.75.51.133
175 204.212.38.12
170 209.244.4.235
167 211.5.1.220
158 200.62.191.36
150 195.178.70.10
147 212.125.128.91
147 192.247.72.254
145 202.180.64.9
144 216.46.201.220
135 164.164.149.13
134 203.97.32.3
132 66.98.240.151
129 84.14.44.250
122 206.40.201.230
118 195.14.50.1
108 211.5.1.219
102 64.234.192.7
  98 66.235.216.48
  88 200.205.163.168
  85 69.20.2.243
  85 69.20.2.231
  85 146.83.183.94
  80 202.239.113.18
  79 199.60.229.4
  79 140.186.4.4
  78 68.125.191.131
  78 203.97.32.5
  72 80.88.192.200
  71 192.189.54.17
  70 82.210.64.18
  69 217.106.235.214
  68 202.229.192.20
  66 202.154.3.2
  64 217.19.24.18
  61 213.203.124.146
  61 195.96.33.249
  57 168.95.1.128
  56 203.94.129.130
  56 200.69.193.111
  56 168.95.1.133
  55 72.3.128.125
  54 168.95.1.145
  53 216.231.41.2
  53 210.119.192.6
  52 203.141.32.247
  52 168.95.1.132
  50 80.80.231.223
  50 204.145.230.31
  49 213.225.90.203
  48 61.129.66.75
  48 38.115.131.10
  47 195.220.32.99
  46 64.60.208.40
  46 207.12.35.170
  46 168.95.1.129
  46 168.95.1.126
  44 212.42.168.116
  44 209.128.208.11
  44 168.95.1.148
  43 84.14.176.166
  43 200.62.191.38
  43 154.11.147.2
  42 168.95.1.144
  41 168.95.1.131
  41 168.95.1.127
  40 81.240.254.45
  40 218.223.31.252
  40 209.82.111.202
  39 69.20.2.237
  39 217.22.50.3
  39 211.72.171.75
  39 131.188.3.89
  38 203.166.97.12
  38 199.201.145.162
  38 168.95.1.147
  38 12.98.160.66
  37 69.36.241.228
  37 168.95.1.146
  37 131.130.199.155
  36 200.31.192.18
  34 216.174.17.6
  34 209.61.163.233
  34 200.207.88.142
  34 168.95.1.92
  32 80.247.228.1
  32 69.60.117.147
  31 67.18.97.50
  30 202.175.151.10
  27 168.95.1.99
  26 216.127.136.207
  26 212.245.255.2
  26 195.2.96.2
  25 216.244.191.38
  25 212.86.129.142
  25 199.64.0.252
  24 212.55.197.117
  24 199.166.210.2
  24 154.11.136.2
  23 216.65.0.156
  23 198.63.210.55
  23 194.204.0.1
  22 202.134.64.12
  21 84.22.6.100
  21 211.125.124.33
  21 203.198.7.66
  21 203.144.168.6
  21 203.116.1.94
  21 202.96.102.3
  21 158.234.250.70
  20 65.106.2.117
  20 213.191.73.65
  19 66.77.137.9
  19 64.65.208.6
  19 64.122.97.116
  19 203.23.72.2
  19 194.106.218.42
  17 80.255.128.145
  17 168.95.192.81
  16 194.242.40.3
  16 168.95.192.83
  15 69.20.2.225
  15 210.104.1.13
  15 207.7.4.66
  15 207.218.192.26
  15 207.106.1.2
  15 168.95.192.89
  15 168.95.192.84
  15 140.123.181.1
  14 217.10.104.109
  14 216.145.96.10
  14 212.45.26.98
  14 210.238.234.242
  14 210.236.36.2
  14 193.50.240.2
  14 193.225.16.111
  14 168.95.192.86
  14 150.186.1.1
  13 24.96.32.18
  13 218.232.110.37
  13 213.130.10.10
  13 202.237.13.66
  13 161.142.201.17
  12 168.95.192.80
  11 62.252.64.17
  11 213.171.195.168
  11 211.125.124.34
  11 210.253.165.8
  11 203.30.161.1
  11 202.45.84.68
  10 216.127.136.213
  10 212.49.128.65
  10 203.10.110.104
  10 202.134.99.162
  10 192.114.65.50
  10 168.95.192.88
  10 168.95.192.85
...

once upon a time, someone more insane than myself wanted to close an
RBL and did so by replacing it with a wildcard entry. we all hated
that since it caused a lot of mail to bounce. (all mail that would
otherwise have been received by that RBL's subscribers, in fact.) it
did however have the effect of causing the subscribers to reconfigure
their mailers to stop querying the now-dead RBL in question. what's
the current thinking on this?

one problem with this is that the pain is not felt by the misconfigured
folk, but by distant innocents.

randy

Randy Bush wrote:

once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated
that since it caused a lot of mail to bounce. (all mail that would
otherwise have been received by that RBL's subscribers, in fact.) it
did however have the effect of causing the subscribers to reconfigure
their mailers to stop querying the now-dead RBL in question. what's
the current thinking on this?

one problem with this is that the pain is not felt by the misconfigured
folk, but by distant innocents.

I don't necessarily agree with that. First off, if you set up your mail server to use "maps.vix.com", you did it a LONG time ago, before scoring systems were all the rage. In all likelihood people are using this in a binary operation "accept or don't based on this DNSBL entry's return code". Flipping that switch will completely break mail for the offending site, and (in all likelihood) they'll notice it pretty quick and stop. Or they won't, in which case, they're pretty much an unattended domain, and who really cares what happens to them anyway?

I think that at some poing, Paul has a right to attempt to reclaim the sane use of his domain name, and considering how long the DNSBL in question has been out of commission, and people who use it should know that by now, the carrot needs to be traded in for a stick.

Cheers,
D

> ... the effect of causing the subscribers to reconfigure their mailers to
> stop querying the now-dead RBL in question. what's the current thinking
> on this?

one problem with this is that the pain is not felt by the misconfigured
folk, but by distant innocents.

i am one of those who believes that e-mail is a shared benefit. so in my
worldview, both the intended recipients and actual senders would feel pain.
(bulk e-mail disproportionately benefits the sender, but i'm thinking 1x1
e-mail in this thought experiment.)

One thing you might consider is putting together a script to harvest email
addresses from whois records that correspond to the PTR for the querying
IPs. Add to that list abuse, postmaster, webmaster, hostmaster, etc @ the
poorly run domain. Then fire off a message explaining the situation and
that you'll be adding a wildcard record on such and such date (preferably
not 4/1). Script all of this and run it every couple of days until the
date you gave and then follow through with the wildcard entry. This
undoubtedly won't stop all of the whining but you can at least say you
tried.

volunteers are welcome to apply for that job.

Perhaps you can get CNet or InfoWorld to pick it and write a story about the
service and the impending change.

that, conversely, would be fun.

When it comes right down to it, you've got to do what you've got to do to
recover your domain. You provided a service that many of us relied upon.
The responsibility rests on our shoulders to keep up with the changing
times. 7-8 years is more than enough time for even the laziest of mail
admins to update their config. Think about how much bandwidth has been
wasted over the years with these errant queries...

about 1 billionth as much as has been wasted by RFC1918-sourced DNS queries
sent to the root name servers OR RFC1918-domained DNS updates sent to AS112.
therefore i treat it as a personal annoyance but NOT a waste in its own right.

100% in agreement with everything Derek says. In the immediate term, it's
*very* rude to just return false positives for everything, but
maps.vix.com hasn't been a live DNSBL since 1999...

it caused a lot of mail to bounce. (all mail that would otherwise
have been received by that RBL's subscribers, in fact.) it did
however have the effect of causing the subscribers to reconfigure
their mailers to stop querying the now-dead RBL in question. what's
the current thinking on this?

I know the guy, in fact was talking to him on the phone earlier this
afternoon and it wasn't as effective as you might hope. He may have
had to abandon the domain.

A probably not surprising number of people have decided that my
abuse.net is a DNSBL, and nothing I've been able to do makes a serious
dent. Look up the TXT record for any n.n.n.n.abuse.net where the n's
are decimal numbers.

2208 68.216.187.10

This is Integrity On Line, which purports to be a "filtered solution
provider", which I presume means a big thick firewall that keeps out
anything that might upset their subscribers. It might be illuminating
to give them a call, express concern that a computer in their center
is sending 400 unwanted messages a minute to you, and see if you can
find anyone who has any idea how the mail servers are configured. I
realize they're only a tiny percentage of your junk traffic, but their
clue level is probably typical.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

one problem with this is that the pain is not felt by the misconfigured
folk, but by distant innocents.

        etc.

One problem we have is that we tend to see the internet as a perfect
simulation of a fair and just system, at least as a first goal.

I don't know if that's possible or not. I don't know if anyone has
actually explored the issue deeply. One problem is that there are many
different notions of justice present globally. Probably thousands with
significant real-world referents.

Paul Vixie wrote:

bear with me, this appears to be about DNS but it's actually about e-mail.

maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing.
i've tried just about everything to get traffic toward the old domain name to
stop... right now there's a DNAME but it made no real difference.

Paul,

Not offering a solution but a bit of an explanation perhaps...

"If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions."

So checking the last released version:
/ucspi-tcp-0.88# grep -hn maps.vix.com rblsmtpd.c
193: if (flagwantdefaultrbl) rbl("rbl.maps.vix.com");

Looks like that could be a cause of some of your pain...
Not everyone runs rblsmptd on their mailserver, but I know lots of large mail servers that run rblsmptd (qmail).

The fact that the option is the default without being explicit means that at least some folks don't even know maps.vix.com zones are no longer present and the current failure case is not impacting them.

-david ulevitch

Thinking this out, out loud. Well, in black and white, anyway.

Your vix.com name servers are authoritative for the zone.

If a name server wants to do a lookup on maps.vix.com, it will get it
from cache, or send a query to the listed IP address for one of the name
servers.

You said you had tried, e.g., putting up a maps.vix.com zone with a huge
negative TTL - or did you say negative TTL? - but that would only work
for multiple queries for the same value from the same name server. I
don't see a clean way to "poison" even a large number of caches to
forget about you completely.

Does a large negative TTL on vix.com really not reduce the traffic much?
But then that hurts you when you add a new record, if someone has been
trying to get to that record. And there are name servers out there that
ignore negative TTL.

The only way for it not to arrive at the name server is for something in
the way to block it. Perhaps a transparent filter, or perhaps the IP
addresses of the "name servers" are your firewalls, which will block and
pass the rest on to the real name servers behind them.

Or maybe that's more work than it's worth. :wink: Is anything suffering
besides your logs?

:One problem we have is that we tend to see the internet as a perfect
:simulation of a fair and just system, at least as a first goal.
:
:I don't know if that's possible or not. I don't know if anyone has
:actually explored the issue deeply. One problem is that there are many
:different notions of justice present globally. Probably thousands with
:significant real-world referents.
:
:

Ultimately, the problem is that the idealism which was more or less the
rule a decade ago has taken a backseat to commercialism and what some see
as practicality; and arguably, some consider such a reasonable excuse for
lax maintenance (to the tune of "if it's not hurting me/my customers,
it's not a priority"). Considering the time passed since maps went
defunct, Paul is entirely justified in doing whatever is necessary to
cluebat the offending networks, imho.

Or just have everydns [or insert other free dns provider] handle your primary dns and let them handle the traffic, problem solved (for you atleast) :slight_smile:

Personally I have no sympathy to people who are using outdated dnsbl's (especially from 1999), I would consider the wildcard if you want to actually solve the problem instead of dealing with it yourself or having to hand it off to someone else.

You may also take that list of ips (with over 100 queries or so) and turn on the dnsbl with those ips added (they will only reject mail from each other but it might give some a clue).

<snip>

The only way for it not to arrive at the name server is for something in
the way to block it. Perhaps a transparent filter, or perhaps the IP
addresses of the "name servers" are your firewalls, which will block and
pass the rest on to the real name servers behind them.

The problem here is, most people that have experiences this problem, are
significantly overwhelmed with traffic of people so much as trying to do
a lookup, even if you firewall it you are still going to get an array of
queries.

In some cases, also, firewalling these queries makes it worse as servers
will query multiple times, where as if you give a response with a large
TTL they will go away. But then you have to have enough server power to
handle these queries (and outbound bandwidth to match).

I don't know how much of an impact there is in this case but I know of
other people who've had this exact same problem and the traffic load of
the attempted queries was immense.

Cheers,
Trent

We can discuss this forever. Paul can either maintain the service until he
is sick of it, and hope they go away - or kick it. He waited long enough
that even if we don't agree, hopefully non of us will have arguments with
him.

Depending on time investment issues, contacting some of the big hitters
and seeing why they hit him may be interesting and may help stop a lot of
these.

Some generic emails to the hitters may also be an over-kill, but would
satisfy some of the prettier souls among us.

  Gadi.

here's the funny thing... what if the cluebat doesn't actualy change any
delivery on the mailserver end? :slight_smile: now THAT would be pretty funny.

-Chris

DNS forward all queries and replies to myspace, Im sure they'll enjoy that!

Brian Wallingford wrote:

... Considering the time passed since maps went
defunct, Paul is entirely justified in doing whatever is necessary to
cluebat the offending networks, imho.

That's my opinion too. But I do have some domain name server addresses that get a lot of traffic due to historical misconfiguration by people who are likely too clueless to adjust it properly.

And I tried some interesting experiments around providing "wrong" wildcard answers to queries that were received.

And then, after getting some nasty complaints (including threats of legal action) from people who, for instance, didn't like that whenever their PC tried to use me as a resolver, they couldn't get to their favorite web sites any more and who weren't interested in removing me from their resolver list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)

So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.

Matthew Kaufman
matthew@eeph.com

list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)

So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.

Uhm. I don't follow?

Once you've taken all reasonable measures to tell said hospital that you're no responsible, nor inclined, to forward their mail - and they continue to ignore your warnings - surely responsibility passes to the person who ignores the warnings? (Hospital Systems Engineer and/or IT Management? Or the person who relied on Email for a life-or-death application?)

If theres no contract between you and said hospital, and you've taken reasonable steps to prevent a mishap, how is it your liability?

Or is this where I get to say 'only in America' ??

To be more relevant to the original problem, I think Paul has every right to do what he wishes with the DNS entry, short of causing anyone else a Denial of Service. (Can't be said hes denying service to any of the clients involved, as they've had no 'service' from him since 1999, as stated...)

Mark.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)

So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.

Uhm. I don't follow?

I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective:

Dear Sir:

Kiss my what?

Never hear from them again.

Chris

It's actually a trivial thing to do. Start with something like the geektools whois proxy. That'll handle getting the queries to the right RIR's whois server. Then all you need to do is parse the output for email addresses. For extra credit, you can look for common "abuse" addresses in the output and ignore other addresses in outputs where an "abuse" address is found.

As for trying to "make it stop", the two methods thought to be most successful are:

1) maps.vix.com. 604800 IN NS .

2) maps.vix.com. 604800 IN NS u1.vix.com.
    maps.vix.com. 604800 IN NS u2.vix.com.
    maps.vix.com. 604800 IN NS u3.vix.com.
    ... [as many as you like]
    u1.vix.com. 604800 IN A 192.0.2.1
    u2.vix.com. 604800 IN A 192.0.2.2
    u3.vix.com. 604800 IN A 192.0.2.3
    ... [as many as you like]

1) just tells them there is no NS, go away.

2) gives them someone unreachable to try, which they'll do, and do, and do, wasting lots of retransmitted queries and the time it takes them to timeout. If you're lucky, the timeouts might be noticed as increased load and mail slowdown on the servers sending these queries.

Either way, a properly functioning caching DNS should leave you alone for a while after caching the fact that there (is no NS for maps.vix.com||the NS's for maps.vix.com are unreachable/unresponsive). i.e. Either of these should mitigate the traffic far better than simply returning NXDOMAIN for every maps.vix.com dnsbl query.

Successful here doesn't necessarily mean "the traffic stopped" but rather the traffic has been mitigated as much as is possible without actually getting people to fix their systems and stop querying the dead zone.