William Warren wrote:

yes i need a caching name server that if the address it is looking for is not in cache will goto my Astaro firewall(which has the dns server to query). Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed

eli@streetlampsoftware.com wrote:

...

William Warren wrote:

...

I am having some issue with setting up a caching nameserver. here's the link: http://www.centos.org/modules/newbb/viewtopic.php?topic_id=150&forum=10&...

the OS is now CentOS4

If you only need caching, then try using something simpler, and more secure, than bind. Try dnsmasq (it can run a dhcp-server too, but that is easily disabled) or dns-cache (a djb software utility).

I prefer dnsmasq myself. Simple, but effective. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

-- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician)

Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Doesn't Astaro have some form of dns caching already?

-Marco Garza

Hello Members,

When I installed Ubuntu Linux on a machine with XP on it, I ran across this warning from a google search:

"Install GRUB on the first sector of the /boot partition. DO NOT INSTALL IT ON THE MBR!."

Is this true for CentOS 4.1 as well? If so, what is the procedure for building a dual boot CentOS/XP system?

Note: XP is already installed on the SATA drive.

TIA, David

BTW My Astaro machine already handles DHCP..just need caching name server services.

eli@streetlampsoftware.com wrote:

William Warren wrote:

...

I am having some issue with setting up a caching nameserver. here's the link: http://www.centos.org/modules/newbb/viewtopic.php?topic_id=150&forum=10&...

the OS is now CentOS4

If you only need caching, then try using something simpler, and more secure, than bind. Try dnsmasq (it can run a dhcp-server too, but that is easily disabled) or dns-cache (a djb software utility).

I prefer dnsmasq myself. Simple, but effective. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

i'd rather use bind..i don't have to go outside the Centos tree that way and can easily maintain it with yum update. Thanks for the suggestion though.

Feizhou wrote:

...

If you only need caching, then try using something simpler, and more secure, than bind. Try dnsmasq (it can run a dhcp-server too, but that is easily disabled) or dns-cache (a djb software utility).

dnscache - simple and secure

However you need some supporting software, namely, daemontools

see http://cr.yp.to/daemontools.html for more information.

wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz tar zxf daemontools-0.76.tar.gz cd admin/daemontools-0.76 echo 'gcc -Os -include /usr/include/errno.h -Wimplicit -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings' > src/conf-cc ./package/install cd ../..

(The above will get you a running daemontools installation right away)

djbdns -- see http://cr.yp.to/djbdns.html

wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz tar zxf djbdns-1.0.5.tar.gz cd djbdns-1.05.tar.gz echo 'gcc -Os -include /usr/include/errno.h -Wimplicit -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings' > conf-cc make setup check dnscache-conf nobody nobody /var/dnscache 192.168.0.[?] touch /var/dnscache/root/ip/192.168.0

(This will get you an installation that listens only on 192.168.0.[?] and that is installed under /var/dnscache. The dnscache program will run under nobody and log files will be generated under nobody uid/gid in /var/dnscache/log/main/current.

By default, it will only use 1MB of RAM for caching. To increase, edit /var/dnscache/env/DATALIMIT and /var/dnscache/env/CACHESIZE. DATALIMIT must be slighty larger than CACHESIZE. At least two megabytes larger seems to be a good value. -- see http://cr.yp.to/djbdns/cachesize.html.

Regarding last step, only queries from 192.168.0.x will be entertained. This is a non-forwarding setup)

To activate: cd /service; ln -s /var/dnscache

If you change anything under /var/dnscache/env or /var/dnscache/root/servers, you need to restart to take effect.

To restart: svc -t /service/dnscache To stop: svc -d /service/dnscache To start: svc -u /service/dnscache (note: daemontools will automatically start on boot and it will also automatically start dnscache) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

William Warren wrote:

i'd rather use bind..i don't have to go outside the Centos tree that way and can easily maintain it with yum update. Thanks for the suggestion though.

1- Try not to top-post.

All you need to get a local name caching on a server is to do a

yum install caching-nameserver

Then,

chkconfig --add named

Finally,

service named start

Then make sure named listens on all IP addresses (if you don't need only local access) and tell clients to use this server for dns queries.

Then if you absolutely need to use your astaro, you'll have to modify your config file as stated by another poster.

Hope this helps.

BTW this is all from my memory... you may have to know what you are doing ;).

Peter Farrow wrote:

Have you tried nscd?

William Warren wrote:

no i have not..:) I am realy interested in learning Bind right now since that is what is able to be accessed through webmin(which i am NOT using for this excersize).

