A record of domain name must be name server ?

Kevin Darcy kcd at chrysler.com
Thu Sep 11 16:53:33 UTC 2014

On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote:
>> 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.
> On 11.09.14 11:20, Kevin Darcy wrote:
>> 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.
> sorry, but again - you are searching for consistency somewhere, where no
> consistency (nor a PTR) is required.
>> 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.
> I haven't met a case where this level of "consistency" would be needed.
Needed? Is that where you're setting the bar here? A little too high, 
I'd say. My point is that consistency is a good thing, and the "CNAME to 
@" practice helps to foster that. Whether it's *needed* would be a whole 
other question. Somewhere between "necessary" and (what Alan called) 
"preferences" are these things called recommendations or best practices.

> I have met a case where the "only one A should point to an IP" caused
> troubles.
Well, sure. Some names, such as zone-apex names, *cannot* own CNAME 
records. If example1.com and example2.com need to resolve to the same 
IP, then, and assuming they are both zone-apex names, you're going to 
have multiple As with the same RDATA, and a reverse-record ambiguity. 
That's unavoidable. All I'm saying, is that in the normal case, where 
you have an option, "CNAME to @" makes a lot of sense and should be 
> your argument fails immediately when there's need for more than just A on
> www.example.com
If the RDATA needs to be *different* between "www" and apex, or the 
application/subsystem which accesses the resource makes a distinction 
between canonical names and aliases, sure. I'm not laying down a 
hard-and-fast rule. Of course there will be exceptions, where the 
higher-level protocols or the user requirements demand it.
>> (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).
> ... and this is just example of it.
An example of what? Of what bad things can happen when (semi-)important 
things are left to mere "preference"?
>>> 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?
> well, me and Alan have shown examples why "www CNAME @" is not a good 
> idea.
Alan's concern was that the "www" name could get associated with record 
types that the DNS admin might not have expected. This is not a problem 
for a competent admin, who will have realistic expectations and an 
understanding of CNAME mechanics. You raised the possibility that a mail 
server might reject messages sent erroneously to "www" and I responded 
that if it's going to fail anyway, at least that failure mode is better 
than a mail server trying to deliver mail to a web server (which is what 
happens in the same scenario when "www" is an independent A record).

You got anything else?

> we both also said it's personal preference.
And I'm saying that's a cop-out. It should be a recommended practice -- 
except where there are special mitigating circumstances which make it 
inappropriate or unworkable -- not merely a "preference". Hair styles 
and musical genres are "preferences"; encouraging consistent 
forward/reverse mappings is something that all DNS admins have a stake 
in, whether they realize it or not.

>> What other RR types do you have in mind? 
> Does it matter at all? It _may_ happen, and it's the case where CNAME is
> not usable
It's not usable where it's not usable, of course. But, where it *is* 
usable, I'm just saying it's recommended, in order to prevent 
reverse-record ambiguity, and to reduce maintenance in the event that 
the IP address changes. Did you seriously think I'd recommend something 
that *doesn't*work*? Please, give me a little more credit than that.

         - Kevin

More information about the bind-users mailing list