Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Tony F
inch writes:
> 
> John C Klensin <[e-mail]> wrote:
> >
> > If a particular SMTP implementation is aware of and follows the spec,
> > almost any consensus indicator that doesn't conflict with other things
> > should be fine --
> 
> There are actually more constraints than you imply in your message.
> 
> > "."
> 
> Has the advantage of being implemented and deployed. Has the disadvantage
> of directing useless queries to the root name servers from MTAs that do
> not understand null MX records.
> 
> > "*******"
> 
> MX target names should obey the LDH host name rules. You won't be able to
> enter this target into many DNS admin tools since they enforce LDH syntax.
> Some nameservers (e.g. BIND) will by default refuse to load a zone with
> a non-hostname MX target.
> 
> This loses the advantages of a "." target and fails to keep useless
> queries away from the root name servers.

"." is a place holder exception.  Below is a minimal zone with a MX with all
the domains set to ".".  Named will load "MX 0 ." fine.  "." prevents lots
of the internal checks at load time from triggering.

% named-checkzone zone zone
zone:1: no TTL specified; using SOA MINTTL instead
zone zone/IN: loaded serial 0
OK
% cat zone
@ SOA . . 0 0 0 0 0
@ NS .
@ MX 0 .
% 

"MX 0 ." is also consistent with "SRV 0 0 0 ." which is documented.

"no-mail.invalid" however will elicit a warning / failure depending
upon what the error level is set to.  Named-checkzone looks up every
MX target and check for A or AAAA records with the exception of
".".  It also checks that they are syntactically valid hostnames.
It also tries to determine if a IPv4 address has been used instead
of a hostname by mistake.

% named-checkzone zone zone
zone:1: no TTL specified; using SOA MINTTL instead
zone zone/IN: zone/MX 'no-mail.invalid' (out of zone) has no addresses records (A or AAAA)
zone zone/IN: loaded serial 0
OK
% cat zone
@ SOA . . 0 0 0 0 0
@ NS .
@ MX 0 no-mail.invalid.
% 

"." is a really good exception marker.  It is also the minimal
exception marker we can have.

> > a special name in example.com or example.net,
> 
> These domains are reserved for use in examples, not for production
> purposes. Are their name servers scaled up enough to handle stray
> queries from MTAs that don't understand null MX records?
> 
> This question applies to any non-"." target. The reason I suggested using
> AS112 was because it is designed for sinking unwanted queries that should
> not have leaked out in the first place. But I still prefer to stick with
> ".".
> 
> > Since SMTP prohibits non-ASCII domain names, one might even consider
> > something Like "=D1=84=D0=B8=D0=BA=D1=82=D0=B8=D0=B2=D0=BD=D1=8B=D0=B9.ex=
> ample.com" or "=E8=99=9A=E5=81=87.example.com" (literally,
> > not as IDNA A-labels) which would cause many SMTP servers to do
> > something nasty that does not involve the DNS.
> 
> You are muddling up the IDNA layers here. The MX target comes from the DNS
> so if you try to put an IDNA name there it has to be encoded as an A-label
> before you put it in the DNS. If you try hard you can put un-encoded UTF-8
> in the DNS, but then it would violate the hostname rules in a similar way
> to "*******".
> 
> It is likely that there are MTAs which do not check that MX targets
> actually obey hostname syntax, so this kind of hack is not going to
> reliably suppress lookups.
> 
> > They will certainly do lookups; how far they will get and whether they
> > will requeue and try again depends somewhat on the string chosen
> 
> I think it depends more on the MTA's and/or postmaster's attitude to DNS
> misconfiguration. Some are quicker to permfail than others.
> 
> Tony.
> --=20
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> Irish Sea: South or southeast 4 or 5, becoming variable 3 or 4. Moderate
> becoming slight. Rain or thundery showers, fog patches. Moderate or good,
> occasionally very poor.
> --1870869256-999632820-1405712346=:28941
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --1870869256-999632820-1405712346=:28941--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]