I think what Peter was directing you towards is the Name Services Cache Daemon (nscd). It is a _transparent_ "start'n forget" client service that caches names (e.g., DNS), NIS maps (e.g., hosts, passwd, group, etc...) and other network information. You don't need to configure it.

It's much easier and more secure to deal with the simple need of clients to catch name and other network mapped services (like NIS).

On Mon, 2005-08-08 at 19:32 -0400, William Warren wrote:

By client do you mean it runs on my server or on my windows machine?

Oh, in that case, it typically only works on and for a local client, i.e., a UNIX/Linux client. I don't know of a port of nscd or an equivalent under Windows, although newer NT5.x (2000/XP) versions of Windows have _some_ naming caching.

Now understand that Windows has some _stupid_ (from a UNIX viewpoint) name resolution logic. This is largely to deal with is own _stupid_ (from a UNIX viewpoint) legacy services that were "me too" type "active." E.g., if Windows fails a resolution of a system name, it will cache that failure. I.e., Windows will not attempt to resolve again for X number of minutes (or, gulp, even X number of hours! ;-).

Just disabling that in Windows (do a quick Google for the key) solves 95% of name service performance issues.

Otherwise, yes, I have setup BIND on my UNIX/Linux servers as a forwarder/caching server. I recommend that on a LAN for security reasons -- i.e., Windows clients _never_ use Internet DNS servers directly, and all name resolution attempts are made to local DNS servers first (who cache on behalf of Windows systems). And when resolution/ performance issues are noticeable, I recommend you install BIND (or another DNS solution) on Windows clients itself.

Especially older NT4.0 and DOS/Win (95/98/Me) versions.

On Tue, 2005-08-09 at 11:45, William Warren wrote:

All my machines except one are windows 2000 professional machines. The other is winme(for my daughter's older games). I think i managed to screw up my BIND configs though. erasing and reinstalling Bind is not fixing it. What files does everyone want posted so this issue can get fixed?

I could easily just reload the system..but that's the winders way of doing things..:)

I'd try rpm -e bind (assuming that /etc/resolv.conf points at your other namesever for now) Make sure that /etc/named.conf and /var/named/chroot/etc/named.conf are gone, then yum install bind

Then make sure that /etc/named.conf installs as a symlink pointing to /var/named/chroot/etc/named.conf and edit in the forward statements pointing to your gateway dns server. Then service named start and look in /var/log/messages for any errors.

Note that local DNS resolution is controlled by /etc/resolv.conf regardless of whether you have named running or not, so test with dig @localhost then pointing some other boxes at it. When you are sure it is working you can change resolv.conf to use the local server.

On Tue, 2005-08-09 at 14:34, William Warren wrote:

Ok etc/named.conf is NOT a symlink and /var/named does NOT have the chroot folders. It has /var/named/data and /var/named/slaves both of which are blank.

I'm at a disadvantage here because I installed my box from the k12ltsp rebuilt Centos 4 isos, but I don't think that part changed. Are you on a Centos4 installed from scratch or was the box upgraded from something else?

Named should work the same, chroot or not, though. What errors are you seeing in /var/log/messages after starting it?

On Tue, 2005-08-09 at 17:22, William Warren wrote:

So i did this:

...

nslookup hotmail.com

(on my winders box) and i got this: *** Can't find server name for address 192.168.0.200: Non-existent domain

I think this is only fatal with nslookup, but DNS servers should be able to reverse-resolve their own IP address to a name and apparently your forwarding server doesn't know your private addresses either. What does 'dig @localhost' say on the box itself?

The right fix is to configure either this or the upstream server as primary for the 192.168.0 zone. Otherwise you'll toss thousands of these queries up to the root servers.

zone "0.168.192.in-addr.arpa" IN { type master; file "192.168.0.arpa"; allow-update { none; }; }; If you don't know the format for the zone file mentioned, you might want to use webmin to build it.

The box's name is Enoch.emmanuelcomputerconsulting.com ip is 192.168.0.200 set statically.

Does your upstream server resolve that domain or your private addresses?

I have actually tried it with caching name server installed with the same error..will try it again..:)

Johnny Hughes wrote:

On Wed, 2005-08-10 at 00:27 -0500, Les Mikesell wrote:

...

On Tue, 2005-08-09 at 17:22, William Warren wrote:

...

So i did this:

...

nslookup hotmail.com

(on my winders box) and i got this: *** Can't find server name for address 192.168.0.200: Non-existent domain

