Verisign fix

[Ian Northeast]

Dave Lugo wrote:
> 
> Paul Vixie wrote:
> >>...  We are screwed because we no longer cache data for .com, etc
> >>requiring recursive lookups for everything.  Am I misunderstanding how
> >>this will work?
> >
> >
> > yes, you are.  use of the delegation-only feature does not prevent caching.
> >
> 
> Uhh... this seems a bit odd - I can no longer query for NS records from
> the root:
> 
> dlugo at spot> dig ns stk.com
> 
> ; <<>> DiG 9.2.2rc1 <<>> ns stk.com
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21648
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

I'm seeing something similar. Using 9.2.2-P1 on Suse Linux Enterprise
Server 8 (UL 1.0) kernel 2.4.19, if I issue an NS query for a valid
domain with an empty cache I get NXDOMAIN:

ihqs35a1:~ # rndc flush
ihqs35a1:~ # dig @localhost ibm.com ns 

; <<>> DiG 9.2.2-P1 <<>> @localhost ibm.com ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56915
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 

But if I then issue an A or MX or something, which works, and try the NS
again, it works. I too see the "enforced delegation-only" message.

It does not appear to make any difference whether the domain's
nameservers are within the domain or not.

OK this isn't going to break much in real life but it could certainly
confuse troubleshooting. I'm holding off on implementing this for now.

Regards, Ian