We're bouncing email to houston.rr.com due to the MX being set to localhost.
clb@countzero:~$ host -t mx houston.rr.com
houston.rr.com mail is handled by 10 localhost.
Setting the MX to 127.0.0.1 seems like an odd way to handle the switch.
<http://www.chron.com/disp/story.mpl/business/silverman/4842611.html>
--Chris
houston.rr.com, amongst other domains, went away as part of the adelphia /
comcast / roadrunner customer swap.
http://blog.wordtothewise.com/index.php/2008/01/11/changes-at-roadrunner/
I tend to agree about the MX-localhost thing (MX 0 . would be better), but
the domain is dead, jim, as far as email is concerned.
Cheers,
Steve
A bunch of roadrunner subdomains migrated over to comcast and those are dud.
One operationally better way to go seems to be Mark Delany's mx0dot
proposal, which started out as an internet draft, but seems to have
lost momentum .. the concept is sound though.
http://ietfreport.isoc.org/idref/draft-delany-nullmx
That'd mean
houston IN MX 0 .
--srs
Exim implements this convention.
Tony.
>
> One operationally better way to go seems to be Mark Delany's mx0dot
> proposal, which started out as an internet draft, but seems to have
> lost momentum .. the concept is sound though.Exim implements this convention.
Er, the concept is DNS related .. totally MTA independent. Simply
declaring that there is no MX record in a way that stops fallback to
an A record.
Exim would check for such. Other MTAs, even those that dont
explicitly check for it, would try to deliver email and fail
immediately, creating a 550 / NDN / whatever.
Basically -
To indicate that a domain never accepts email, it advertises a solitary MX RR with a RDATA section consisting of an arbitrary preference number 0, and a dot terminated null string as the mail exchanger domain, to denote that there exists no mail exchanger for a domain.
The dot termination denotes that the null MX domain is considered to be absolute, and not relative to the origin of the zone, the behavior of dot termination and the formatting of this record is as described in STD13
--srs
It's slightly more subtle than that. MTAs have to interpret MX records, so
there is plenty of variation in semantics. If an MTA does not implement
the "." convention then it will look up the root's AAAA and A records,
which is stupid but should cause the message to bounce as desired. However
if it does implement the convention (just like the "usage rules" for a SRV
record target of "." in RFC 2782) then it can skip the address lookups and
save the root some work. (It can also produce a better error message.)
This really ought to be explained in draft-delany-nullmx.
Note that an MTA can't rely on its recursive DNS server to populate the
additional section of a DNS reply, because of the truncation rules in RFC
2181. So if the additional section is empty (as it would be for an MX
target of ".") it must explicitly look up the address records to find out
if they are really missing or were just truncated. So it's worth
implementing the "." convention explicitly. (See also
http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html
for the IPv6 implications of truncated MX records.)
Tony.
The draft died. And I think this stuff about looking up A / AAAA for
the root was certainly raised in the IETF sometime back. Not that
there isnt enough junk traffic (and DDoS etc) coming the roots' way
that this kind of single lookup would get lost in the general noise ..
Might want to revive it and take it forward? I rather liked that
draft (and Mark Delany cites me in the acknowledgements as I suggested
a few wording changes for the definition of a null MX - dot terminated
null string, STD13 etc, during his drafting of the document)
--srs
In article <bb0e440a0801141838r736462dey64094e555cd6d0a6@mail.gmail.com> you write:
the "." convention then it will look up the root's AAAA and A records,
which is stupid but should cause the message to bounce as desired. However
if it does implement the convention (just like the "usage rules" for a SRV
record target of "." in RFC 2782) then it can skip the address lookups and
save the root some work. (It can also produce a better error message.)
This really ought to be explained in draft-delany-nullmx.The draft died. And I think this stuff about looking up A / AAAA for
the root was certainly raised in the IETF sometime back. Not that
there isnt enough junk traffic (and DDoS etc) coming the roots' way
that this kind of single lookup would get lost in the general noise ..Might want to revive it and take it forward? I rather liked that
draft (and Mark Delany cites me in the acknowledgements as I suggested
a few wording changes for the definition of a null MX - dot terminated
null string, STD13 etc, during his drafting of the document)--srs
--
Suresh Ramasubramanian (ops.lists@gmail.com)
There are lots of places in the DNS where "." makes sense
as a null indicator. RP uses it today, as does SRV. MX
should use it and fallback to A should be removed. It
actually takes more cache space to record that a MX record
does not exist than it takes to record that a A or AAAA
record exists (SOA rdata is atleast 22 octets).
draft-ietf-dnsop-default-local-zones used it for SOA RNAME
but was changed under WG pressure.
A and AAAA should use 0.0.0.0 and :: to indicate that a host
exists but is not currently connected.
Mark
Fallback to A should be removed sure sounds like a plan.
srs
Fallback to A should be removed sure sounds like a plan.
great idea. it will only break mail to 42% of the internet.
randy
I see roadrunner listens.
frodo:~ dig +short houston.rr.com mx
0 .
frodo:~ dig +short houston.rr.com txt
"v=spf1 -all"
--srs
Randy's right, though it's email *from* 42% of the Internet that's the
biggest problem. [rant about email from shitty php web forms elided]
Tony.