[sf-lug] SF-LUG DNS
jim
jim at well.com
Sat Nov 14 19:18:44 PST 2009
outstanding! tons of thanks!
On Sat, 2009-11-14 at 12:34 -0800, Alex Kleider wrote:
> > 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/
> >
>
>
>
>
More information about the sf-lug
mailing list