[dns-operations] NS records pointing to names with CNAME records
marka at isc.org
Thu Jun 25 23:43:25 UTC 2009
In message <d791b8790906251016t1f36a5d3v41efe50ce85acfa5 at mail.gmail.com>, Matth
ew Dempsky writes:
> On Thu, Jun 25, 2009 at 9:00 AM, Paul Vixie<vixie at isc.org> wrote:
> > pretty much does not work.
> Sure, but there are situations where it would work fine with the
> current additional section processing rules:
> foo.dom. NS ns-alt.bar.dom.
> bar.dom. NS ns.bar.dom.
> ns.bar.dom. A 184.108.40.206
> ns-alt.bar.dom. CNAME ns.bar.dom.
But there are lots of case where they won't.
example.net NS ns.example.net
ns.example.net CNAME foo.example.net
foo.example.net A 220.127.116.11
You need to copy both the CNAME and the A into the parent
as glue and that just doesn't work. It's not worth the
effort of trying to make it work. Named just doesn't follow
CNAME records when looking for address of nameservers.
Eventually someone complains about the zone not working and
it gets fix. Lots of these would get fixed sooner if all
registries took their RFC 1034 obligations seriously and
periodically checked delegations to see if they are still
Named also reports this as a error when the zone is loaded.
It would be nice if other vendors did the same because there
is a whole lot of @#%$#@ out there that is relatively easy
to detect at load time. The global state of the DNS would
be better for it.
> But I'm not arguing that caches should allow this; I'm just interested
> in knowing how existing caches handle situations like this. Thanks to
> you and Mark for explaining BIND's behavior.
> >=A0as a
> > result, i know of no implementation that follows CNAME in these two
> > cases.
I don't know of any implementation that includes CNAME records in
> additional section processing, but dnscache and GbDns follow CNAME
> records when determining which IP addresses to send queries to.
> > =A0in RFC 1034 section 3.6.2 (page 15) i see this text:
> > =A0 =A0 =A0 =A0Domain names in RRs which point at another name should alw=
> ays point
> > =A0 =A0 =A0 =A0at the primary name and not the alias. =A0This avoids extra
> > =A0 =A0 =A0 =A0indirections in accessing information.
> >> I know the relevant RFCs warn that zones should not be configured this
> >> way because older caches may have problems with them, but they also warn
> >> against CNAME chains (which are commonly used),
> > begging to differ, in RFC 1034 section 3.6.2 (page 15) i see this text:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... CNAME chains should be followed and CN=
> AME loops
> > =A0 =A0 =A0 =A0signalled as an error.
> Right, the spec says caches "should" handle CNAME chains, but also
> that CNAME chains "should" not happen (see the other text you quoted).
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations