[ale] Question about bind server behavior.

[Michael H. Warfield]

On Sat, 2014-01-25 at 14:53 -0500, JD wrote: 
> 1 of the 2 times a server I was responsible for got hacked was via bind.
> Being hacked teaches a bunch of lessons.
> * versioned backups!!  A mirror is NOT enough.

Periodic zone verification is also good.  Just to a zone transfer from
each of your exposed slaves and compare that to a pull from you're
master.

> * don't run services on the internet that aren't absolutely necessary
> * don't run bind without chroot, keep the authoritative server off the internet

Bzzt...  Wrong answer.  You have to have authoritative servers on the
internet, they just don't have to be the master authoritative server.
They can all be slaves off a private master.  Slaves and masters are all
"authoritative" for their respective zones.  Masters have the original
zone files while slaves pull their zone information from other
authoritative name servers (a master or other slaves).

Real life example.  I have three exposed authoritative name servers, all
of which pull from a private master in a secure manner.  I also get free
name server service from Hurricane Electric.  So, ns1.he.net pulls my
zone information as a slave from one of my three public name servers,
all of whom are slaves in turn.  Then ns[2345].het.net pull (slave) that
information from ns1.he.net.

So, ns[123].wittsend.com and ns[12345].he.net are all authoritative for
my zones and none of them are masters.  If you didn't have authoritative
name servers on the Internet, nobody could look you up.  You're thinking
of a "master" name server, not an "authoritative" name server.
Orthogonal attribute.

> * avoid running sendmail ... that's a diff "hacked" story.
> 
> On 01/25/2014 01:59 PM, Jim Lynch wrote:
> > On 01/25/2014 12:40 PM, Michael H. Warfield wrote:
> >> On Sat, 2014-01-25 at 12:07 -0500, Jim Lynch wrote: 
> >>> One of my host providers changed the IP address of my server.  I went to 
> >>> the bind server that provides the master records and changed the IP 
> >>> address in the tables.  I restarted bind and then did a dig 
> >>> @<masterdnsserver> <serverwithnewaddress> and it reports the old IP 
> >>> address.  Is something caching that information?
> >> 1) Did you update the serial number in the SOA?
> > Hi, Mike,
> > 
> > Yes
> >> 2) Are you sure you got the right zone file?  If bind is running chroot,
> >> you may find a copy in /var/named/data and a copy
> >> in /var/named/chroot/var/named/data.  Modern setups connect the two
> >> together through a bind mount but it use to not always be that way and
> >> an updated system won't perform the bind mount if it finds the chroot
> >> directory already populated.
> > It's not chrooted.  The /etc/named.conf file contains:
> > 
> > zone "lynch-family.info" {
> >         type master;
> >         file "/var/named/lynch-family.info.hosts";
> >         };
> > The /var/named/lynch-family.info.hosts file has a line:
> > 
> > lynch-family.info.      IN      A       107.161.113.167
> > 
> > Which is the new IP address. 
> > 
> > I'm pretty sure that's what bind is using.
> > 
> > Jim.
> >>> I thought that if I provided a server to dig it asked the system 
> >>> directly.  I guess I need to go back to school.
> >> You got the correct dig command (although I would have specified -t any
> >> and verified an updated SOA as well).
> > How interesting.  Adding the -t any found the correct address.  -t A gives me
> > the old one.    I guess I'll wait a few days and see if the right stuff gets
> > propogated.
> > 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://mail.ale.org/pipermail/ale/attachments/20140125/a04b5e43/attachment.sig>