LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
Search this Thread
Old 10-22-2007, 10:16 PM   #16
sneakyimp
Member
 
Registered: Dec 2004
Posts: 795

Original Poster
Rep: Reputation: 50

This is a nightmare. I had BIND resolving locally after I edited /etc/resolv.conf but I couldn't figure out how to get it to respond to a 'dig' request from a remote IP. My suspicion was that this had something to do with me trying to install a cached nameserver. Sorry if I was unclear - I replaced my ISP's actual nameserver IP with 99.99.99.99 for the sake of privacy. I spoke with them today and apparently my upstream DNS servers are likely to change fairly frequently. As I understand it you can put a 'search ' directive in resolv.conf.

I would like to accomplish two things
1) Present a cached DNS server to all local services like SpamAssassin or DCC or Postfix or whatever.
2) Present authoritative DNS to any request originating outside my machine.

Is that possible? Any idea which bind I should install? CentOS 5 offers these options:
Code:
[root@server2 /]# yum list bind*
Loading "installonlyn" plugin
Setting up repositories
Reading repository metadata in from local files
Reducing Dag-RHEL-Yum to included packages only
Finished
Available Packages
bind.i386                                30:9.3.3-9.0.1.el5     updates
bind-chroot.i386                         30:9.3.3-9.0.1.el5     updates
bind-devel.i386                          30:9.3.3-9.0.1.el5     updates
bind-libbind-devel.i386                  30:9.3.3-9.0.1.el5     updates
bind-libs.i386                           30:9.3.3-9.0.1.el5     updates
bind-sdb.i386                            30:9.3.3-9.0.1.el5     updates
bind-utils.i386                          30:9.3.3-9.0.1.el5     updates
 
Old 10-22-2007, 10:38 PM   #17
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
The problem was that you installed a caching server, when that is not what you want. A cacher only answers questions about other domains, not your own. Also, stop thinking about your ISP nameservers, you won't ask them, and they have nothing to do with you answering queries. Putting them in resolv.conf has no effect on BIND, BIND will go straight to the roots then back up to you, and your ISP DNS has no place in that chain.

Here is a config directly from my nameserver, which does exactly what you want, answer all queries from your LAN, and answer any query from anywhere for your authoritative domain -

Code:
acl mydomain {192.168.0.0/24;
              10.173.52.16/28;
              10.174.10.248/30;
              99.99.99.99/32;
              127.0.0.1;
              };

options {
        pid-file "/var/run/named/named.pid";
        directory "/var/cache/bind";
        fetch-glue      no;
        allow-transfer { slave.#1.IP.addr; slave.#2.IP.addr; slave.#3.IP.addr; };
        allow-query { any; };
        allow-recursion { mydomain;};
};

//include "/etc/bind/named.conf.options";
key rndc {
algorithm hmac-md5;
secret "somelongstringofcrapthatyoudon'tshare";
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc; };
};
// reduce log verbosity on issues outside our control
logging{
  channel simple_log {
  file "/var/log/named/bind.log" versions 3 size 5m;
  severity info;
  print-time yes;
  print-severity yes;
  print-category yes;
};
channel queries {
      file "/var/log/named/queries.log" versions 5 size 10m;
      severity info;
      print-time yes;
      print-severity yes;
      print-category yes;
};
category lame-servers { null; };
category cname { null; };

category default{
simple_log;
};
category queries { queries; };
};


// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};
zone "yourzone.com" in {
        type master;
        file "yourzone.com";
};
So you define all the address groups that should have recursive queries answered by your machine (your whole house, your whole town, whatever works for you), and put them in the acl. The allow-query any line allows any machine in the world to ask about yourzone.com, which obviously should be changed to the correct name of your domain. The file will get defined in /var/cache/bind/yourzone.com. This config also allows a log of queries and bind.log files, so you can see what queries your server is answering, and if you screw up a zonefile, check the bind.log file. You'll have to create the /var/log/named directory, and make sure the user bind has permissions to write in this directory.

