BIND 9 NS records. (Bind 8 -> 9 ) migration.

[Mark.Andrews at nominum.com]

> 
> 
> > Are you sure the problem is that BIND 9 doesn't promote
> > NS RRs?  That looks like a vanilla "CNAME and other
> > data" error in the eecs.tulane.edu zone to me.
> 
> 
> > > In system log:
> > > "time info" transfer of 'eecs.tulane.edu' from 129.81.132.1#53:
> receiving
> > > responses: CNAME and other data
> >
> > Are you sure the problem is that BIND 9 doesn't promote
> > NS RRs?  That looks like a vanilla "CNAME and other
> > data" error in the eecs.tulane.edu zone to me.
> 
> 
> No, I am not sure.  Can you suggest an assesment method? Our current
> configuration worked before we upgraded to Bind 9. Does the eecs nameserver
> need to be configured to allow recursive queries?
> 
> Thanks for the info.
> 
> -Chris
> 
> -0-0-0-0-0-0-0-0-0-0-0---0-0-0-0-0-0-0-0-0-0-0--0
> 
> # dig @129.81.132.1 eecs.tulane.edu
> 
> ; <<>> DiG 9.1.3 <<>> @129.81.132.1 eecs.tulane.edu
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50291
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
> 
> ;; QUESTION SECTION:
> ;eecs.tulane.edu.               IN      A
> 
> ;; ANSWER SECTION:
> eecs.tulane.edu.        86400   IN      A       129.81.132.3
> 
> ;; AUTHORITY SECTION:
> eecs.tulane.edu.        86400   IN      NS      ns1.tcs.tulane.edu.
> eecs.tulane.edu.        86400   IN      NS      ns2.tcs.tulane.edu.
> eecs.tulane.edu.        86400   IN      NS      rex.eecs.tulane.edu.
> eecs.tulane.edu.        86400   IN      NS      pegasus.eecs.tulane.edu.
> 
> ;; ADDITIONAL SECTION:
> ns1.tcs.tulane.edu.     86400   IN      A       129.81.16.21
> ns2.tcs.tulane.edu.     86400   IN      A       129.81.224.50
> rex.eecs.tulane.edu.    86400   IN      A       129.81.132.1
> pegasus.eecs.tulane.edu. 86400  IN      A       129.81.132.3
> 
> ;; Query time: 64 msec
> ;; SERVER: 129.81.132.1#53(129.81.132.1)
> ;; WHEN: Tue Jul 10 14:05:15 2001
> ;; MSG SIZE  rcvd: 203
> 
> 
> --0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
> 
> # dig @ns2.tcs.tulane.edu eecs.tulane.edu
> 
> ; <<>> DiG 9.1.3 <<>> @ns2.tcs.tulane.edu eecs.tulane.edu
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11567
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;eecs.tulane.edu.               IN      A
> 
> ;; Query time: 2 msec
> ;; SERVER: 127.0.0.1#53(ns2.tcs.tulane.edu)
> ;; WHEN: Tue Jul 10 14:08:01 2001
> ;; MSG SIZE  rcvd: 33

	Using dig transfer the zone from the master then run
	named-checkzone on it.

	Unfortunately by the time we see this error we don't know
	which of the records being added to the database is the
	offending record.  We just know one of them triggered the
	problem.

	The master is most probably also complaining and is being
	ignored.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com