On Tue, 15 Dec 2009, Florian Weimer wrote:

* Eric J. Esslinger:

...

I found a reference to a null MX proposal, constructed so: example.com IN MX 0 .

I think this is quite controversal.

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. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

On 2009-12-15, at 19:09, Tony Finch wrote:

On Tue, 15 Dec 2009, Florian Weimer wrote:

...

* Eric J. Esslinger:

...

I found a reference to a null MX proposal, constructed so: example.com IN MX 0 .

I think this is quite controversal.

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 :-) http://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00 Joe

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 -----Original Message-----

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 :-)

http://tools.ietf.org/html/draft-jabley-dnsop-missing-mname-00

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. Mark

Joe

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 2009-12-15, at 15:45, Dave Sparro wrote:

On 12/15/2009 10:17 AM, Eric J Esslinger wrote:

...

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.

Pulling from my often mangled memory:

This was proposed in a draft RFC that went nowhere.

http://tools.ietf.org/html/draft-jabley-sink-arpa-01 One of the imagined purposes of this draft is to be able to write example.com. IN MX 0 SINK.ARPA. and be confident that SINK.ARPA does not exist. Joe

On Tue, Dec 15, 2009 at 7:46 AM, Eric J Esslinger <eesslinger@fpu-tn.com> wrote:

So in any case, due to customer privacy concerns we feel we can't do that.

If you don't want to handle email for the long-obsolete customer accounts, but just don't want to send that mail to anybody else, it's pretty easy to run a teergrube or other tarpit system to trap any mail addressed to the A-record. These systems basically accept mail v.e.rrrr.yyyyy....s....l.....o...w...l..yyyyy so that spammers can waste their time talking to your tarpit instead of to somebody who cares, and so you can trap their IP addresses and potentially block them or use them to support your other spam-blockers if you want. You don't need a high-performance machine because all the users are spammers and you're *trying* to give them bad service. (Some variants, like LaBrea, are used for connection attempts to non-existent machines - they'll send a syn-ack so the attacker thinks he has a successful 3-way handshake, which slows down scanning attacks.) If you do want to accept mail for the long-obsolete customer accounts, so you can give them a proper human-readable rejection message, you may need to customize. It looks like Exim supports that, though I haven't tried it. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.

On 12/15/09 8:06 AM, Andy Davidson wrote:

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 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. -Doug

On Wed, 16 Dec 2009, Mark Andrews wrote:

Douglas Otis wrote:

...

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.

MX records DO NOT take IP addresses.

Or if he puts in the trailing dot it'll still cause the root server traffic he was trying to avoid. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

On 2009-12-17, at 00:02, Douglas Otis wrote:

To avoid server access and hitting roots:

host-1.example.com. IN A 192.0.2.0 ... host-10.example.com. IN A 192.0.2.9

example.com. IN MX 0 host-1.example.com. ... example.com. IN MX 90 host-10.example.com.

This will still cause DNS requests to be sent towards 192.0.2.0 and 192.0.2.9, and they may not be dropped at the first router depending on local conditions. There are implications of state in the local resolver. Choosing MX RDATA with a name that is known not to exist ideally will only exercise the local cache for the non-existent name, since it will perhaps not be the first such query and the non-existence will already be cached. SINK.ARPA doesn't exist today. The document I referred to only exists to enforce that non-existence in the future; operationally you could install MX records towards SINK.ARPA today and get the desired effect, regardless of the state of the document. Joe

Douglas Otis <dotis@mail-abuse.org> writes:

If MX TEST-NET became common, legitimate email handlers unable to validate messages prior to acceptance might find their server resource constrained when bouncing a large amount of spam as well.

none of this will block spam. spammers do not follow RFC 974 today (since i see a lot of them come to my A RR rather than an MX RR, or in the wrong order). any well known pattern that says "don't try to deliver e-mail here" will only be honoured by friend people who don't want us to get e-mail we don't want to get. -- Paul Vixie KI6YSY

Douglas Otis <dotis@mail-abuse.org> writes:

Agreed. But it will impact providers generating a large amount of bounce traffic, and some portion of spam sources that often start at lower priority MX records in an attempt to find backup servers without valid recipient information. In either case, this will not cause extraneous traffic to hit roots or ARPA.

if you're just trying to stop blowback from forged-source spam, and not trying to stop the spam itself, then some mechanism like an unreachable MX does seem called for. note that those approaches will cause queuing on the blowerbackers, rather than outright reject/die. other approaches that could cause outright reject/die would likely direct the blowback to the blowback postmasters, who are as innocent as the spam victims. i'm not sure there's a right way to do this in current SMTP. i used to think we could offer to verify that a piece of e-mail had come from us using some kind of semi-opaque H(message-id) scheme, but in studying it i found that as usual with spam the economic incentives are all backwards. -- Paul Vixie KI6YSY

On Wed, 16 Dec 2009, Douglas Otis wrote:

To avoid server access and hitting roots:

host-1.example.com. IN A 192.0.2.0 host-10.example.com. IN A 192.0.2.9

example.com. IN MX 0 host-1.example.com. example.com. IN MX 90 host-10.example.com.

This is not very good from the point of view of a legitimate but mistaken sender, because their messages will be queued and retried. The advantage of pointing MX records at nonexistent hosts is most MTAs (and all common ones) will stop trying to deliver the message immediately. It is perhaps more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups, unlike the nullmx or sink.arpa ideas. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

On Thu, Dec 17, 2009 at 6:54 AM, Tony Finch <dot@dotat.at> wrote:

On Wed, 16 Dec 2009, Douglas Otis wrote: > more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups If you want to be kind, point the MX to an A record that resolves to 127.0.0.1. Common MX'es should immediately reject, and report a "configuration error"/MX loop with the domain.

Your intent will also be clear, to just about everyone, it will be obvious the MX is intentionally broken. Other tricks may be more obscure, will be less obvious that you don't want mail, and may look like a mistake -- you might even get visitors to your domain contacting you to report the broken MX record. An alternative to resolving MX to an invalid IP might be to cut to the chase and just make further DNS lookups impossible altogether... @ 604800 IN MX MX.BOGUSMX BOGUSNS 604800 IN A 0.0.0.0 BOGUSMX 604800 IN NS BOGUSNS Or for that matter delegate the subdomain to 255.255.255.255. The recursive resolvers already have to immediately reject DNS delegation to broadcast addresses and the like. Though i'd be afraid of finding that some obscure resolver didn't...... [EG] "Gee thanks... some spammer exploited my open relay, and your broadcast NS delegation, caused my LAN to get swamped by my mail servers' DNS lookups while it was trying to send the 10 million spams to you...." -- -J

On Thu, 17 Dec 2009, James Hess wrote:

Other tricks may be more obscure, will be less obvious that you don't want mail, and may look like a mistake -- you might even get visitors to your domain contacting you to report the broken MX record.

I think that's true with the suggestions in the rest of your post.

An alternative to resolving MX to an invalid IP might be to cut to the chase and just make further DNS lookups impossible altogether... Or for that matter delegate the subdomain to 255.255.255.255. The recursive resolvers already have to immediately reject DNS delegation to broadcast addresses and the like.

That'll result in a SERVFAIL DNS reply which the MTA will treat as a temporary failure. Remember the aim is to get MTAs to give up on undeliverable mail immediately. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

On Tue, 15 Dec 2009 11:51:29 -0600, Eric J Esslinger wrote:

B. Set spf -all, for those who bother to check that to stop inbound mail from your domain.

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). -Phil