A record of domain name must be name server ?

Kevin Darcy kcd at chrysler.com
Thu Sep 11 15:20:54 UTC 2014

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, and
>> www.example.com owns an A record, then
>> where does 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

More information about the bind-users mailing list