I think this is only fatal with nslookup, but DNS servers should be able to reverse-resolve their own IP address to a name and apparently your forwarding server doesn't know your private addresses either. What does 'dig @localhost' say on the box itself?

The right fix is to configure either this or the upstream server as primary for the 192.168.0 zone. Otherwise you'll toss thousands of these queries up to the root servers.

zone "0.168.192.in-addr.arpa" IN { type master; file "192.168.0.arpa"; allow-update { none; }; }; If you don't know the format for the zone file mentioned, you might want to use webmin to build it.

...

The box's name is Enoch.emmanuelcomputerconsulting.com ip is 192.168.0.200 set statically.

Does your upstream server resolve that domain or your private addresses?

BTW, there is a package called caching-nameserver ...

yum install caching-namesever

will give you a good working caching nameserver

---

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

grrr..nslookup says(copy and paste went wrong due to fat fingers..:)>

*** Can't find server name for address 192.168.0.200: No response from server Server: jericho.emmanuelcomputerconsulting.com Address: 192.168.0.1

Non-authoritative answer: Name: hescominsoon.com Address: 82.165.193.174

William Warren wrote:

dig to localhost says: [root@enoch ~]# dig localhost

; <<>> DiG 9.2.4 <<>> localhost ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2833 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION: ;localhost. IN A

;; ANSWER SECTION: localhost. 86400 IN A 127.0.0.1

;; AUTHORITY SECTION: localhost. 86400 IN NS localhost.

;; ADDITIONAL SECTION: localhost. 86400 IN A 127.0.0.1

;; Query time: 6 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Wed Aug 10 08:24:15 2005 ;; MSG SIZE rcvd: 73

nslookup still says:

[root@enoch ~]# dig localhost

; <<>> DiG 9.2.4 <<>> localhost ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2833 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION: ;localhost. IN A

;; ANSWER SECTION: localhost. 86400 IN A 127.0.0.1

;; AUTHORITY SECTION: localhost. 86400 IN NS localhost.

;; ADDITIONAL SECTION: localhost. 86400 IN A 127.0.0.1

;; Query time: 6 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Wed Aug 10 08:24:15 2005 ;; MSG SIZE rcvd: 73

It's starting to look like maybe a OS reinstall?

Johnny Hughes wrote:

...

On Wed, 2005-08-10 at 00:27 -0500, Les Mikesell wrote:

...

On Tue, 2005-08-09 at 17:22, William Warren wrote:

...

So i did this:

...

nslookup hotmail.com

(on my winders box) and i got this: *** Can't find server name for address 192.168.0.200: Non-existent domain

I think this is only fatal with nslookup, but DNS servers should be able to reverse-resolve their own IP address to a name and apparently your forwarding server doesn't know your private addresses either. What does 'dig @localhost' say on the box itself?

The right fix is to configure either this or the upstream server as primary for the 192.168.0 zone. Otherwise you'll toss thousands of these queries up to the root servers.

zone "0.168.192.in-addr.arpa" IN { type master; file "192.168.0.arpa"; allow-update { none; }; }; If you don't know the format for the zone file mentioned, you might want to use webmin to build it.

...

The box's name is Enoch.emmanuelcomputerconsulting.com ip is 192.168.0.200 set statically.

Does your upstream server resolve that domain or your private addresses?

BTW, there is a package called caching-nameserver ... yum install caching-namesever

will give you a good working caching nameserver

---

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

[root@enoch ~]# dig @localhost

; <<>> DiG 9.2.4 <<>> @localhost ;; global options: printcmd ;; connection timed out; no servers could be reached

Les Mikesell wrote:

On Wed, 2005-08-10 at 07:25, William Warren wrote:

...

dig to localhost says: [root@enoch ~]# dig localhost

dig localhost tells the system to ask the server(s) mentioned in /etc/resolve.conf to resolve the name localhost.

What you want is: dig @localhost which queries the nameserver on the local machine to show you some info from the root servers as a useful diagnostic to make sure it can reach them. If you are firewalled in a way that udp on port 53 can't get back from the internet and you aren't configured to use a forwarder that can get answers, you won't see the root servers displayed. You can also query for specific addresses: dig @localhost www.sun.com

On Wed, 2005-08-10 at 10:37, William Warren wrote:

[root@enoch ~]# dig @localhost

; <<>> DiG 9.2.4 <<>> @localhost ;; global options: printcmd ;; connection timed out; no servers could be reached

OK, this can either mean that named isn't running or isn't listening on the 127.0.0.1 interface (/var/log/messages should tell you if it started up and bound to that interface), or it could mean that you aren't able to contact the root servers.

