[sf-lug] SF-LUG DNS

[jim]

   (continuing on the list in case others are 
interested, which i hope they are--i could use 
some help.) 

   you're right, as usual, rick. this is entirely 
my doing and fault, partly due to ignorance. 
   we replaced the old machine with a new one. the 
old machine was pretty much a classic unix box 
(CentOS 4 or 5). the new machine uses debian XEN 
to implement two virtual machines, one for balug, 
the other for sf-lug (which is now using the 
correct ip address). 

(...skipping the details of the last two days' 
confused actions...) 

   i'll have to bring up the old machine and find 
the dns files then copy them to the new machine. 
   probably a poor idea to have a master dns 
server on the box that the dns points to, yes? 

   per your subsequent email re a third dns name 
server, that's my fault, too: i got distracted in 
the middle of the process (of learning what to 
type in which files) and dropped the ball. i'll 
go pick the ball back up. 
   i wish i could find a tutorial that succinctly 
and completely explains the rudiments of setting 
up dns for and on a linux system: this would 
summarize the concepts and then specify the files 
to create and/or modify and finally present 
several examples to exemplify common use cases. 



On Sat, 2009-11-14 at 00:56 -0800, Rick Moen wrote:
> 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.
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>