[sf-lug] SF-LUG DNS

[Alex Kleider]

>    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. 

this may not be quite up to the level you need but it might be worth having a look at http://www.aboutdebian.com/dns.htm
I've found aboutdebian to be a very useful site, especially his neworking page.

> 
> 
> 
> 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/
> > 
> 
> 
> _______________________________________________
> 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/
>