If the server is running, then you either need to make sure that udp and tcp, port 53 can get to the internet and back with appropriate NATting, or you have to add forwarding info to named.conf to pass the queries through an upstream server that does have full internet access.

Running 'tcpdump port 53' in another window can help you see where your query is going and whether you are getting answers.

Robert Hanson roberth@abbacomm.net wrote:

what does your resolv.conf file look like? what does your named.conf file look like?

From what I saw in this thread, the original poster is (was?)

interested in caching for local Windows systems. That's why "nscd" came up but was quickly dismissed.

maybe the thread name should be changed if you are using bind or bind caching nameserver

That's why I append the subject to nscd, but now I've responded and changed it again here. We started to go off on "nscd," but then we came back to the BIND or another DNS caching/fowarding server**.

-- Bryan

**[OT]NOTE: My primary reason for doing this is that it makes it easier to find discussions in the archives, while still reserving the "sort by subject" in the mail readers too. It's the same logic that was used prior for UseNet per the (now lost?) O'Reilly discussion guidelines. It not only helps raise my ratings in Google searches, as well as popularity in people who click on them, but I get thanks from people who see my subject appendings mid-thread out of dozens or even hundreds of items (saving them a lot of effort).

Thread ID in SMTP/NNTP always maintains threading proper (which is why I switched to Yahoo for webmail recently, away from not only my old provider who didn't, but GMail which has stated it will never).

named.conf: // // named.conf for Red Hat caching-nameserver //

options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; };

// // a caching only nameserver config // controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; };

zone "." IN { type hint; file "named.ca"; };

zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; }; };

zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; };

zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; };

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 { type master; file "named.ip6.local"; allow-update { none; }; };

zone "255.in-addr.arpa" IN { type master; file "named.broadcast"; allow-update { none; }; };

zone "0.in-addr.arpa" IN { type master; file "named.zero"; allow-update { none; }; };

include "/etc/rndc.key";

resolv.conf:

nameserver 192.168.0.1

Robert Hanson wrote:

what does your resolv.conf file look like?

what does your named.conf file look like?

maybe the thread name should be changed if you are using bind or bind caching nameserver

thanks and kind regards,

-- Robert Hanson Abba Communications http://www.abbacomm.net

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

For the list as well: I have webmin installed if that will help anyone on this..but it seems CLI is the best way to go..:)

William Warren wrote:

Let me restate what i am trying to do and the original error:

I have a centos-4 machine that acts as a samba file server and my ntp time server. I now want to have it be a dns caching name server for my network since my firewall's caching is not long enough for me. When i start it up i get no errors. However, when i try to use it from one of my internal hosts i get the following error: *** Can't find server name for address 192.168.0.200: No response from server Server: jericho.emmanuelcomputerconsulting.com Address: 192.168.0.1

Non-authoritative answer: Name: cgalliance.org Address: 64.202.166.214

192.168.0.200 is named Enoch.emmanuelcomputerconsulting.com and it's ip address is static. 192.168.0.1 is the Astaro firewall which i want Enoch to goto if the cached request is expired or not present. I am sure i deleted something i was not supposed to in following various net guides. I could reinstall the system but that is the windows way of doing things. BIND is what i wish to use. I have the base bind package and caching-name server installed. I ma sure some conf files are either missing or broken. For some odd reason BIND is NOT chrooted like some folks have said it should be and this could be the root cause.

William Warren wrote:

...

named.conf: // // named.conf for Red Hat caching-nameserver //

options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; };

// // a caching only nameserver config // controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; };

zone "." IN { type hint; file "named.ca"; };

zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; }; };

zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; };

zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; };

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 { type master; file "named.ip6.local"; allow-update { none; }; };

zone "255.in-addr.arpa" IN { type master; file "named.broadcast"; allow-update { none; }; };

zone "0.in-addr.arpa" IN { type master; file "named.zero"; allow-update { none; }; };

include "/etc/rndc.key";

resolv.conf:

nameserver 192.168.0.1

Robert Hanson wrote:

...

what does your resolv.conf file look like?

what does your named.conf file look like?

maybe the thread name should be changed if you are using bind or bind caching nameserver

thanks and kind regards,

-- Robert Hanson Abba Communications http://www.abbacomm.net

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

Bryan J. Smith wrote:

