--On Friday, July 18, 2014 20:39 +0100 Tony Finch <d...@dotat.at>
wrote:
> 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.
Yes, almost certainly.
>> "."
>
> 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.
I completely agree, but SMTP imposes no such requirement.
> 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.
Does that imply that this spec should contain a warning that
loading one of these "null MX" records may require a
configuration change in one's nameserver? Just asking.
> This loses the advantages of a "." target and fails to keep
> useless queries away from the root name servers.
>
>> 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?
Yep. Sorry for not selecting a better example, but I hope the
point was clear.
> 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 ".".
Ok, thanks for clarifying.
>> Since SMTP prohibits non-ASCII domain names, one might even
>> consider something Like "фиктивный.example.com" or
>> "虚假.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 "*******".
I'm actually not... and sorry if I wasn't clear. Because SMTP
doesn't impose any restrictions on what it can pick up from MX
DATA (presumably the only limits are those imposed by 2181) and
knows nothing about IDNA, un-encoded UTF-8 (or, for that matter,
un-encoded UTF16 or something else as long as it is within the
64 byte label limit, is just meaningless trash -- far further up
the "trash" scale than "******". If an implementation chooses
to apply host name checks (or SMTP mailbox domain name validity
checks) that seems wise to me, but goes beyond what SMTP
requires.
> 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.
Exactly. They are different examples of guaranteed bogus
strings; they don't help a bit with the query problem. If we
really want help with the query problem, we need to update SMTP
(see previous over-long note to DNSOP, which I'll forward to you
under separate cover.
>> 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.
Yep, And that is independent of whether we agree about what
constitutes "DNS misconfiguration". Had you said
"misconfiguration, abuse, or stupidity", we'd probably agree.
:-)
john
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
