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 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.
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
followed.
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
_______________________________________________
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