Windows NT5+ (2000+) client systems have a _flawed_, _default_ logic to "hold down" DNS resolution upon failure. That means if a DNS resolution fails, Windows clients will _not_ requery the server _until_ that timeout passes. There is a registry hack to change this as follows: [ From http://www.winguides.com/registry/display.php/1203/ ]

'To change the DNS cache timeout for negative responses (where a lookup failed). Windows 2000 - Create or modify the DWORD value called "NegativeCacheTime". Windows XP and .NET Server 2003 - Create or modify the DWORD value called "MaxNegativeCacheTtl". Set the value to equal the required timeout in seconds the default is 300 (5 minutes). Restart Windows for the changes to take effect.'

It's my #1 recommendation until you resolve the problem. UNIX clients/resolvers _never_ (AFAIK) cache a "failure," only Windows -- which I think is flawed, but there is a reason for it (that has to do with legacy SMB file/print).

Regardless of what solution you come to on the server, consider doing the above.

Just to add to your knowledge base:

On Windows system, you can manually flush its dns cache, failed and otherwise, by opening a Command Window and typing:

ipconfig /flushdns

On Wed, 2005-08-10 at 11:50, Bryan J. Smith wrote:

Are you sure it's the server?

Most firewalls these days are BSD (including variants like VxWorks) and Linux network stacks and use BIND or another POSIX DNS service.

As I mentioned in a previous post: http://lists.centos.org/pipermail/centos/2005-August/009553.html

Windows NT5+ (2000+) client systems have a _flawed_, _default_ logic to "hold down" DNS resolution upon failure. That means if a DNS resolution fails, Windows clients will _not_ requery the server _until_ that timeout passes. There is a registry hack to change this as follows: [ From http://www.winguides.com/registry/display.php/1203/ ]

'To change the DNS cache timeout for negative responses (where a lookup failed). Windows 2000 - Create or modify the DWORD value called "NegativeCacheTime". Windows XP and .NET Server 2003 - Create or modify the DWORD value called "MaxNegativeCacheTtl". Set the value to equal the required timeout in seconds the default is 300 (5 minutes). Restart Windows for the changes to take effect.'

It's my #1 recommendation until you resolve the problem. UNIX clients/resolvers _never_ (AFAIK) cache a "failure," only Windows -- which I think is flawed, but there is a reason for it (that has to do with legacy SMB file/print).

Regardless of what solution you come to on the server, consider doing the above.

On Wed, 2005-08-10 at 12:21 -0400, William Warren wrote:

named.conf:

OK ... when you start it (/etc/init.d/named restart) do you get any errors in /var/log/messages

If not ... do you have port 53 tcp and udp open in your IPTABLES

and is SELinux ON or OFF

} } } yes I have a blanket outgoing rule for all known hosts inside my } netowrk..:) }

what is that blanket rule(s)?

-- Robert Hanson Abba Communications http://www.abbacomm.net

NOds I have been doing that..:) I am not a windows newb..i am a linux newb though..:)

*that being said i do not consider myself a windows guru though*

Bryan J. Smith wrote:

Windows NT5+ (2000+) client systems have a _flawed_, _default_ logic to "hold down" DNS resolution upon failure. That

means if a DNS resolution fails, Windows clients will

_not_ requery the server _until_ that timeout passes. There is a registry hack to change this as follows: [ From

http://www.winguides.com/registry/display.php/1203/ ]

'To change the DNS cache timeout for negative responses (where a lookup failed). Windows 2000 - Create or modify the DWORD value called "NegativeCacheTime". Windows XP and .NET Server 2003 - Create or modify the DWORD value called "MaxNegativeCacheTtl". Set the value to equal the required timeout in seconds the default is 300 (5 minutes). Restart Windows for the changes to take effect.'

It's my #1 recommendation until you resolve the problem. UNIX clients/resolvers _never_ (AFAIK) cache a "failure," only Windows -- which I think is flawed, but there is a reason for it (that has to do with legacy SMB file/print).

Regardless of what solution you come to on the server, consider doing the above.

Just to add to your knowledge base:

On Windows system, you can manually flush its dns cache, failed and otherwise, by opening a Command Window and typing:

ipconfig /flushdns

The blanket rule effectivly says that any outgoing traffic of any kind from any of my known hosts(which includes enoch) is expressedly allowed.

Robert Hanson wrote:

} } } yes I have a blanket outgoing rule for all known hosts inside my } netowrk..:) }

what is that blanket rule(s)?

-- Robert Hanson Abba Communications http://www.abbacomm.net

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

} } Ok removing the alternate dns makes the caching name server work..:) I } guess we need to fix the reverse-resolve now? }

i dunno on chrooted right now.

you prob know this yet... i dunno if you are testing a global ip address or a private ip address.

to test reverse dns and check for an authoritative answer do this

dig -x ip.address.totest.here

and check it out.

if you are trying to be authoritative and get private space in-addr.arpa to resolve properly then i believe you will need to run regular bind distro and not caching.

- rh

-- Robert Hanson Abba Communications http://www.abbacomm.net

Replies inline:

On Wed, 2005-08-10 at 11:56, William Warren wrote:

...

well here is what it got this time: DNS request timed out. timeout was 2 seconds. *** Can't find server name for address 192.168.0.200: Timed out *** Default servers are not available Server: UnKnown Address: 192.168.0.200

Non-authoritative answer: Name: cgalliance.org Address: 64.202.166.214

This is still nslookup - the timeout/error should not happen in normal dns resolution.

...

How can i fix the revrese resolving issue?

Number to name resolution is exactly the same as name to number, except that the actual names involved are constructed by reversing the IP number octets and appending in-addr.arpa. If your server isn't configured to answer for your private address ranges itself, it will pass the query off to the root servers like everything else, and of course no one else is going to know anything about your private ranges.

If you look at the entry for zone 0.0.127.in-addr.arpa noting that the filename must be different for each zone and lives in the directory mentioned at the top (relative to the chroot location if your version does a chroot), you will see what you need to do. If you have webmin, it will offer to build the reverse zones for machines you put in forward lookup zones but you can do it by hand or find a script that does it if you prefer. To fix your nslookup issue you only have to make 192.168.0.200 work, so try adding that to understand the principle.

*super dns newb here. How would i go about making it work? i'll take a gander inside webmin and see if i can figure it out though*

Also, you mentioned earlier that you wanted to use another server as the forwarder. Does that one already have entries for your private IP's?

*No it does not. The firewall is basiclaly jsut a forwarding nameserver and AFAIK does little if no caching.*

I've always wondered why distributions don't come preconfigured with canned answers for all the RFC 1918 private address space to reduce the nonsense queries to the root servers.

-- Les Mikesell lesmikesell@gmail.com

again, I prefer to use Bind. Is djbdns in the Centos tree?

Feizhou wrote:

...

...

...

How can i fix the revrese resolving issue?

Number to name resolution is exactly the same as name to number, except that the actual names involved are constructed by reversing the IP number octets and appending in-addr.arpa. If your server isn't configured to answer for your private address ranges itself, it will pass the query off to the root servers like everything else, and of course no one else is going to know anything about your private ranges.

If you look at the entry for zone 0.0.127.in-addr.arpa noting that the filename must be different for each zone and lives in the directory mentioned at the top (relative to the chroot location if your version does a chroot), you will see what you need to do. If you have webmin, it will offer to build the reverse zones for machines you put in forward lookup zones but you can do it by hand or find a script that does it if you prefer. To fix your nslookup issue you only have to make 192.168.0.200 work, so try adding that to understand the principle.

*super dns newb here. How would i go about making it work? i'll take a gander inside webmin and see if i can figure it out though*

geez. all this trouble....install djbdns and you will forget about its existence. Things just work.

In bind, you need to define a 0.168.192.in-addr.arpa zone and create the stuff similar to the 0.0.127.in-addr.arpa

200 IN PTR your.name.

With djbdns, you can just install and run walldns and forward/split-horizon queries for 0.168.192.in-addra.arpa to the walldns instance if you don't need names. or you install tinydns if you want names. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

Ok i am closing this thread. time for a new one..:)

Feizhou wrote:

...

...

...

How can i fix the revrese resolving issue?

Number to name resolution is exactly the same as name to number, except that the actual names involved are constructed by reversing the IP number octets and appending in-addr.arpa. If your server isn't configured to answer for your private address ranges itself, it will pass the query off to the root servers like everything else, and of course no one else is going to know anything about your private ranges.

If you look at the entry for zone 0.0.127.in-addr.arpa noting that the filename must be different for each zone and lives in the directory mentioned at the top (relative to the chroot location if your version does a chroot), you will see what you need to do. If you have webmin, it will offer to build the reverse zones for machines you put in forward lookup zones but you can do it by hand or find a script that does it if you prefer. To fix your nslookup issue you only have to make 192.168.0.200 work, so try adding that to understand the principle.

*super dns newb here. How would i go about making it work? i'll take a gander inside webmin and see if i can figure it out though*

geez. all this trouble....install djbdns and you will forget about its existence. Things just work.

In bind, you need to define a 0.168.192.in-addr.arpa zone and create the stuff similar to the 0.0.127.in-addr.arpa

200 IN PTR your.name.

With djbdns, you can just install and run walldns and forward/split-horizon queries for 0.168.192.in-addra.arpa to the walldns instance if you don't need names. or you install tinydns if you want names. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos .

On Wed, 2005-08-10 at 13:05, Feizhou wrote:

With djbdns, you can just install and run walldns and forward/split-horizon queries for 0.168.192.in-addra.arpa to the walldns instance if you don't need names. or you install tinydns if you want names.

I have no idea what any of that means. It doesn't sound easier than using the stock packages which also 'just work' when you add the names and addresses that no other server knows. It does help to have a tool to build the reverse zones for you but webmin is probably the way to go if you don't want to do it by hand.

Les Mikesell wrote:

On Wed, 2005-08-10 at 13:05, Feizhou wrote:

...

With djbdns, you can just install and run walldns and forward/split-horizon queries for 0.168.192.in-addra.arpa to the walldns instance if you don't need names. or you install tinydns if you want names.

I have no idea what any of that means. It doesn't sound easier than using the stock packages which also 'just work' when you add the names and addresses that no other server knows. It does help to have a tool to build the reverse zones for you but webmin is probably the way to go if you don't want to do it by hand.

If you just look at walldns it will tell you that it automatically maps things like 192.168.0.1 <-> 1.0.168.192.in-addr.arpa

If you want real names, then you have to use tinydns where you can create the records.

For an authoritative server, it is probably better running bind since it keeps stuff in memory while tinydns hits a cdb (disk i/o). dnscache is the only choice if you need a high performance dns cache where bind does not meet what is required.

For config file format, tinydns beats bind hands down. Anyway, for small zones, bind is probably less effort since it comes with CentOS.

} no this is not authoritative. I actually have my ecc domain hosted } elsewhere..i simply clal my machines internally that to keep it simple } so there are behind a nat in RFC1918 space at the house here. }

please forgive yet i recommend

dig

for dns testing almost all of the time. although nslookup is ok i recall instances years ago where dig used properly returned right answers and helped find problem when nslookup was totally wrong. could have been the resolver libraries, i dont recall.

just a preference.

if you are trying to reverse lookup that x.x.x.200 ip address or whatever private space, like the others said, you have to run your own dns and i do not know if caching truly supports this authoritatively as well... see below.

chalk up the caching nameserver experience and go to chroot bind IMHO.

-- Robert Hanson Abba Communications http://www.abbacomm.net

I have been playing with it..reading various docs..following guides on the net. it WAS chrooted but then I did something and it's not..:) So i guess i have to reconstruct the chroot?

Les Mikesell wrote:

On Wed, 2005-08-10 at 12:39, Robert Hanson wrote:

...

chalk up the caching nameserver experience and go to chroot bind IMHO.

Do you know how the packaging is currently done? I did an 'everything' install and got the chroot bind preconfigured as caching-only, but don't have any idea what the other install options give you. Looks the same on fedora FC3 and FC2, but various boxes seem to have /etc/named.conf as normal files instead of symlinks to the chroot file, even though the /etc/sysconfig/named file contains ROOTDIR=/var/named/chroot. That could be confusing.

} } so you are recommending i run a full chrooted BIND dns server to serve } dns for my internal hosts and then use it to pass external DNs requests } to my firewall for forwarding? That was going to be my next step since } i intended to put samba as my PDC and when i can get a copy setup a 2k3 } server box to integrate Astaro and Samba directly into an AD environment. } } So let the full dns server adventure begin..! } }

yes, if you want to manage and run your own networks, you need to know dns and dns troubleshooting and know it well and it will save you time in the _long run_ plus you can truly be in control of _your networking business_ so to speak.

people will differ on what dns software yet the "theory" and "implementation" and "troubleshooting skills" are extremenly important in serving yourself and others.

- rh

-- Robert Hanson Abba Communications http://www.abbacomm.net

On Wed, 2005-08-10 at 12:10, William Warren wrote:

it is looking like it's partially windows brain dead dns caching as well. The caching is now working..I just need tog et the reverse lookups working so nslookup will like it. Right now there's a two second pause while my windows client tries to wait for the reverse lookup then it goes ahead and uses the server i specified.

The pause is just an nslookup thing as it is trying to get an answer from a nameserver that knows its own name as a sanity check. Normal programs (ping, etc.) will happily accept any answer, sane or not.

rofl i forgot one command..to start hte service rofl! ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14053 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13

;; QUESTION SECTION: ;. IN NS

