problem resolving ardownload.adobe.com

[Casey Deccio]

On Wed, Jul 2, 2014 at 2:51 PM, Carl Byington <carl at byington.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> version: 9.10.0-P2
>
> dig ardownload.adobe.com. @localhost
>
> ;; ANSWER SECTION:
> ardownload.adobe.com.   8743    IN  CNAME   ardownload.wip4.adobe.com.
>
>
What is the rest of the dig output?  Specifically, what status is your
resolver giving you (NOERROR or NXDOMAIN)?

When queried for type NS, the adobe load balancer returns NXDOMAIN:

$ dig @du1gtm001.adobe.com  ardownload.wip4.adobe.com ns

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @du1gtm001.adobe.com
ardownload.wip4.adobe.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42533
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ardownload.wip4.adobe.com.    IN    NS

;; AUTHORITY SECTION:
wip4.adobe.com.        30    IN    SOA    sj1gtm001.adobe.com.
hostmaster.sj1gtm001.adobe.com. 1283 10800 3600 604800 60

;; Query time: 116 msec
;; SERVER: 193.104.215.247#53(193.104.215.247)
;; WHEN: Mon Jul  7 16:58:37 2014
;; MSG SIZE  rcvd: 100


Even though A queries yield NOERROR:

$ dig @du1gtm001.adobe.com  ardownload.wip4.adobe.com a

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @du1gtm001.adobe.com
ardownload.wip4.adobe.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21275
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ardownload.wip4.adobe.com.    IN    A

;; ANSWER SECTION:
ardownload.wip4.adobe.com. 300    IN    CNAME
ardownload.adobe.com.edgesuite.net.

;; Query time: 119 msec
;; SERVER: 193.104.215.247#53(193.104.215.247)
;; WHEN: Mon Jul  7 16:59:25 2014
;; MSG SIZE  rcvd: 91

Your cache might be adversely affected by this behavior if your cache is
sending NS queries to authoritative servers (for example, RPZ with NS
lookup), which would cause the name to be cached as NXDOMAIN.

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140707/63991b78/attachment.html>