Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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.
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:
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.
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:
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?
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?
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.
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!
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
is used.