I would simply install the bind.i386 package, and dump my named.conf into their named.conf, making changes if you need to.

Peace,
JimBass
 
Old 10-23-2007, 02:51 AM   #18
sneakyimp
Member
 
Registered: Dec 2004
Posts: 795

Original Poster
Rep: Reputation: 50
I would like my DNS server to cache results because I have SpamAssassin running locally to screen mail and it makes a BOATLOAD of queries to external servers which can be really slow. A caching nameserver is supposed to improve performance pretty dramatically.

I *really* appreciate that .conf file you sent. I've copied it and changed it a bit for my machine. And it seems to work...HOWEVER it seems to immediately come under attack or something...either that or I have something configured wrong. Here's the output log when i do 'service named start' :
Code:
23-Oct-2007 03:39:00.143 general: info: zone 0.in-addr.arpa/IN: loaded serial 42
23-Oct-2007 03:39:00.143 general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
23-Oct-2007 03:39:00.144 general: info: zone 255.in-addr.arpa/IN: loaded serial 42
23-Oct-2007 03:39:00.144 general: info: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700
23-Oct-2007 03:39:00.144 general: warning: /var/named/chroot/var/named/mydomain.com.zones:1: no TTL specified; using SOA MINTTL instead
23-Oct-2007 03:39:00.144 general: info: zone mydomain.com/IN: loaded serial 20071022
23-Oct-2007 03:39:00.144 general: info: zone localdomain/IN: loaded serial 20071022
23-Oct-2007 03:39:00.145 general: info: zone localhost/IN: loaded serial 20071022
23-Oct-2007 03:39:00.145 general: notice: running
23-Oct-2007 03:39:00.145 notify: info: zone mydomain.com/IN: sending notifies (serial 20071022)
23-Oct-2007 03:39:00.146 notify: info: client 11.11.11.11#32816: received notify for zone 'mydomain.com'
23-Oct-2007 03:39:00.732 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net IN AAAA +
23-Oct-2007 03:39:00.885 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net.com IN AAAA +
23-Oct-2007 03:39:01.022 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net IN A +
23-Oct-2007 03:39:02.231 queries: info: client 127.0.0.1#32816: query: 171.71.91.67.in-addr.arpa IN PTR +
23-Oct-2007 03:39:02.948 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net IN A +
23-Oct-2007 03:39:04.684 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net IN AAAA +
23-Oct-2007 03:39:04.684 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net.com IN AAAA +
23-Oct-2007 03:39:04.685 queries: info: client 127.0.0.1#32816: query: ip67-91-71-171.z71-91-67.customer.algx.net IN A +
23-Oct-2007 03:39:05.985 queries: info: client 127.0.0.1#32816: query: 171.71.91.67.in-addr.arpa IN PTR +
As you can see it complains about me having no TTL in the mydomain zone but otherwise loads fine. But then some machine (IP of 67.91.71.171) IMMEDIATELY attempts to send me a notify. What's up with THAT?? Is that a machine on the botnet or something?

I was hoping you might clear a few things up pretty please?

0) I set both logs to the same log (/var/log/named.log) because I'm concerned about my logs getting huge without being rotated. Do you have any advice about making sure these logs don't get out of control and are periodically rotated or deleted? Also, Is it a problem that I specify different version numbers and maximum sizes for the same log? Also, do you *really* want to log queries? Seems to me there are going to be MILLIONS of them.

1) What is the difference between allow-recursion and allow-query-cache? The docs are pretty vague on what it really means.

2) what the heck does that 'key rndc' section do? I understand that rndc is a control interface for BIND but am not clear if I would call this from the localhost, a remote host, etc. I'm also confused about where the rndc config might live and whether it needs to be updated to match this .conf file.
UPDATEI was having trouble stopping named until I made certain that the key value matched the contents of rndc.key.

3) controls...is that related to rndc key? What is it? The docs say something about this only being needed for backward compatibility to BIND 8.

4) Can you suggest any tests I should run before trying to use this as an authoritative DNS server? I installed dig by running this:
Code:
yum install bind-utils
Anyways...thanks for your help so far! I really don't enjoy this at all and I'm really concerned about setting up something that's going to hurt my server's performance or expose me to a hack or something.
 
Old 10-23-2007, 01:35 PM   #19
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
Your alleged "attack" is not an attack of any sort. It isn't sending any info towards you, you are asking about it. Maybe somebody at that address is trying to send you a message. I bet it is more likely that is your own address, or somebody that is spamming you. Also, any DNS server will cache info for as long as it is valid for, which is determined by the authoritative DNS.

Correct your TTL error, put one in the header of the zonefile. Check google for the 100,000 examples of zonefiles, and see that all of them have a TTL. There is nothing in what you posted about that address trying to send you a notify. All the notify statements I see is your machine complaining about your malformed zone, or you sending out notifies.

0) So you're concerned about logs getting to big, but did you bother at all to read and think about what I wrote for more than 2 seconds? What do you think this means:
Code:
file "/var/log/named/bind.log" versions 3 size 5m;
Do you think there is an outside chance that it will keep 3 bind.log files, each one a max of 5Mb in size? Or that just maybe the queries log keeps 5 copies, each a max of 10 Mb? There will not be millions of queries. Even in an office with 50 people you'll take days to fill a 10 Mb query log.

1) The docs are explicit about what those mean, which suggests to me you either didn't read them, or didn't bother to understand them. First off, your garbage OS doesn't even have a new enough version of BIND to allow you to use allow-query-cache. That came into play in 9.4.0. Allow-query-cache allows anyone to ask your server for the info it already has in its cache, which all versions of BIND used to allow, regardless of who was asking. Now the ability to query the cache can be manipulated. Recursion is the ability to ask your DNS about zones it is not authoritative for.

2) rndc is a great tool, it should be a must have for BIND. Once you graduate to larger machines, you don't want to bring down BIND to restart 1000 zones because you made one change to one of them. Rndc allows BIND to keep running, while reloading just that individual zone. All versions use rndc to start or stop a BIND process, so the key must match the file, or you can't start or stop your BIND without a manual kill. Rndc can be called from localhost, or a remote host, depending on how you have set it up. Keeping it restricted to localhost is a good idea, but you don't have to do that.

3) There used to be an explicit control statement in named.conf, which has been done away with for years now. It still exists for backwards compatibility, but you won't need it, and shouldn't use it, as that functionality could be removed at any time.

4) Dig is all you need. The command is
Code:
dig yourdomain.com @localhost
Then before you make it live, use dig from some other machine, to make sure you have done it right. And ask for everything, mail records, and any subdomains, to make sure everything is set.

Do some research next time. If you need this amount of hand holding to even get started, you will have issues once you go live.

Peace,
JimBass

3)

Last edited by JimBass; 10-23-2007 at 01:37 PM.
 
Old 10-23-2007, 03:07 PM   #20
sneakyimp
Member
 
Registered: Dec 2004
Posts: 795

Original Poster
Rep: Reputation: 50
Someone steal your guitar Jim? You sound cranky in your post.

This line looks to me like i have *received* a notify for my own domain. I don't see any reason why I would receive a notify for my own domain from an IP in virginia that I don't recognize. Assume 11.11.11.11 is my server's IP:
Code:
23-Oct-2007 03:39:00.146 notify: info: client 11.11.11.11#32816: received notify for zone 'mydomain.com'
If I turn query log to level=debug then I get lots of this:
Code:
23-Oct-2007 03:55:48.366 resolver: debug 1: createfetch: c3.nstld.com A
23-Oct-2007 03:55:48.366 resolver: debug 1: createfetch: c3.nstld.com AAAA
23-Oct-2007 03:55:48.366 resolver: debug 1: createfetch: d3.nstld.com A
23-Oct-2007 03:55:48.366 resolver: debug 1: createfetch: d3.nstld.com AAAA
23-Oct-2007 03:55:48.366 resolver: debug 1: createfetch: m3.nstld.com A
23-Oct-2007 03:55:48.366 resolver: debug 1: createfetch: m3.nstld.com AAAA
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0x80137b48 c3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0x80137b48 d3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0x80137b48 m3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0x8013ddd8 c3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0xb5a03df0 c3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0x8013ddd8 d3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0x8012b100 m3.nstld.com
23-Oct-2007 03:55:48.367 database: debug 1: no_references: delete from rbt: 0xb5a03df0 m3.nstld.com
I googled isc.org for 'createfetch' and no records were returned. Ditto for 'delete from rbt'. I googled internet-wide for these strings and just got weird log report type stuff.

