I have a domain that exists solely to cname A records to another domain's websites. There is no MX server for that domain, there is no valid mail sent as from that domain. However when I hooked it up I immediately started getting bounces and spam traffic attemtping to connect to the cnamed A record, which has no inbound mail server (It's actually hitting the firewall in front of it). (The domain name is actually several years old and has been sitting without dns for a while)
I found a reference to a null MX proposal, constructed so: example.com IN MX 0 .
Question: Is this a valid dns construct or did the proposal die? I don't want to cause people problems but at the same time, I don't want any of this crap to even attempt to deliver on this domain to any of my servers.
It's valid. But if you think all spammers will respect it, you're in for a surprise.
There is also a recommendation to point the MX at somewhere unroutable (192.2.x.x IIRC, but don't quote me on that). This will force the spammer / bot to try to connect to something that does not exist and use up sockets & resources, hopefully slowing it down. I've also heard that pointing the MX at localhost is useful, for reasons that should be obvious. The latter has the slight advantage of not making networks with a default route carry packets to the DFZ.
I'm sure some will find errors with all three suggestions. I honestly don't know which is the best / worst. Personally I'd set up a tiny mail server that accepted connections & feed them to /dev/null, or maybe forwarded the whole feed to a spam trap or DCC or the like.
This was proposed in a draft RFC that went nowhere.
Parsing the Null MX record was implemented in at least one fairly popular MTA (Postfix?)
The null MX record was published by whoever got (some of?) the Excite @Home domain(s) after that company flamed out. This results in the occasional post to various mailing lists by people wondering why they are queuing mail bound for said domain.
So to the point of your question, it may reduce some SMTP connection attempts to you, but will not likely eliminate them.
I've had a couple of off-list comments already about using it as/donating it to a spam trap; That is a good idea and I actually thought of that.
However, the address was formerly used for email addresses for our customers and for our business (some 10 years ago it was registered, but has not had any valid dns records set for roughly 6 years), and we still deal from time to time with mail being sent to old addresses on that domain for various reasons (several dns registrations, for example, we've had to help these people go through the fax change system because we don't want to go to the trouble of setting up to receive email on this domain again)
So in any case, due to customer privacy concerns we feel we can't do that.
Also I have set the spf -all on it, for those that look for these records to auot-reject email from the domain.
I have a domain that exists solely to cname A records to another domain's websites.
[...]
I found a reference to a null MX proposal, constructed so:
example.com IN MX 0 .
[...]
Question: Is this a valid dns construct or did the proposal die?
It's "valid", but you will probably find people still try to spam to
machines on the A records, and all of the other weird and wonderful things
that spambots try to do to find a path that will deliver mail...
If there is no time that mail should appear *from* this domain name then
it's polite to set spf records as such - one of the few things spf is
always useful for like this :
@ IN TXT "v=spf1 -all"
... all this means in practice though is that spammers who actually bother
to check for this, will find someone else to masquerade. But you won't
have to deal with the associated attempted bounce delivery connections...
A. Use a valid domain mapped to an unroutable or loopback instead of the .
I've decided to use 127.0.0.1
B. Set spf -all, for those who bother to check that to stop inbound mail from your domain.
Already had that in place
C. Donate the spam to someone who would use it.
I can't donate the existing incoming email due to privacy concerns, however, project honeypot uses subdomains (foo@bar.example.com) for it's spam traps and wants unused subdomains so it's traps will be 'clean to start'. I'll see if I can get that done.
D. Expect some spammers to detect any MX strangeness you use and bypass it in favor of your A record.
Understandable, and none of the referenced records in the DNS files accept mail from outside, connections are silently dropped at the firewall. This is just an attempt to cut the mess coming in because of the A record down in size.
E. Set up an actual mail server routing all mail to /dev/null.
I'd rather just drop the traffic rather than have another service to maintain/secure/update
My impression from discussions on various IETF lists is that most people
think it is a good idea, it is already reasonably widely implemented, but
no-one has the time and persistence to push a spec through to publication.
I disagree. There was considerable concern with a misuse of a mechanism and its effect on various systems. That, from discussion on the IETF mailing list I was on when it was discussed there. There was no rough consensus that I could see.
SRV records documented the hostname "." as representing "no service". However, errors made by non-RFC-compliant clients still generate a fair amount of root traffic attempting to resolve A records for ".". The MX record never defined a hostname "." to mean "no service" so it would be unwise to expect email clients will interpret this as a special case meaning "no service" as well. One might instead consider using:
example.com. IN MX 0 192.0.2.0
IN MX 10 192.0.2.1
...
IN MX 90 192.0.2.9
where 192.0.2.0/24 represents a TEST-NET block.
This should ensure traffic will not hit the roots or your servers. Assuming a sender tries all of MX addresses listed, they may still attempt to resolve A records for example.com. This MX approach will affect those failing to validate email prior to acceptance, and, of course, spammers.
> Eric J Esslinger wrote:
>> I have a domain that exists solely to cname A records to another domain's
websites.
> [...]
>> I found a reference to a null MX proposal, constructed so:
>> example.com IN MX 0 .
> [...]
>> Question: Is this a valid dns construct or did the proposal die?
>
> It's "valid", but you will probably find people still try to spam to
> machines on the A records, and all of the other weird and wonderful things
> that spambots try to do to find a path that will deliver mail...
SRV records documented the hostname "." as representing "no service".
However, errors made by non-RFC-compliant clients still generate a fair
amount of root traffic attempting to resolve A records for ".". The MX
record never defined a hostname "." to mean "no service" so it would be
unwise to expect email clients will interpret this as a special case
meaning "no service" as well. One might instead consider using:
example.com. IN MX 0 192.0.2.0
IN MX 10 192.0.2.1
...
IN MX 90 192.0.2.9
Which will expand to:
example.com. IN MX 0 192.0.2.0.example.com.
IN MX 10 192.0.2.1.example.com.
....
IN MX 90 192.0.2.9.example.com.
You might as well also add a DKIM ADSP policy with "dkim=discardable".
Similar to your SPF policy, it announces that no unsigned mail (or
no mail at all in your case) should come from this domain. But DKIM
does not suffer from the problems SPF causes with email forwarding
(see recent NANOG thread on that topic).
When I attempted to document a similar idea (using an empty label in the MNAME field of an SOA record in order to avoid unwanted DNS UPDATE traffic) the consensus of the room was that the idea was both controversial and bad
>> * Eric J. Esslinger:
>>=20
>>> I found a reference to a null MX proposal, constructed so:
>>> example.com IN MX 0 .
>>=20
>> I think this is quite controversal.
>=20
> My impression from discussions on various IETF lists is that most =
people
> think it is a good idea, it is already reasonably widely implemented, =
but
> no-one has the time and persistence to push a spec through to =
publication.
When I attempted to document a similar idea (using an empty label in the =
MNAME field of an SOA record in order to avoid unwanted DNS UPDATE =
traffic) the consensus of the room was that the idea was both =
controversial and bad
Well UPDATE traffic is supposed to go to the nameservers listed in
the NS RRset prefering the MNAME if and only if the MNAME is a
nameserver. Lots of update clients don't do it quite right but
there are some that actually send to all the nameservers.
Setting the MNAME to "." does not actually address the problem.
I realize we're a bit off-topic, but to be tangential to the original topic, and thus barely relevant:
(Presuming the "sink.arpa." thing succeeds, big presumption I realize...)
So, how about using sink.arpa. as a(n) MNAME?
Or perhaps, one of the hosts listed in AS112?
Maybe a new AS112 entry that resolves to one of the IP addresses mentioned already (127.0.0.1 and friends)?
(Too bad there isn't a reserved IP address that definitively goes to /dev/null locally. Or is there?)
Does an MNAME really need to be fully qualified?
Cute idea: use the "search" of non-fully-qualified names, to direct bad UPDATE traffic to a very local server, e.g. "ns1" (no dot).
It would also be nice to have a place-holder in DNS that "resolves" (in the loose sense) to an appropriate pre-defined "thing", like the default nameserver for a client, or "yourself" for a resolver.
But I digress.
Brian
When I attempted to document a similar idea (using an empty label in the =
MNAME field of an SOA record in order to avoid unwanted DNS UPDATE =
traffic) the consensus of the room was that the idea was both =
controversial and bad
Well UPDATE traffic is supposed to go to the nameservers listed in
the NS RRset prefering the MNAME if and only if the MNAME is a
nameserver. Lots of update clients don't do it quite right but
there are some that actually send to all the nameservers.
Setting the MNAME to "." does not actually address the problem.
My personal opinion is that there's an operational need for some people to receive an explicit reply from AS112 servers, or at least that a change in current behaviour will have noticeable consequences.
Does an MNAME really need to be fully qualified?
All names in the DNS are fully-qualified on the wire, regardless of what short-cuts are available in the zone file format understood by particular pieces of software.
Cute idea: use the "search" of non-fully-qualified names, to direct bad UPDATE traffic to a very local server, e.g. "ns1" (no dot).
All names in the DNS are fully-qualified on the wire.
It would also be nice to have a place-holder in DNS that "resolves" (in the loose sense) to an appropriate pre-defined "thing", like the default nameserver for a client, or "yourself" for a resolver.
like this :