[dns-operations] Curious use of cname

George Michaelson ggm at apnic.net
Thu Aug 7 00:14:37 UTC 2014


we all said symlinks were a bad idea when Berkeley did them. We also all
use them. The properties OF the symlink matter more than people realize,
because 99% of the time, they care about the properties of the object
pointed to by the symlink.

when Sun added ${symbolic} expansion on the fly to symlinks we all said it
was a bad idea.. I dont think many of us use that any more much.

oh sorry: did I say symlink? I meant CNAME. Morally, the DNSSEC sigs over
the CNAME are like the properties of the symlink. All the rest is about the
target.




On Thu, Aug 7, 2014 at 10:06 AM, Andrew Sullivan <ajs at anvilwalrusden.com>
wrote:

> On Thu, Aug 07, 2014 at 07:51:53AM +1000, Mark Andrews wrote:
> > Those with developers that don't read RFC 1034 which tried to prevent
> > this from happening.
>
> You're probably right.  But of course, RFC 1034 was written a number
> of years ago, and some of the protocol-specification language that
> later became well-understood isn't used in it.  In particular,
>
> > RR.  If a CNAME RR is present at a node, no other data should be
> > present; this ensures that the data for a canonical name and its aliases
> > cannot be different.
>
> this makes it sound like "nothing at a CNAME but a CNAME is a good
> idea" instead of "if you have a CNAME, that means by definition
> nothing else can be there."  To a naïve reader, the text above might
> read as, "You shouldn't do this, but you could.  But it'd have a bad
> consequence, and you don't want that, right?"  What it should say, of
> course, is more like, "CNAME just means that the name you looked up is
> actually some other name, therefore there MUST be no other data at the
> owner name of a CNAME."  Something like that.
>
> I've talked to people who've been facile with the DNS for a number of
> years, who didn't get that this wasn't some arbitrary rule, but was
> the very meaning of "canonical name".  If you explain it, the lights
> always go on.  But RFC 1034 does a poor job of explaining it.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140807/ccd5433d/attachment.html>


More information about the dns-operations mailing list