As for the missing TTL in my zone file, I copied my zone file from this tutorial and it's also missing there. I just noticed the description in the docs today. I hope you'll forgive me, it's only a 650KB FILE. Hopefully I won't have to read those 100,000 valid zone files on google to answer the rest of my questions.

I appreciate your responses (except for the barbs)

0. I read your file thoroughly and also read the isc docs on this directive. If *you* had read my post more closely you'd see that I used the same log file twice with different directives and I was wondering if that would break anything? I left your original log sizes and was wondering if that would cause a problem? I ask because the original install had both a LogWatch and a logrotate script which pointed to /var/log/named.log and ALSO I have chosen to install a chrooted bind which looks elsewhere for the file. It's a bit of a mess and I worry they won't work together. Please don't get pissed, I'm just trying to understand this.

1. Maybe I'm an idiot but I don't really understand what this means:
allow-query-cache - Specifies which hosts are allowed to get answers from the cache. If allow-query-cache is not set then allow-recursion is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost is used.
allow-recursion - Specifies which hosts are allowed to make recursive queries through this server. If allow-recursion is not set then allow-query-cache is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost is used.
The if/then conditionals are a bit of a mind bender for someone new to this. Thanks for the clarification. That's disappointing about the directive not being available in Bind 9.3. There are no links to Bind 9.3 documentation on the ISC site. I don't see any need to bash my 'garbage' OS. It's CentOS 5 (based on RHEL 5), released only 6 mos ago, and the best my hosting provider has to offer. I'm not personally attached to it. Also, you're using Debian - the current stable package for Etch is Bind 9.3.4 so there! :P For what it's worth, the ISC site offers links to more recent RPM's but I'm not sure how to take advantage of them just yet (or whether it's worth it).

Quote:
Originally Posted by JimBass
Do some research next time. If you need this amount of hand holding to even get started, you will have issues once you go live.
Do some research? Are you serious? I've been reading about BIND for two days now and the 650KB of documentation is written like a math proof. I'm fully aware you know more about it than I do. That's why I'm here looking for help.

I'm still wondering if my install of BIND is caching any of the DNS requests it gets from SpamAssassin. Is there some kind of test I can do to find out?
 
Old 10-23-2007, 07:18 PM   #21
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
Your server will cache everything it receives an answer about, for as long as the authoritative server says to. For example, look at google.com. Google keeps their available servers on a super short leash. The answer they give is only good for 5 minutes (300 seconds). If nobody has asked your DNS server the address of google.com in 300 seconds, it gets a fresh answer. See here ->
Code:
jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57970
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       64.233.187.99
google.com.             300     IN      A       64.233.167.99
google.com.             300     IN      A       72.14.207.99

;; AUTHORITY SECTION:
google.com.             258601  IN      NS      ns3.google.com.
google.com.             258601  IN      NS      ns4.google.com.
google.com.             258601  IN      NS      ns1.google.com.
google.com.             258601  IN      NS      ns2.google.com.

;; Query time: 34 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:24 2007
;; MSG SIZE  rcvd: 148
Google in essence has told my server, here's your answer, now shut up for 300 seconds. My server won't ask anyplace again for the 300 seconds. You can see my server will keep answering from its cache until that 300 seconds goes down to 0, then it will ask again ->

Code:
jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23837
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             297     IN      A       72.14.207.99
google.com.             297     IN      A       64.233.187.99
google.com.             297     IN      A       64.233.167.99

;; AUTHORITY SECTION:
google.com.             258598  IN      NS      ns4.google.com.
google.com.             258598  IN      NS      ns3.google.com.
google.com.             258598  IN      NS      ns2.google.com.
google.com.             258598  IN      NS      ns1.google.com.

;; Query time: 4 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:27 2007
;; MSG SIZE  rcvd: 148

jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55270
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             296     IN      A       64.233.167.99
google.com.             296     IN      A       72.14.207.99
google.com.             296     IN      A       64.233.187.99

;; AUTHORITY SECTION:
google.com.             258597  IN      NS      ns3.google.com.
google.com.             258597  IN      NS      ns1.google.com.
google.com.             258597  IN      NS      ns2.google.com.
google.com.             258597  IN      NS      ns4.google.com.

;; Query time: 5 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:28 2007
;; MSG SIZE  rcvd: 148

jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46556
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             295     IN      A       64.233.187.99
google.com.             295     IN      A       64.233.167.99
google.com.             295     IN      A       72.14.207.99

;; AUTHORITY SECTION:
google.com.             258596  IN      NS      ns4.google.com.
google.com.             258596  IN      NS      ns3.google.com.
google.com.             258596  IN      NS      ns1.google.com.
google.com.             258596  IN      NS      ns2.google.com.

;; Query time: 4 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:29 2007
;; MSG SIZE  rcvd: 148

jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48902
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             294     IN      A       72.14.207.99
google.com.             294     IN      A       64.233.187.99
google.com.             294     IN      A       64.233.167.99

;; AUTHORITY SECTION:
google.com.             258595  IN      NS      ns3.google.com.
google.com.             258595  IN      NS      ns4.google.com.
google.com.             258595  IN      NS      ns1.google.com.
google.com.             258595  IN      NS      ns2.google.com.

;; Query time: 25 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:30 2007
;; MSG SIZE  rcvd: 148

jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29699
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             292     IN      A       64.233.167.99
google.com.             292     IN      A       72.14.207.99
google.com.             292     IN      A       64.233.187.99

;; AUTHORITY SECTION:
google.com.             258593  IN      NS      ns2.google.com.
google.com.             258593  IN      NS      ns3.google.com.
google.com.             258593  IN      NS      ns4.google.com.
google.com.             258593  IN      NS      ns1.google.com.

;; Query time: 25 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:31 2007
;; MSG SIZE  rcvd: 148

jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8181
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             291     IN      A       64.233.187.99
google.com.             291     IN      A       64.233.167.99
google.com.             291     IN      A       72.14.207.99

;; AUTHORITY SECTION:
google.com.             258592  IN      NS      ns2.google.com.
google.com.             258592  IN      NS      ns4.google.com.
google.com.             258592  IN      NS      ns1.google.com.
google.com.             258592  IN      NS      ns3.google.com.

;; Query time: 26 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:32 2007
;; MSG SIZE  rcvd: 148

jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57793
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             290     IN      A       72.14.207.99
google.com.             290     IN      A       64.233.187.99
google.com.             290     IN      A       64.233.167.99

;; AUTHORITY SECTION:
google.com.             258591  IN      NS      ns2.google.com.
google.com.             258591  IN      NS      ns3.google.com.
google.com.             258591  IN      NS      ns1.google.com.
google.com.             258591  IN      NS      ns4.google.com.

;; Query time: 4 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 18:56:33 2007
;; MSG SIZE  rcvd: 148
Some time later, after the original 300 seconds has expired, the next query will again go to google's nameservers (which understandably have a MUCH larger timeout) ->
Code:
jim@jimsworktop:~$ dig google.com

; <<>> DiG 9.4.1-P1 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9127
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       72.14.207.99
google.com.             300     IN      A       64.233.187.99
google.com.             300     IN      A       64.233.167.99

;; AUTHORITY SECTION:
google.com.             258015  IN      NS      ns1.google.com.
google.com.             258015  IN      NS      ns4.google.com.
google.com.             258015  IN      NS      ns2.google.com.
google.com.             258015  IN      NS      ns3.google.com.

;; Query time: 100 msec
;; SERVER: 192.168.68.103#53(192.168.68.103)
;; WHEN: Tue Oct 23 19:06:10 2007
;; MSG SIZE  rcvd: 148
By the way, did you see what version of BIND my Debian laptop used to ask about google? Looks like 9.4.1-P1. How about my home server?
Code:
jim@JimsBeastie:~$ /usr/local/sbin/named -v
BIND 9.4.1-P1
Seems to be the latest and greatest. The only way to get great software doing what you want is to roll your own. Get your tarball, extract it to /usr/local, then ./configure, make, and make install. If you want to wait and hope what your package manager has chosen to do with a package works for you, that's fine. I'd be lying out my teeth if I said I compiled all my own software, but I can be certain that I compile anything that I actually use often. If you're close enough to a project to be on its mailing list, then you'll want the new and improved version the minute it comes out, and a package manager doesn't give you that. Etch might be 9.3.4, but all my Etch machines happily run 9.4.1.

You're either receiving a notify because you have configured yourself to be 2 machines (both a master and slave on one, are using 2 IP addresses, or the most likely, you are hearing from what is the authoritative server for your domain, although for you to hear it is odd. I am not willing to troubleshoot that, as you are obscuring your domain name and the servers involved. That is a common mistake among newbies. When you're looking for help with DNS, you can't hide those things. DNS is not an attack vector. The worst that can be done with DNS is that they ask you your IP address.

This is a proper header for a zone file ->
Code:
example.com           IN SOA  ns1.example.com. root.example.com. (
                                2007102200 ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                1209600    ; expire (2 weeks)
                                3600       ; minimum (1 hour)
                                )
$TTL 7200       ; 2 hours
0) The total size of my logs will never exceed 65 Mb. If you don't have 65 Mb of space, you don't have enough room to do anything. Use my config, or modify it to suit your needs, but keep the BIND log separate from the queries. Queries are only useful to see what is being asked, or should law enforcement come calling. The bind.log is the important one, and it should be kept separate. I see no reason to run a chroot, but if you want to thats fine. Just modify the log location to be within the chroot.

