problems with UA worldwide sites on IPv6 enabled PC

[Barry Margolin]

In article <d52qq5$1bqn$1 at sf1.isc.org>,
 Mathias Koerber <mathias at koerber.org> wrote:

> Here is the detailed problem description I sent UAL on
> this problem recently (KMM2534973V89232L0KM):

If you want to emulate the way a resolver works, you should really be 
sending your queries without the RD flag, i.e. use the +norec option to 
dig.

> > 3. HOWEVER, both nameservers reply with an NON-AUTHORITATIVE answer when
> >    queried for www.unitedairlines.com.sg [incorrect]

You asked for recursion, so they recursed (it's not a great idea to have 
recursion enabled on authoritative server, but it's not prohibited by 
any specification I know of).  But since they're not authoritative for 
the www.unitdairlines.com.sg subdomain, they correctly return 
non-authoritative answers.

> > HOWEVER: We had been told by dns01.uls-prod.com that
> > dc2lbs1.uls-prod.com is the real nameserver for
> > www.unitedairlines.com.sg, so a good nameserver will not simply trust
> > the NS records learned this way, but will refresh them by asking
> > dc2lbs1.uls-prod.com itself:

I've never heard of BIND doing this explicit query for NS records when 
it's refreshing its cache.  It just sends whatever query it's recursing 
for to the most specific NS record in its cache, and expects it to 
return either an answer or a delegation to a lower-level server.

> > 
> >   > [root at nano1 ~]# dig @dc2lbs1.uls-prod.com. www.unitedairlines.com.sg NS
> >   >
> >   > ; <<>> DiG 9.3.0 <<>> @dc2lbs1.uls-prod.com.
> > www.unitedairlines.com.sg NS
> >   > ;; global options:  printcmd
> >   > ;; Got answer:
> >   > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49223
> >   > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> >   >
> >   > ;; QUESTION SECTION:
> >   > ;www.unitedairlines.com.sg.     IN      NS
> >   >
> >   > ;; Query time: 258 msec
> >   > ;; SERVER: 209.87.113.4#53(dc2lbs1.uls-prod.com.)
> >   > ;; WHEN: Sat Apr 30 10:30:23 2005
> >   > ;; MSG SIZE  rcvd: 43
> > 
> > BAD: Now dc2lbs1.uls-prod.com returns a SERVFAIL error for this domain.
> > This will result in the local nameserver (in this case here at my ISP)
> > to mark this nameserver as LAME for this domain.
> > 
> > The problem is that dns01.uls-prod.com/dns02.uls-prod.com claim
> > that www.unitedairlines.com.sg is a separate zone with authoritative
> > nameservers dc1lbs1.uls-prod.com/dc2lbs1.uls-prod.com, but that those
> > two nameservers respond with failure when asked to confirm the NS
> > list for www.unitedairlines.com.sg...

These dcXlbs1.uls-prod.com servers are probably not full-featured 
nameservers, but DNS-based load balancing appliances like Local 
Director.  They typically implement just enough of the DNS protocol to 
support their needs.

Since these servers will not be queried for the NS records in the course 
of normal hostname resolution, I don't think this should cause any 
operational problems.  And I don't think it has anything to do with the 
problem you encounter only when enabling IPv6 on your PC.

However, I noticed that if I queried them with +norec, I did get a more 
proper response:

barmar $ dig www.unitedairlines.com.sg ns @dc1lbs1.uls-prod.com +norec

; <<>> DiG 9.2.2 <<>> www.unitedairlines.com.sg ns @dc1lbs1.uls-prod.com 
+norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24703
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.unitedairlines.com.sg.   IN NS

;; AUTHORITY SECTION:
www.unitedairlines.com.sg. 86396 IN NS dc2lbs1.uls-prod.com.
www.unitedairlines.com.sg. 86396 IN NS dc1lbs1.uls-prod.com.

;; ADDITIONAL SECTION:
dc1lbs1.uls-prod.com.   86396 IN A  209.87.112.4
dc2lbs1.uls-prod.com.   86396 IN A  209.87.113.4

;; Query time: 117 msec
;; SERVER: 209.87.112.4#53(dc1lbs1.uls-prod.com)
;; WHEN: Sun May  1 12:56:14 2005
;; MSG SIZE  rcvd: 131

It's NON-AUTHORITATIVE, which is wrong, but at least it's not a SERVFAIL.

My guess is that your IPv6 problem is that you're querying for AAAA 
records, and these server return the same kind of non-authoritative 
NOERROR response for this.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***