Update. After I sent this, I realized the the two servers experiencing =
the problem did NOT have the "forwarders {};" in their named.conf for =
"principal.com". I added it in so they are the same.
Now I'm wondering...does that line still have an affect on how things =
work, even though I'm not using forwarders anymore?
I'm thinking it might...
-----Original Message-----
From: Treptow, Craig=20
Sent: Friday, July 18, 2003 4:45 PM
To: BIND List (E-mail)
Subject: W2K delegation issue
Hi. We are running BIND 9.2.2 on Solaris 8. We have an internal copy =
=3D
of the principal.com domain as well as an external copy hosted by our =
=3D
ISP.
Internally, we have delegated the corp subdomain for W2K usage:
In db.principal.com:
corp 3600 IN NS pfgdsmdc001.corp.principal.com.
corp 3600 IN NS pfgdsmdc002.corp.principal.com.
pfgdsmdc001.corp.principal.com. IN A 162.131.5.74
pfgdsmdc002.corp.principal.com. IN A 162.131.154.12
When looking up a host in one of the subdomains under corp =3D
(principalusa), you normally see this:
; <<>> DiG 9.2.2 <<>> pfgscldc001.principalusa.corp.principal.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6119
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 17, ADDITIONAL: 0
;; QUESTION SECTION:
;pfgscldc001.principalusa.corp.principal.com. IN A
;; ANSWER SECTION:
pfgscldc001.principalusa.corp.principal.com. 18 IN A 192.168.76.219
;; AUTHORITY SECTION:
principalusa.corp.principal.com. 56 IN NS =3D
pfgapndc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgbuedc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgdsmdc003.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgdsmdc004.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgdsmdc005.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgdsmdc006.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfggridc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfghkgdc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfglondc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgmdtdc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgmexdc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgmscdc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgmtydc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgscldc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgspkdc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgsyddc001.principalusa.corp.principal.com.
principalusa.corp.principal.com. 56 IN NS =3D
pfgwtldc001.principalusa.corp.principal.com.
;; Query time: 9 msec
;; SERVER: 162.131.23.103#53(162.131.23.103)
;; WHEN: Fri Jul 18 16:34:59 2003
;; MSG SIZE rcvd: 507
or this:
; <<>> DiG 9.2.2 <<>> pfgscldc001.principalusa.corp.principal.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22794
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;pfgscldc001.principalusa.corp.principal.com. IN A
;; ANSWER SECTION:
pfgscldc001.principalusa.corp.principal.com. 300 IN A 192.168.76.219
;; AUTHORITY SECTION:
principalusa.corp.principal.com. 3600 IN NS =3D
pfgdsmdc003.principalusa.corp.principal.com.
principalusa.corp.principal.com. 3600 IN NS =3D
pfgdsmdc004.principalusa.corp.principal.com.
;; Query time: 18 msec
;; SERVER: 162.131.23.103#53(162.131.23.103)
;; WHEN: Fri Jul 18 16:35:45 2003
;; MSG SIZE rcvd: 129
Sometimes we see this, though:
; <<>> DiG 9.2.2 <<>> pfgdsmdc004.principalusa.corp.principal.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58515
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;pfgdsmdc004.principalusa.corp.principal.com. IN A
;; AUTHORITY SECTION:
principal.com. 8517 IN SOA dnspri.sys.gtei.net. =3D
dns-admin.bbnplanet.com. 2003071750 3600 900 864000 86400
;; Query time: 7 msec
;; SERVER: 162.131.23.103#53(162.131.23.103)
;; WHEN: Thu Jul 17 16:45:15 2003
;; MSG SIZE rcvd: 136
Here are some sections from named.conf:
options {
directory "/usr/dns/bind/data";
pid-file "/usr/dns/bind/etc/named.pid";
listen-on port 53 { 162.131.38.89; };
notify yes;
query-source address 162.131.38.89 port *;
transfer-source 162.131.38.89;
notify-source 162.131.38.89;
allow-query { any; };
allow-transfer { localhost; };
transfer-format many-answers;
recursive-clients 4000;
tcp-clients 100;
provide-ixfr yes;
};
zone "principal.com" IN {
type master;
file "master/db.principal.com";
allow-update {none;};
allow-transfer =3D
{localhost;dns-secondary-servers;midrange-servers;};
also-notify { 162.131.46.68; 162.131.62.180; };
forwarders {};
};
We used to forward to our ISP's name servers, but we don't anymore, so =
=3D
can I get rid of the forwarders line under the principal.com zone =3D
definition?
More importantly, does anybody have any idea what is going on? It acts =
=3D
like when this happens, it doesn't know anything about any domain ending =
=3D
in "principal.com" and shoves the request out the Internet. Could I be =
=3D
getting bad data from one of the W2K DC's sometimes? Or could something =
=3D
else be causing this? Is it my forwarders line?
The only solution I have when this happens is "rndc flush".
Any help or ideas with this will be greatly appreciated!!
Thanks!
Craig
|