1) All RHEL is garbage. Sorry, but its true. Becoming dependent on the "right" rpm just prevents you from being able to make your own RPM. If you run a public server, I strongly suggest Slackware, Debian, or any of the open/free BSD family.

You can dump your cache to a log file, but it is easiest to do with the command ->
Code:
rndc dumpdb -cache
You need to define a dump location in named.conf.

You don't need to do that though. You'd have to tweak the hell out of BIND to make it not cache its answers. Add a line like this to named.conf - dump-file "/var/log/named/dump.db";

Your help session is over. You've got all the pieces done, just assemble to toy and play with it!

Peace,
JimBass
 
Old 10-23-2007, 07:47 PM   #22
sneakyimp
Member
 
Registered: Dec 2004
Posts: 795

Original Poster
Rep: Reputation: 50
Cheers Jim! Thanks for all your help. Feeling much better about this now and there's no way I could have done it as quickly without your tips. Hope I haven't discouraged you from helping us noobs.
 
  


Reply

Tags
bind, dns, migration


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I need to migrate to a new domain w/ BIND (DNS) rsmccain Linux - Networking 1 11-17-2006 02:14 AM
TEMP_FAILURE: DNS Error: Timeout while contacting DNS servers when receiving emails tonysutherland Linux - Networking 2 02-10-2006 09:04 AM
Migrate from exchange/dns to bind xiaodown Linux - Networking 0 07-15-2004 12:30 PM
lame dns servers etc and general dns issues suse_linux9.1 Linux - Networking 3 06-01-2004 01:50 PM
Migrate my hosted DNS to my RH9 box wazab Linux - Newbie 2 05-09-2004 05:40 AM


All times are GMT -5. The time now is 05:28 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration