A record of domain name must be name server ?
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 203.0.113.48, and
>>>> www.example.com owns an A record 203.0.113.48, then
>>>> where does 126.96.36.199.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.
> 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
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
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
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.
More information about the bind-users