[TAG] How to do DNS right ;->

[Rick Moen]

----- Forwarded message from rick -----

Date: Tue, 22 Nov 2005 15:51:05 -0800
To: ecain at phosphor.net
Subject: cain.org's DNS

Eric, I just wanted to alert you to some minor problems with your
cain.org domain's DNS.  (As a reminder, my nameserver does secondary for
it.  I periodically check on the health of domain I do DNS for.)

Have a look through
http://www.dnsreport.com/tools/dnsreport.ch?domain=cain.org  .  It's a 
valuable overview.  Detail on some items highlighted is given below:


1.  With only two nameservers, your DNS is a little thin.  You really
should have somewhere between three and seven, inclusive.  It's
therefore in your interest to find a couple of others, I think.
Naturally, I try to make sure mine's reliable, though.  ;->


2.  Your parent (.ORG) zone lacks glue records for _both_ nameservers.
This isn't a _very_ serious problem, as its only consequence in this
case is that queries on cain.org require two lookups to find the
nameserver, instead of the standard single lookup.  So, your nameservice
is slower than it needs to be.

That is, if something needs to find a host's IP within cain.org, the
first thing it does is send a query to .ORG's nameservers, asking what 
NS entries exist for it.  The reply would be NS1.PHOSPHOR.NET and
NS1.LINUXMAFIA.COM, but extra "glue" information should ideally be sent
for those entries saying that, by the way, NS1.PHOSPHOR.NET has IP
address 207.7.137.130 and NS1.LINUXMAFIA.COM has IP address
198.144.195.186.`  

In the absence of "glue" information, the process trying to look up 
your DNS information has to follow up on its NS query ("What are the
nameservers for this domain?") with A queries.  ("Gee, it's nice that
you gave me NS entries' hostnames, but I also need to look up the
matching IPs before I can actually do anything with that data.")

This isn't a serious problem because it's only a minor slowdown, and the
query results get cached thereafter.  But it's suboptimal.

Ordinarily, one would try to fix this situation by having you edit your
NS records at your registrar's domain records for cain.org, which would
result in both NS and matching "glue" A records in your parent .ORG
zonefiles.  The problem is that glue records for .NET and .COM domain 
names probably will not be accepted by the .ORG nameservers, and most 
caches wouldn't accept them anyway, because .ORG has no authority for
glue records out of its "bailiwick".

My recommendation:  Fix that situation by creating NS and A records for
both existing nameservers right _in_ your zonefile, as part of
cain.org's own zone records, assigning them cain.org names for DNS
purposes, like this:

                IN      NS      ns1.cain.org.
		IN	NS	ns2.cain.org.
ns1		IN	A	207.7.137.130
ns2             IN      A       198.144.195.186

(Increment your zonefile serial number, save, exit, reload the zone.)

_Then_, go to your administrative CGI for your domain records at OpenSRS
/ Tucows, Inc. (your registrar), and swap in NS1.CAiN.ORG and
NS2.CAIN.ORG for the existing NS1.PHOSPHOR.NET and NS1.LINUXMAFIA.COM
entries.  (A lot of novice DNS admins get this wrong, adding "NS" lines
to their zonefiles and somehow expecting the top-level domains to
somehow magically detect and implement their intention to make those
new nameservers authoritative.  It doesn't work that way:  It's the NS
records in your _parent_ zone, not your own zonefile, that make your
domain's nameservers authoritative.)

Some would object that this means you have to update the zonefile
if/when the two nameservers' IPs change -- which is true, but misses the
point that you'd have to fix this in your /etc/bind/named.conf's
allow-transfer lines anyway, so having to also update the zonefile IPs
is no big deal.

Note that, if you follow my recommendation, you will also want to
replace NS1.PHOSPHOR.NET in your zonefile's SOA header with
NS1.CAIN.ORG, that being the indicator about where your master DNS 
is located.


3.  Your domain doesn't yet accept mail to abuse at cain.org, which it 
really should, as that is required by RFC2142.  You can direct that 
mail to wherever postmaster mail goes.

A lot of your outbound mail from cain.org may be going unread for lack
of that record:  I actually had to whitelist your domain; otherwise, my
spam-rejection routines would have refused all mail from your domain.


4.  Your zonefile doesn't yet have an SPF record.  I'd recommend you 
follow the www.dnsreport.com page's link to generate one, and add it to
your zonefile.  This costs you only five minutes of your time, and means
that MTAs that check incoming mail's SPF DNS records can detect and
reject forgeries that fraudulently claim to be from your domain.

----- End forwarded message -----