Intermittent name resolution for spmonline.petronas.com.my

[Mark Andrews]

	It's a load balancer which intercepts A queries and passes
	everything else to the nameserver behind it which knows
	nothing about spmonline.lb2.petronas.com.my so it returns
	NXDOMAIN.   As you have IPv6 aware applications they make
	AAAA queries which results in NXDOMAIN being returned which
	is then cached.

	Tell the administrator of the load balancer to correctly
	configure the backing nameserver to add a A record for
	spmonline.lb2.petronas.com on the backing zone.  That way
	the answers that the backing server returns will be consistant
	with those returned from the load balancer.

; <<>> DiG 9.3.6-P1 <<>> aaaa @lb2jr.petronas.com.my spmonline.lb2.petronas.com.my
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16217
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;spmonline.lb2.petronas.com.my.	IN	AAAA

;; AUTHORITY SECTION:
lb2.petronas.com.my.	3600	IN	SOA	lb2jr.petronas.com.my. dnsadmin.pttcdc.com.my. 2008081601 1200 900 86400 3600

;; Query time: 386 msec
;; SERVER: 170.38.17.251#53(170.38.17.251)
;; WHEN: Tue Mar 17 14:44:01 2009
;; MSG SIZE  rcvd: 105

	Mark

In message <3BDDBE8CFBA149818CE53DAA536316B1 at EliasLaptop>, "Elias" writes:
> Hello all,
> 
> We're seing intermittent name resolution for spmonline.lb2.petronas.com.my 
> but can't seem to pin the issue down. While troubleshooting I noticed that 
> their nameserver will return an NXDOMAIN answer whenever a TCP query is sent 
> and thought I'd bingo'ed the issue down.
> 
> # dig @lb2jr.petronas.com.my spmonline.lb2.petronas.com.my +tcp
> 
> ; <<>> DiG 9.6.0rc2 <<>> @lb2jr.petronas.com.my 
> spmonline.lb2.petronas.com.my +tcp
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1050
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;spmonline.lb2.petronas.com.my. IN      A
> 
> ;; AUTHORITY SECTION:
> lb2.petronas.com.my.    3600    IN      SOA     lb2jr.petronas.com.my. 
> dnsadmin.pttcdc.com.my. 2008081601 1200 900 86400 3600
> 
> The admin reacted quickly by saying that they don't allow zone transfers (I 
> don't see how that relates to the issue), and have since completely blocked 
> of TCP/53. So I'm back to square one again.
> 
> 
> This is the cache dump whenever the query fails (BIND 9.6.0rc2) :
> 
> 
> ; authauthority
> petronas.com.my.        20296   NS      ns2.petronas.com.my.
>                                   20296   NS      gateway.petronas.com.my.
> ; authanswer
> gateway.petronas.com.my. 20296  A       170.38.99.99
> ; glue
> lb2.petronas.com.my.    19493   NS      lb2jr.petronas.com.my.
>                                     19493   NS      lb2tt.petronas.com.my.
> ; authauthority
> spmonline.lb2.petronas.com.my. 2269 \-ANY ;-$NXDOMAIN
> ; authanswer
> lb2jr.petronas.com.my.  20417   A       170.38.17.251
> ; authanswer
> lb2tt.petronas.com.my.  20411   A       211.25.204.251
> ; authanswer
> ns2.petronas.com.my.    20320   A       170.38.22.200
> ; answer
> spmonline.petronas.com.my. 19493 CNAME  spmonline.lb2.petronas.com.my.
> 
> 
> Another question is, when do queries normally switch to TCP? I know that 
> when the answer is to big to fit in a single UDP packet, it is switched to 
> TCP, but are there any other reasons? RFC 5452 has a mention that certain 
> resolvers may re-issue the query over TCP when they detects spoofing 
> attempts (can anyone explain in detail how this is achieved, greatly 
> appreciated :D)
> 
> Thx!
> 
> 
> - Elias - 
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org