<HEAD><TITLE>Resolving dangling CNAME records</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

</HEAD>
<BODY>

<!-- Copyright 2005,2010 Sam Trenholme

    TERMS

    Redistribution and use, with or without modification, are permitted 
    provided that the following condition is met:

    1. Redistributions must retain the above copyright notice, this 
       list of conditions and the following disclaimer.

    This documentation is provided 'as is' with no guarantees of 
    correctness or fitness for purpose.

 -->

This document is for people who are getting a "dangling CNAME" warning,
or who wish to have CNAME records that point to records served by
other DNS servers.

<p>

There are two cases that can cause the "dangling CNAME" message
to appear:

<ul>
<li><A href="#nonlocal">When a CNAME points to an external host
    name.</A>
<li><A href="#local">When a CNAME is misspelled or the host the
    CNAME points to is misspelled</A>
</ul>

<A name=nonlocal>
<h3>CNAMEs pointing to external host names</h3>
</A>

Sometimes, people may wish to have local names point to external
entries with CNAME records.  For example, it may be desirable to
have the shortcut "google" for "www.google.com".  One way
one may wish to do this is as follows:

<pre>
	google.example.com. +86400 CNAME www.google.com.
</pre>

MaraDNS' default configuration will not complete the record.
In other words, some people may expect Mara to output the following
for "google.example.com":

<pre>
	google.example.com. +86400 CNAME www.google.com.
	www.google.com. +900 A 66.102.7.104
</pre>

Instead, Mara simply outputs:

<pre>
	google.example.com. +86400 CNAME www.google.com.
</pre>

I call this a "dangling CNAME record", since the CNAME record is not
resolvable by some stub resolvers.  In order to resolve dangling CNAME
records, MaraDNS can be configured thusly:

<ul>
<li>We run MaraDNS server on one IP and a Deadwood server on another IP.
<li>For the sake of this example, we will suppose that the server
  people send queries to for resolving hostnames has the IP 192.168.1.1,
  which will be running Deadwood. 
  We will further suppose that there is a MaraDNS server which has the dangling 
  CNAME issue with the IP 192.168.1.2
<li>Set up 192.168.1.1 to use 192.168.1.2 to resolve all hostnames that end
  in, say, "example.com.", via the upstream_servers dwood3rc variable.
<li>Set up 192.168.1.2 to have dangling CNAME records in the 
  authoritative half.
</ul>

This will cause dangling CNAME records to be fully resolved; here is
what the two MaraDNS servers do to resolve such a record:

<ol>
<li>A stub resolver asks 192.168.1.1 the IP address for, say 
   "google.example.com"
<li>192.168.1.1 asks 192.168.1.2 the IP address for "google.example.com" (since
    the name ends in "example.com")
<li>192.168.1.2 tells 192.168.1.1 "google.example.com is a CNAME for
    www.google.com, and I don't have an IP for it"
<li>192.168.1.1, seeing that it has a CNAME without an IP, asks
    nameservers on the internet for the IP for "www.google.com"
<li>When 192.168.1.1 has a complete record, it will send this record to
   the stub resolver.  In other words, 192.168.1.1 will tell the stub
   resolver that google.example.com is a CNAME for www.google.com, and then
   give out the IP for www.google.com.
</ol>

Here is an example <tt>dwood3rc</tt> file for 192.168.1.1:

<pre>
ipv4_bind_addresses = "192.168.1.1"
chroot_dir = "/etc/maradns"
recursive_acl = "192.168.1.0/24"
upstream_servers = {}
upstream_servers["example.com."] = "192.168.1.2"
</pre>

Here is an example <tt>mararc</tt> file for 192.168.1.2:

<pre>
ipv4_bind_addresses = "192.168.1.2"
chroot_dir = "/etc/maradns"
csv2 = {}
csv2["example.com."] = "db.example.com"
</pre>

If dangling CNAMEs are not an issue for a given setup, or if they are
resolved by the above setup using both MaraDNS and Deadwood, the warnings
about dangling CNAMEs can be turned off by adding this to a mararc file:

<pre>
no_cname_warnings = 1
</pre>

<A name=local>
<h3>A typo can cause a dangling CNAME record</h3>
</A>

A typo can also cause a dangling CNAME record.  E.g:

<pre>
www.example.com. CNAME hoost1.example.com.
host1.example.com. A 10.1.2.3
</pre>

Here, we mispelled the CNAME record; we meant to type "host1.example.com"
but typed in "hoost1.example.com".  We can also get a dangling CNAME
thusly:

<pre>
www.example.com. CNAME host1.example.com.
hoost1.example.com. A 10.1.2.3
</pre>

Or by a typo in the <tt>mararc</tt> file:

<pre>
csv2["exammple.com."] = "db.example.com"
</pre>

(We typed in exammple.com when we should have typed in "example.com")

<P>

Followed by a zone file that looks like this:

<pre>
www.example.com. CNAME host1.example.com.
host1.% A 10.1.2.3
</pre>

Since the % will expand to "exam<b>m</b>ple.com" instead of "example.com".

<P>

In all of these cases, the dangling CNAME warning will go away when the typo
is found and corrected.

</BODY></HTML>

