Nictool: CNAME for @ ??

Started by Christian Adler, April 25, 2007, 01:18:08 AM

Previous topic - Next topic

Christian Adler

Hi Matt,

we found that NicTool accept CNAME-Records for the domain (@), this will cause some problems on the backends (bind: CNAME ON TOP OF DOMAIN or CNAME AND OTHER DATA).

Do you intend to include a check to prevent this record ?


Christian Adler

Add the following code to NicToolServer/Zone/Record/

    if ($data->{'type'} eq "TXT") {  # Changes by Matt Simerson to support TXT records
                if ($data->{'address'} =~ /:/) {
                        $data->{'address'} =~ s/:/\\072/;  # substitute : with \072 since : is reserved in tinydns
+    elsif ($data->{'type'} eq "CNAME" && $data->{'name'} eq "$zone_text.") {
+           $self->{'errors'}->{'address'} = 1;
+           push(@{ $self->{'error_messages'} }, "CNAME not allowed on top of domain");
+        }


I almost agree with you. But, it's not specifically disallowed. What id disallowed is having a CNAME and any other RRs for the same name (RFC 1034).  That pretty much rules out having a CNAME for a domain you wish to receive mail at, which RFC 2821 hints at.

In that spirit, I have added an additional check in Record/Sanity. Now we check to see if an A or MX records exist at the same level, and if so, disallow the creation of the CNAME.

Beyond those restrictions, I am unaware of any RFC that disallows the creation of a CNAME for

Christian Adler

Thanks, but a CNAME on produce everytime an error "CNANE and other data" because there is always a SOA on and some NS on!


The SOA doesn't count, and a zone is not required to have nameservers. A zone could have only a single RR such as ' CNAME' with no other RRs. That's perfectly legal in DNS.

As a matter of policy, I think it is not sensible to disallow legal DNS entries. OTOH, I wouldn't be adverse to someone contributing a patch that includes option to disallow certain types of records that the local admin deems inappropriate.