Joe Abley wrote:

On 2009-12-17, at 23:16, Ted Hardie wrote:

...

Silly question: how well would using 1.0.0.257.in-addr.arpa match the need identified in draft-jabley-sink-arpa ?

It seems like it would be equally well guaranteed to be non-existant (short of change in the def of IPv4 and in-addr.arpa). Like sink.arpa, it would get you a valid SOA and nothing else.

Am I missing something, or is this operationally equivalent?

That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist.

The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants.

I was actually thinking that what could be useful would be a generic way to signal that a service is not available. Something like "noservice" (actual label is not important) as the first label of any hostname. Then if you are a person of good will and see that MNAME or the RHS of an MX record is assigned to "noservice.example.com" you would know not to bother to try doing whatever you were trying to do (dynamic dns updates, deliver mail, etc.). I would think that further specifying that any hostname with "noservice" as the first/only label MUST resolve to 127.0.0.1, etc. I'm sure there are also some other rough edges I'm not thinking of from off the top of my head. If this is interesting I would volunteer to write a draft for it, hopefully with Joe's help? (Both since I'm poaching his idea and because he's really good at writing drafts.) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/

On Fri, 18 Dec 2009, Jason Bertoch wrote:

Isn't the fundamental problem that SMTP can fall back to an implicit MX? None of these solutions will stop spammers from skipping MX records and using direct-to-host connections.

This has nothing to do with spam.

Shouldn't we just consider dropping the implicit MX back door as opposed to getting creative with MX records that spammers will surely note and avoid anyway?

It's impossible to make that kind of incompatible change with an installed base of billions of users. It's already impossible to eliminate the AAAA fallback and keep the A fallback. 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.

I wouldn't call it impossible...difficult, maybe. Do metrics exist on how many current installs still rely on the implicit MX? Is the abuse of the implicit MX causing more harm than the effort it would take legacy DNS admins to specify an MX?

If I understand your question, you're asking how many sites don't bother with an MX record, but count on the fallback to A to get their mail delivered. I have to say I don't know and don't know of anyone who has checked. I'm not sure that's its even possible to know without starting with a full knowledge of the mail-sending entities out there. Given that many entities allow for subdomain-level mail address (research.example.com, cs.example.edu), the number of extant domain names at some level of the hierarchy would only be a predictor. Possibly someone with a very large mail installation could run statistics to show how often they fell back; that wouldn't be perfect, but it would be somewhat useful. But I think the key question is actually different. Look at this text in RFC 2821: If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error. If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than keep seeking for an A/AAAA. Is *that* useful? If so, then sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be. regards, Ted Hardie

In message <4B2BCEA2.7010402@i6ix.com>, Jason Bertoch writes:

Ted Hardie wrote:

...

But I think the key question is actually different. Look at this text in RFC 2821:

If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error.

If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than keep seeking for an A/AAAA. Is *that* useful? If so, then sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be.

Yes, I understand the RFC. That section is what allows this topic to be discussed in the first place. sink.arpa may very well be the interim solution, too. It definitely looks better than "0 .". It just seems like an ugly, smelly hack when the fundamental problem lies with allowing the implicit MX. It implies that I should, for the benefit of everyone, create a sink.arpa MX for every A record, where the effort could be better spent dropping the implicit MX rule and requiring an MX record for hosts that really do accept mail.

/Jason

"MX 0 ." is not useable. "." is not a legal host name. For those MTA's that ignore the legal hostname rule there shouldn't be any address records at "." which also make it unusable. And for those of you worring about DNSSEC costs. NODATA is 1 NSEC/NSEC3 record unless it is from a wildcard where there are some addition records, whereas NXDOMAIN is usually 2 NSEC or 3 NSEC3 records + signatures. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Fri, 18 Dec 2009, Jason Bertoch wrote:

...

Do metrics exist on how many current installs still rely on the implicit MX?

It's very common for email from web servers to be poorly configured such that it uses the webserver's hostname as the return path's mail domain.

It is very difficult to measure how many current installs rely on the implicit MX, as someone else noted. On a somewhat different angle of attack: Even five years ago, it was considered mildly problematic to deploy a hostname where the A pointed someplace incapable of receiving mail, since some "products" (you know who you are) were so poorly written and still in use that they would connect to the A (or "implicit MX" if you prefer) even in the presence of MX records. Now that another five years have passed, it would be interesting to see how many antiques are still sending e-mail AND are worth talking to. I'm guessing not many. That suggests that it might well be fine to point A at something that is not capable of receiving SMTP, as long as you have MX records. An arrangement that should always have been practical, of course. Is anyone actually doing this? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Sun, 20 Dec 2009, Joe Greco wrote:

It is very difficult to measure how many current installs rely on the implicit MX, as someone else noted.

On a somewhat different angle of attack: [...]

That suggests that it might well be fine to point A at something that is not capable of receiving SMTP, as long as you have MX records. An arrangement that should always have been practical, of course.

Is anyone actually doing this?

I can't quite answer your question yet, but here are some related numbers. I analysed the mail domains used in envelope return paths of 10 days of traffic from the start of this month (before the end of term - I work for Cambridge University). This totalled 2473192 messages from 98825 domains after spam filtering. The data is rather skewed: 43295 domains were used in only one message each. The breakdown of these domains from the DNS point of view is: total: 98825 broken: 897 - neither A nor MX records no A: 18687 no MX: 6282 mismatch: 56244 - A and MX point to different hosts partial: 380 - A is not a subset of MX match: 16335 - A is a subset of MX Note that there is some difference between the validation done by the DNS software I used for this analysis and that done by our MTA, and over a week has passed since we accepted these messages, which is why the "broken" count is non-zero. I did this using about 150 lines of perl and `adnshost -f -a`; I don't have a handy concurrent SMTP tool so the full analysis will take more work... 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.