From owner-freebsd-hackers  Fri Oct 11 09:23:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA10118
          for hackers-outgoing; Fri, 11 Oct 1996 09:23:39 -0700 (PDT)
Received: from austin.polstra.com (austin.polstra.com [206.213.73.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA10110
          for <hackers@FreeBSD.org>; Fri, 11 Oct 1996 09:23:33 -0700 (PDT)
Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id JAA04887; Fri, 11 Oct 1996 09:23:22 -0700 (PDT)
Message-Id: <199610111623.JAA04887@austin.polstra.com>
To: jkh@time.cdrom.com
Cc: hackers@FreeBSD.org
Subject: Re: Site maintainers for subdomains under freebsd.org - please read!
In-reply-to: <824.845039160@time.cdrom.com>
Date: Fri, 11 Oct 1996 09:23:21 -0700
From: John Polstra <jdp@polstra.com>
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

I have an important clarification for one part of Jordan's message:

> CNAMES:
> 
>         The following CNAMEs should be in place, just to make it easier
>         for us to figure out name server topology when things are broken:
> 
>         ns.<dom>.freebsd.org
> 
>                 Your main name server.  If you have secondaries, they
>                 should be ns2.<dom>.freebsd.org, ns3... and so on.

If a name such as "ns.<dom>.freebsd.org" is actually _used_ to specify a
name server (i.e., is referenced by a NS record), then it must not be a
CNAME.  Instead, you should use an extra A record, like this:

				NS	ns.eastjesus.freebsd.org.
	ns		IN	A	111.222.333.444
	realname	IN	A	111.222.333.444

The same goes for MX records, by the way.  They are only allowed to
reference A records, not CNAME records.

Here is the explanation, from an old comp.protocols.tcp-ip.domains FAQ:

    Date: Wed Mar  1 11:14:10 EST 1995
    Subject: Q5.6 - NS is a CNAME

    Q: Can I do this ?  Is it legal ?

       @                       SOA     (.........)
			       NS      ns.host.this.domain.
			       NS      second.host.another.domain.
       ns                      CNAME   third
       third           IN      A       xxx.xxx.xxx.xxx


    A: No.  Only one RR type is allowed to refer, in its data field, to a
       CNAME, and that's CNAME itself.  So CNAMEs can refer to CNAMEs but 
       NSs and MXs cannot.

       BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than 
       simply failing as pre-4.9 servers did.  Here's a current example:

	Dec  7 00:52:18 gw named[17561]: \
		       "foobar.com IN NS" points to a CNAME (foobar.foobar.com)

       Here is the reason why:

	  Nameservers are not required to include CNAME records in the
	  Additional Info section returned after a query.  It's partly an
	  implementation decision and partly a part of the spec.  The
	  algorithm described in RFC 1034 (pp24,25; info also in RFC 1035,
	  section 3.3.11, p 18) says 'Put whatever addresses are available
	  into the additional section, using glue RRs [if necessary]'.
	  Since NS records are speced to contain only primary names of
	  hosts, not CNAMEs, then there's no reason for algorithm to
	  mention them. If, on the other hand, it's decided to allow CNAMEs
	  in NS records (and indeed in other records) then there's no
	  reason that CNAME records might not be included along with A
	  records.  The Additional Info section is intended for any
	  information that might be useful but which isn't strictly the
	  answer to the DNS query processed.  It's an implementation
	  decision in as much as some servers used to follow CNAMEs in 
	  NS references.

--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth