[sf-lug] SF-LUG DNS

Rick Moen rick at linuxmafia.com
Sat Nov 14 00:56:18 PST 2009


Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):


> The only other immediate thing I particularly notice, is 208.96.15.252
> isn't (yet) handling DNS queries, and presuming (guessing) that
> 198.144.195.186 is slave for sf-lug.com., not master, where does it
> get that data from?  Looks like it may not have a master available to it
> "presently" (well, a bit ago, anyway).  SOA would imply it likely gets
> that data from 208.96.15.252.

Let's see:

$ whois sf-lug.com | grep "Name Server"
   Name Server: NS1.SF-LUG.COM
   Name Server: NS2.SF-LUG.COM

$ dig NS1.SF-LUG.COM +short
208.96.15.252

$ dig NS2.SF-LUG.COM +short
198.144.195.186

The latter IP address, 198.144.195.186, is my nameserver.


$ grep -A 4 sf-lug.com /etc/bind/named.conf.local
zone "sf-lug.com" {
        type slave; 
        file "/var/cache/bind/sf-lug.com.zone";
        allow-query { any; };
	allow-transfer { none; };
        masters {
	//ns1.sf-lug.com is:
        208.96.15.252;
        };
};

$ ls -l /var/cache/bind/sf-lug.com.zone 
-rw-r--r-- 1 root root 470 2009-11-11 18:29
/var/cache/bind/sf-lug.com.zone

$ cat /var/cache/bind/sf-lug.com.zone 
$ORIGIN .
$TTL 86400	; 1 day
sf-lug.com		IN SOA	ns1.sf-lug.com. jim.well.com. (
				2007102904 ; serial
				3600       ; refresh (1 hour)
				3600       ; retry (1 hour)
				1209600    ; expire (2 weeks)
				10800      ; minimum (3 hours)
				)
			NS	ns1.sf-lug.com.
			NS	ns2.sf-lug.com.
			A	208.96.15.252
			MX	5 mail.sf-lug.com.
			TXT	"v=spf1 a mx -all"
$ORIGIN sf-lug.com.
mail			A	208.96.15.252
ns1			A	208.96.15.252
ns2			A	198.144.195.186
www			A	208.96.15.252




So, there you have it.  198.144.195.186, my nameserver, is a DNS
seconary / slave / whatever-is-your-choice-of-jargon, pulling down 
zones from IP 208.96.15.252, having done so most recently at 6:29 PM,
last Wednesday.

And those IPs _are_ the authoritative servers in the parent zone (as
shown by whois).


> If 198.144.195.186 has any or all of these IPs:
> 208.69.42.165
> 208.69.42.166
> 208.96.15.252
> as its master for sf-lug.com., it will need updating.

To _what_?  I have no clue, because nobody's bothered to say anything.
Oops.

Hey, attention, guys:  You need to closely coordinate with your DNS
secondaries' sysadmins whenever you move your domain's master DNS to a
different IP.  You guys need to send e-mail (not mailing list mail) to
the guy who runs your secondaries (in this case, just me), saying that a
specified domain needs to be repointed to a new master IP.  You need to
say when this should happen.  You need to fix obsolete IPs in NS lines
in the zone you're serving from the master.  You need to make sure the
secondaries' IPs are all in the new master nameserver's allow-transfer
ACL.  You need to verify that the secondary successfully has done an
AXFR (zone transfer) from the new master IP, you need to query using dig
to make sure master and slaves are serving the new S/N (query for the
SOA).  Last, you then need to update the nameserver list in the domain
record, which ensures that the parent zone (.com, in this case) has the
correct glue records.

Again, e-mail or telephone.  Don't just blow stuff at me on a mailing
list.

I would appreciate it if you would also send me (attached to offlist
e-mail) your current revised master zonefile.  If it's anything like the
three-day-old one above, it has errors in it that need fixing.  I could
sit and detail what's wrong with the one above, but I really don't want
to then hear "Oh, but that's not what our zonefile says any more."  So,
please send the revised copy.  Thank you.

Also, I'll repeat yet again something I've told you a number of times
before:  You are violating RFC recommendations in having only two
nameservers, and it's unsafely thin service.  The RFC recommendation is
minimum three, maximum seven nameservers.

That was an important problem that you needed to fix the last n times
I've brought it to your attention.  The problem remains unfixed; you
still need to fix it, and hasn't gotten better just because you've
ignored it.





More information about the sf-lug mailing list