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 <3bddbe8cfba149818ce53daa53631...@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@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_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