;; ANSWER SECTION: . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 604800 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 604800 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 604800 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 604800 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 604800 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 604800 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 604800 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 604800 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 604800 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 604800 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 604800 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 604800 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 604800 IN A 202.12.27.33

;; Query time: 104 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Wed Aug 10 11:37:52 2005 ;; MSG SIZE rcvd: 436

Les Mikesell wrote:

On Wed, 2005-08-10 at 07:25, William Warren wrote:

...

dig to localhost says: [root@enoch ~]# dig localhost

dig localhost tells the system to ask the server(s) mentioned in /etc/resolve.conf to resolve the name localhost.

What you want is: dig @localhost which queries the nameserver on the local machine to show you some info from the root servers as a useful diagnostic to make sure it can reach them. If you are firewalled in a way that udp on port 53 can't get back from the internet and you aren't configured to use a forwarder that can get answers, you won't see the root servers displayed. You can also query for specific addresses: dig @localhost www.sun.com

On Wed, 2005-08-10 at 10:40, William Warren wrote:

nslookup trying to use enouch as a caching nameserver still fails:

*** Can't find server name for address 192.168.0.200: Non-existent domain Server: jericho.emmanuelcomputerconsulting.com Address: 192.168.0.1

That just means it can't reverse-resolve its own name which makes nslookup not trust it. You should fix that, but meanwhile it should work for normal operations. Try removing the alternative server(s) from a client and see if names still are resolved normally by everything but nslookup. You should get the same answer from dig @localhost some.domain.com as ping reports from a windows client.

too many threads, can we consolidate and get back on track?

:)

-- Robert Hanson Abba Communications http://www.abbacomm.net

Robert Hanson roberth@abbacomm.net wrote:

too many threads, can we consolidate and get back on track?

If you check the Message-ID, they are _all_ the _same_ thread.

Maintaining the root subject helps avoid this, just append follow-ups with the relevant change in focus.

E.g., I did when we went someone brought up nscd. I did it again when BIND was clearly the focus. I did the same when I focused on the Windows client.

If you view the archives, they are so threaded _together_.

If you [re-]append the subject, and sort by thread, date or even subject, you can easily pick out the relevant posts you are interested in (without having to read _all_ of them).

And they still sort well by subject, _unlike_ pre-pending the subject with something different. That should _only_ be done when the subject changes massively.

Mailing lists via SMTP, just like UseNet groups via NNTP, can benefit from this approach which was laid out in the O'Reilly Posting Guidelines from long ago.

Robert Hanson roberth@abbacomm.net wrote:

thanks Bryan, appreciated. like i said, i am not an expert at threads etc and i am currently using a braindead mailer etc till i can consolidate and switch.

Note that some people _do_ disagree with me. Especially since GMail came out and not only sorts on subject, but correlates on subject.

I try to only append the subject as necessary for a major focus, leaving the original root subject, and following up without change. That way it best addresses all things -- especially the archives and Google searches (just like UseNet threading/searches before that).

The main problem is for mail readers that don't track Message-ID. This is extremely common today thanx to most simple webmail services. Even my prior web service didn't honor this, so I avoided subject appending.

Yahoo Mail seems to track Message-ID fully, and that's why I switched. It's free, although it's $20/year if you want extra features (like the ability to change the From: address).

Ok removing hte alternate dns makes the caching nameserver work..:) I guess we need to fix the reverse-resolve now? Also why isn't it chrooted?

For Johnny selinux in in warn only mode.

Les Mikesell wrote:

On Wed, 2005-08-10 at 10:40, William Warren wrote:

...

nslookup trying to use enouch as a caching nameserver still fails:

*** Can't find server name for address 192.168.0.200: Non-existent domain Server: jericho.emmanuelcomputerconsulting.com Address: 192.168.0.1

That just means it can't reverse-resolve its own name which makes nslookup not trust it. You should fix that, but meanwhile it should work for normal operations. Try removing the alternative server(s) from a client and see if names still are resolved normally by everything but nslookup. You should get the same answer from dig @localhost some.domain.com as ping reports from a windows client.

On Tue, 2005-08-09 at 15:34 -0400, William Warren wrote:

Ok etc/named.conf is NOT a symlink and /var/named does NOT have the chroot folders. It has /var/named/data and /var/named/slaves both of which are blank.

OK, try rpm -e bind bind-chroot yum install bind bind-chroot

"bind" is the server "bind-chroot" sets up the symlinks

Remember that you will need to edit /var/named/chroot/var/named/* to change DNS entries.

Also remember to increment your SERIAL number each time you edit a zone file, or bind won't notice the change.