On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:
On 10.09.14 18:13, Kevin Darcy wrote:
No, what I'm saying is that if
example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then
where does 48.113.0.203.in-addr.arpa point?
Completely your decision.
Some people will point it at example.com, some will point it at
www.example.com. What you get is a mish-mosh. No consistency.
Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.
The issue is consistency. If you give admins choices where to point a
PTR, and the RFCs don't provide any clear guidance, you're going to get
inconsistent results.
If you make "www" a CNAME to apex, then the RFCs are clear that you
can't point the PTR to the "www" name. The *only*legal*choice* is to
point the PTR at the apex name. You're going to get *much*more*
consistent results.
Consistency is a good thing, isn't it? Sure, the earth isn't going to
fall off its axis of rotation just because of the way people point their
A and PTR records, CNAME or don't CNAME. But if we can nudge people in
the direction of consistency, and there is no downside, why wouldn't we
do that? That's what "best practices" are all about -- impelling people
towards processes/methods/conventions that ultimately benefit
*everyone*. Greatest good for the greatest number, and all that.
If, on the other hand, www.example.com is a CNAME to example.com,
then it's crystal clear where the reverse record will point --
example.com. There is no ambiguity or option for inconsistency.
If you point www CNAME @, the 'www' will have both MX and NS records
same as
example.com. Which may e.g. cause rejectd on backup MX hosts, apparently
not designed to receive mail for www.example.com.
So, is it better that mail sent erroneously to www.example.com fall
through the RFC 5321 algorithm and attempt to be delivered to the A
record? That host is almost certainly is a *web* server and quite likely
to not even be listening on port 25. After some period of time, the user
ultimately gets a "connection timed out, still retrying" NDR and
scratches their head trying to figure out what went wrong. Meanwhile,
the sending MTA keeps on retrying, web server sees "garbage" traffic on
an off-port and generates ICMP packets back to the source. In the "CNAME
to @" scenario, at least the mail gets rejected promptly by a *mail*
server, you have a nice clear audit trail on the server side and a
meaningful error message (e.g. "I don't accept mail for the
www.example.com domain") back to the user.
(Yes, I'm aware that there was a proposal recently discussed on the
DNSOP list for an MX-target convention to denote "no mail service
offered here". That would presumably solve the problem I cited in the
previous paragraph. But AFAIK that proposal is many years away from
widespread adoption, and even if adopted, it puts an extra burden on the
DNS admins to populate the "no service" MX record, which, again, is
going to produce inconsistent results -- some admins will remember to do
it; many won't).
Obviously, if one wants mail for example.com and www.example.com to be
delivered to *different* MX targets, then "CNAME to @" isn't an option.
But in the general case, where you don't want mail to www.example.com to
be deliverable *at*all*, "CNAME to @" is quite a viable option;
arguably, a *better* option, since the failure mode is faster and
cleaner than directing MTAs to try to deliver mail, as per RFC 5321, to
a web server.
The same applies for all other RRs for exmaple.com Alan named crap.
Actually, the only other RR type that Alan enumerated specifically was
NS, which operates on entirely different principles, and serves a
significantly different function, than MX-based mail routing. Who would
be looking up www.example.com with QTYPE=NS? Is that even a plausible
use-case scenario?
What other RR types do you have in mind? SRV records? They have their
own defined naming structure, which effectively precludes apex naming.
TXT records used for SPF purposes? Worst case for that is that the same
hosts trusted to send mail for example.com are also trusted to send mail
for www.example.com -- but *sending* mail servers are presumably under
the control (directly or indirectly) of the domain owner, so the
potential for negative fallout seems rather minimal. Something else? Are
you thinking that a LOC record should be differentiated between "www"
and apex, if the web server is physically in a different datacenter than
the corporate headquarters of the domain owner?
- Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
