In message <alpine.lsu.2.00.1407182019070.28...@hermes-1.csi.cam.ac.uk>, Tony F inch writes: > > John C Klensin <john-i...@jck.com> 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 <d...@dotat.at> 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --1870869256-999632820-1405712346=:28941-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
