Does anyone know why IANA has assigned NS and A records to the
example.{com,org,net,...} domains? They even put up a website
at the IP explaining RFC 2606.
* Why did they assign NSs and a valid IP to these invalid domains?
* Are they breaking the RFC by doing this?
* Are they breaking anti-UCE filters by doing this? (yes)
* Are they harvesting URLs and referrers?
* Will they next advertise routes for RFC 1918 addresses?
Roger Marquis [1/4/2004 10:06 PM] :
Does anyone know why IANA has assigned NS and A records to the
example.{com,org,net,...} domains? They even put up a website
at the IP explaining RFC 2606.
Perhaps because at least some people don't know about RFC2606 (and they don't know RFC1918 as well, come to think of it) means and send spam complaints to IANA?
Like for example http://groups.google.com/groups?selm=396A85E6.3FC5%40whew.com
* Are they breaking anti-UCE filters by doing this? (yes)
What filter are you trying to use? and what spam did you see that forged example.* in the sender envelope / rDNS?
* Will they next advertise routes for RFC 1918 addresses?
There's a lot of polishing to be done on your tinfoil hat, amigo ... them mind rays are starting to get through.
srs
* Why did they assign NSs and a valid IP to these invalid domains?
So they can put up an explanatory website that says "Don't do that,
you idiot". This is similar to the choice of one of the RFC1918 address
blocks because a major vendor used an adddress in that block as their
"Hey there, I'm an unconfigured system" address. Sometimes, things
get done out of sheer pragmatism.
* Are they breaking the RFC by doing this?
I'd say the problem of 1918 leakage is a bigger concern. I'm sure
the example.* webserver isn't getting thousands of hits per second
like the root nameservers are seeing from 1918 addresses.
* Are they breaking anti-UCE filters by doing this? (yes)
Only in that you can't ban mail from example.com because it doesn't
have a DNS entry. (a) I don't see enough forged mail from example.com
to worry about it, and (b) I think we all should have learned about trusting
*that* check implicitly after Verisign's stunt.
* Are they harvesting URLs and referrers?
Well, the URL would point to them. What do they get out of that?
The referrer doesn't tell them anything, other than "the referer page had
an example URL that somebody was dumb enough to click on". Note that
at that point, you really *want* to hand the poor user an explanation rather
than a host-not-found (see the first point).
* Will they next advertise routes for RFC 1918 addresses?
If they want to DDoS themselves, sure.
If they did do it and your site noticed, you're obviously one of Randy Bush's
competitors who took his advice. Google for '+bgp +filter', and get some
heavier-duty aluminum foil next time you're at the supermarket.....
Having said that, I wonder who'd notice if AS701 suddenly announced the 3 1918
blocks. Like Postel's hijacking of the root, no correctly configured systems
should notice anything happened... 
* Are they breaking anti-UCE filters by doing this? (yes)
How? They own example.com. If UCE happens to contain a forged sender
of roble.com, would you consider that even remotely useful in a filter?
Why should example.com be any different? they will likely never use the
domain name, so probably wouldn't care if you feel the need to blacklist
it explicitly, for that matter.
> * Are they breaking anti-UCE filters by doing this? (yes)
How? They own example.com. If UCE happens to contain a forged sender
of roble.com, would you consider that even remotely useful in a filter?
Why should example.com be any different? they will likely never use the
domain name, so probably wouldn't care if you feel the need to blacklist
it explicitly, for that matter.
Maybe NANAE will let y'all borrow one of the troll signs.
[Attribution removed because my remark is not aimed at any one
particular potser here.)
> * Are they breaking anti-UCE filters by doing this? (yes)
How? They own example.com.
A) They don't own example.com and, B) this is the crux of the issue.
IANA was not granted special privileges by RFC2606 nor do they have
any more claim to these domains than Verisign does to unregistered
domains or expired domains.
Example.dom was placed in the pubic domain by a public and open RFC
process. It seems that IANA has violated this process and in so
doing exceeded the authority vested in them by their contract with
DARPA (and the DOC?).
If UCE happens to contain a forged sender
of roble.com, would you consider that even remotely useful in a filter?
Yes. Roble manages several email gateways for companies other than
ourselves and we've found that rejecting invalid domains and senders
is an indispensable component of spam filtering. Not only is it
effective it is also 100% false-positive proof (so far).
This is the best explanation I've read so far. Problem is, it's
not a compelling rational. Is this really the only reason for
assigning NS and A records, violating the RFC, and breaking thousands
of spam filters in the process?
Roger Marquis [1/5/2004 3:19 AM] :
This is the best explanation I've read so far. Problem is, it's
not a compelling rational. Is this really the only reason for
assigning NS and A records, violating the RFC, and breaking thousands
of spam filters in the process?
What spam did you see that forged example.* in the sender envelope / rDNS?
example.* is well worth special-casing, I dare say, if you find spam being sent with it in the headers.
Erm. No, RFC2606 specifically says:
3. Reserved Example Second Level Domain Names
The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.
example.com
example.net
example.org
4. IANA Considerations
IANA has agreed to the four top level domain name reservations
specified in this document and will reserve them for the uses
indicated.
In other words, they're IANA reserved, and you're permitted to use them
for the purposes listed in the RFC.
reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.204.69.218.218@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.204.69.218.218@example.com>
reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.204.69.218.218@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.204.69.218.218@example.com>
reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.66.207.192.254@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.66.207.192.254@example.com>
reject: RCPT from unknown[195.219.161.18]: 504 <sss>: Helo command rejected: need fully-qualified hostname; from=<sss@example.com> to=<sssx@example.com>
reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.172.153.194.136@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.172.153.194.136@example.com>
reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.172.153.194.136@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.172.153.194.136@example.com>
reject: RCPT from adsl-65-66-178-75.dsl.snantx.swbell.net[65.66.178.75]: 554 <vic@victim.com>: Recipient address rejected; from=<pekon@example.com> to=<vic@victim.com> proto=SMTP helo=<compuserve.com>
warning: 213.230.38.5: hostname reserved-multicast-range-NOT-delegated.example.com verification failed: Host not found
reject: RCPT from cmailg1.svr.pol.co.uk[195.92.195.171]: 554 <cmailg1.svr.pol.co.uk[195.92.195.171]>: Client host rejected: Access denied; from=<thetoptenwebs@www.example.com> to=<vic@victim.com>
reject: RCPT from lsanca2-ar24-4-62-187-078.lsanca2.dsl-verizon.net[4.62.187.78]: 554 Service unavailable; Client host [4.62.187.78] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?4.62.187.78; from=<bclark@dummy-host.example.com> to=<commsec@victim.com> proto=SMTP helo=<compuserve.com>
reject: RCPT from 12-252-121-69.client.attbi.com[12.252.121.69]: 554 Service unavailable; Client host [12.252.121.69] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?12.252.121.69; from=<hashao@example.com> to=<wotan@victim.com> proto=SMTP helo=<aol.com>
reject: RCPT from unknown[219.234.9.254]: 554 Service unavailable; Client host [219.234.9.254] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?219.234.9.254; from=<gorgo@dummy-host.example.com> to=<lindalu1@victim.com> proto=SMTP helo=<rambler.ru>
reject: RCPT from unknown[166.104.200.92]: 554; Client host [166.104.200.92] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?166.104.200.92; from=<cbaoqiu@dummy-host.example.com> to=<vic@victim.com> proto=SMTP helo=<microsoft.com>
reject: RCPT from host202-60.pool21759.interbusiness.it[217.59.60.202]: 554 Service unavailable; Client host [host202-60.pool21759.interbusiness.it] blocked; from=<tasminahmad@dummy-host.example.com> to=<pacgermany@victim.com> proto=SMTP helo=<mailserv>
reject: RCPT from c-66-229-245-245.we.client2.attbi.com[66.229.245.245]: 554; Client host [66.229.245.245] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.229.245.245; from=<bcwekjfeg@example.com> to=<brad@victim.com> proto=SMTP helo=<c-66-229-245-245.we.client2.attbi.com>
reject: RCPT from c-66-229-245-245.we.client2.attbi.com[66.229.245.245]: 554; Client host [66.229.245.245] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.229.245.245; from=<bcwekjfeg@example.com> to=<freekje@victim.com> proto=SMTP helo=<c-66-229-245-245.we.client2.attbi.com>
reject: RCPT from flandre-1-81-57-169-89.fbx.proxad.net[81.57.169.89]: 554; Client host [81.57.169.89] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?81.57.169.89; from=<jwxplalp@hinmavzgv.example.net> to=<daemon@victim.com> proto=SMTP helo=<flandre-1-81-57-169-89.fbx.proxad.net>
reject: RCPT from unknown[61.105.251.12]: 554 Service unavailable; Client host [61.105.251.12] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?61.105.251.12; from=<rosalia@faun.example.org> to=<jon@victim.com> proto=SMTP helo=<microsoft.com>
reject: RCPT from ool-182f3f56.dyn.optonline.net[24.47.63.86]: 554 Service unavailable; Client host [24.47.63.86] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?24.47.63.86; from=<lippmann@example.org> to=<e.retsia@victim.com> proto=SMTP helo=<compuserve.com>
reject: RCPT from mrdn-01-25.dialup.netins.net[207.177.98.90]: 504 <sss>: Helo command rejected: need fully-qualified hostname; from=<sss@example.com> to=<sssx@example.com>
reject: RCPT from 13-156.ae.cgocable.ca[24.122.13.156]: 554; Client host [24.122.13.156] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=24.122.13.156; from=<alrwv236h@example.org> to=<agodoy@victim.com> proto=SMTP helo=<13-156.ae.cgocable.ca>
...
A) They don't own example.com and,
Who says they don't? RFC never says IANA can or cannot "own".
B) this is the crux of the issue.
IANA was not granted special privileges by RFC2606 nor do they have
any more claim to these domains than Verisign does to unregistered
domains or expired domains.
The RFC never stated "IANA cannot register these domains."
It says IANA will _reserve_ the domains.
Bottomline, as long as IANA "holds" the domain, stating its
"reserved", RFC is complied.
http://www.example.com says:
"You have reached this web page by typing "example.com", "example.net", or "example.org" into your web browser.
These domain names are reserved for use in documentation and are not available for registration. See RFC 2606, Section 3.
"
Good enough. I find it fully compliant to the RFC.
Example.dom was placed in the pubic domain by a public and open RFC
process. It seems that IANA has violated this process and in so
doing exceeded the authority vested in them by their contract with
DARPA (and the DOC?).
Is that contract available in public domain? If so, have you read it?
I clearly understand your frustration but let's not make assumptions.
> If UCE happens to contain a forged sender
> of roble.com, would you consider that even remotely useful in a filter?Yes. Roble manages several email gateways for companies other than
ourselves and we've found that rejecting invalid domains and senders
is an indispensable component of spam filtering. Not only is it
effective it is also 100% false-positive proof (so far).
OK, bingo. This is a simple issue to fix. Configure your spam filter to
reject spams sourced from example.* This is not hard, and much more productive
and quickest to do on your mail server(s).
-J
Does anyone know why IANA has assigned NS and A records to the
example.{com,org,net,...} domains? They even put up a website
at the IP explaining RFC 2606.* Why did they assign NSs and a valid IP to these invalid domains?
There's already been a lot of discussion about why this is a good thing,
so I won't reiterate it all. That web site gets roughly 5 million hits a
week, so we believe that it's definitely providing a valuable
educational service to the internet community.
* Are they breaking the RFC by doing this?
We don't believe we are, and certainly wouldn't intentionally take any
action that violates the RFC's. The IANA is entrusted with safeguarding
a lot of internet resources, and it's a responsibility that we take very
seriously.
* Are they breaking anti-UCE filters by doing this? (yes)
This is an unfortunate side effect, but we believe that the user
education benefits are worth the cost.
* Are they harvesting URLs and referrers?
We log the "standard" stuff that just about any other web site would,
including URI's, referers, etc. As someone else pointed out,
"harvesting" the URI's won't really provide us any benefit. As for the
referers, if the community finds this problematic, I would have no
problem turning it off. We don't release the data, and currently we're
not doing anything with it other than logging it, so we wouldn't miss it
if it went away.
Hopefully this information is useful. If you have any further questions,
please feel free to contact me.
Doug
I'd say the problem of 1918 leakage is a bigger concern.
Quite a big problem. Because some of the major backbones don't bother to
filter that address space in the src of the packets, DDoS tools just love
forging UDP packets with reserved space, which makes it nearly impossible to
correctly track down where its coming from.
A good example of this issue is with at least two of the AHBL nameservers run
by the SOSDG (I have no idea what the other nameservers are seeing as they are
not managed by us, but they are probably getting similar queries), someone
from 192.168.1.20 is making dns queries for ip4r lookups under dnsbl.ahbl.org.
Of course, the bogon filters stop it dead in its tracks, but, the fact that
its getting through across Sprint, Cogentco, and similar isn't a good sign.
Providers should be filtering at their borders both src and dst packets going
to any of the reserved spaces. If they did, this wouldn't be an issue.
Now, the better question is, what idiot is doing those dnsbl queries on our
servers, and why haven't they noticed that the lookups don't work, and
resolving in general probably isn't working? Who knows.
< Side note: sorry about the weird quoting. OE-Quotefix is somehow barfing
on your message specifically and crashing, so I had to turn it off >
But, it has to be done carefully. Our RHSBL (part of the AHBL) is based on
this idea - but, we are extremely careful in what we block exactly. A single
wrong block (aol.com for example) could have really bad side affects for
anyone using the list. As such, the best way to use a domain style block is
to try and only use it on the mainsleeze spammers for example, that spam from
their (many) domains they own.
We had to do this with topic's spammy domains in order to allow our users to
keep getting messages from mailing lists hosted off of topica's main domain.
Each type of blacklisting has to be carefully thought out, and implemented
correctly. A combination of a DNSbl, a RHSbl, a whitelist, and something
similar to spamassassin gives you the flexability to block alot of spam
without needing to block everything outright.
> * Are they breaking anti-UCE filters by doing this? (yes)
This is an unfortunate side effect, but we believe that the user
education benefits are worth the cost.
As long as IANA isn't sending email using that domain, then it should be
trivial for email admins to block anything claiming to come from that domain.
Thanks Doug. Are those discussions available on the net? If so
could you post the URL?
The discussion I'm referring to is the one that happened on the NANOG
list subsequent to your post.
Doug