[sf-lug] SF-LUG domain runthrough

[Rick Moen]

I was talking to Jim in private mail about SF-LUG's Internet domain,
sf-lug.com, and the idea came up of my looking over the group's 
DNS and commenting here.


1.  DNS is pretty much basically functional, which puts SF-LUG ahead of
many.  (There's a lot of dysfunctional DNS out there.)


2.  There are only two authoritative nameservers declared in the parent
.COM zone.  This is bad.  RFC recommendations are between 3 and 7.  My
own domains have six.  Downside of two is that you're pretty fragile.

:r! dig -t ns sf-lug.com @k.gtld-servers.net +short

ns1.sf-lug.com.
ns2.sf-lug.com.

(I can't offer you a third nameserver.  I'm already your second one.)


3.  The same two nameservers are in the zone's own zonefile.  That's
good, and again puts you ahead of most people messed-up DNS.  It's vital
that, when/if nameservers change, the "NS" lines get changed at _both_ 
the zone's own zonefile and in the parent .COM zone.

:r! dig -t ns sf-lug.com +short

ns1.sf-lug.com.
ns2.sf-lug.com.


3.  The two servers _do_ have the same zonefile, which you tell by
comparing S/Ns with in the SOA (start of authority) record.  This is
good.  It means that you don't get different results depending on which 
nameserver you reach.

:r! dig -t soa sf-lug.com @ns1.sf-lug.com +short  
ns1.sf-lug.com.sf-lug.com. admin.sf-lug.com. 2007041403 3600 3600 1209600 60

:r! dig -t soa sf-lug.com @ns2.sf-lug.com +short
ns1.sf-lug.com.sf-lug.com. admin.sf-lug.com. 2007041403 3600 3600 1209600 60

The "2007041403" return value is the S/N, FYI.


4.  Someone made a (very common) error  in the SOA:  Notice the
"ns1.sf-lug.com.sf-lug.com."?  That means that someone put
"ns1.sf-lug.com" in the SOA record as the name of the master nameserver
-- omitting the trailing period.  It should be "ns1.sf-lug.com.", and
please note the period at the end of the name.

5.  VERY BAD:  See the "60" at the end of the SOA line?  That sets a
minimum TTL (time to live) for all DNS records, unless otherwise stated,
of 60 seconds.  That 's way, way, too low, and will put unjustifiable 
strain on both the nameservers (one of which is mine), plus it will lead
to many unnecessary timeouts on DNS lookups.  A setting that low should
be used only for brief periods (e.g., 1-2 days) while moving important
services, to force frequent re-checks of your DNS by setting duration of
the records' validity very low.  Conventional value for minimum TTL is 
between 3600 and 10800:  The RFC recommendation is 1-3 hours (3600 -
10800 seconds).

Please fix that ASAP.  My poor little home DSL line will be grateful.


6.  VERY BAD:  The MX (mail exchanger) record points to a CNAME (alias) 
entry, rather than an "A" record.  

:r! dig -t mx sf-lug.com +short
5 mail.sf-lug.com.

:r! dig mail.sf-lug.com 

sf-lug.com.
208.96.15.252

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52648
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; ANSWER SECTION:
mail.sf-lug.com.	43	IN	CNAME	sf-lug.com.
sf-lug.com.		43	IN	A	208.96.15.252

[...]


By RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3, MX records
(like NS ones) cannot point to a host defined by a CNAME.  Please
note that _some_ SMTP servers will refuse to deliver mail to any such 
domains.  You may already be encountering this problem, and not know it.

As a general comment, people tend to way, way, way overuse CNAMEs
in their DNS, leading them directly into problems like this one.
As a rule of thumb, if you use "A" records instead, everywhere except
for references to hosts in other domains entirely, you'll be on the
right track.

(No RFC requires people to do that.  It's just a heuristic I've come to
recommend to people, as it automatically avoids large numbers of
problems.)

7.  No SPF record.  I'd recommend one, as it then makes it possible 
for other domains elsewhere to detect that e-mail purporting to come
from an authorised SF-LUG mail server, but in fact forged, is faked
and should not be accepted as valid.  

There are other competing approaches to that problem, such as Domain
Keys.  Nothing wrong with those, and my urging putting an SPF record in
your DNS zonefile doesn't preclude taking those other measures, too.

Here's a reasonable SPF record you could put in the "@" (domain-wide)
part of your zonefile:

		IN      TXT     "v=spf1 a mx -all"

That means "This is an SPF version 1 record.  Please regard as absolutly 
complete the list of MXes (mail exchangers) for all of the sf-lug.com
domain that have either an A or an MX record in this zone's zonefile
declaring them as such.  If any other IP address connects to you and 
claims to be an authorised MX for domain sf-lug.com, you can 
absolutely without regret consider it an imposter."


I hope the above helps.  Don't forget to put the "." at the end of
all FQDNs (fully qualified domain names) in your zonefile, and don't
forget to increment the S/N whenver you make changes!  ;->