Intermittent name resolution for spmonline.petronas.com.my

Elias elias at streamyx.com
Tue Mar 17 03:23:11 UTC 2009


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 - 




More information about the bind-users mailing list