[Pdns-users] Erroneous NXDOMAIN from Ebay triggered by EDNS extra info

[sthaug at nethelp.no]

I'm trying to use PowerDNS recursor 3.5.3 with EDNS turned on:

disable-edns=no

in order to handle larger UDP message sizes. This leads to a failure
to resolve certain Ebay DNS names, e.g. i.ebayimg.com which through
a twisty maze of Akamai etc DNS results in the following, if EDNS is
turned off:

i.ebayimg.com.          2383    IN      CNAME   i.g.ebay.com.
i.g.ebay.com.           60      IN      CNAME   i.ebayimg.com.edgesuite.net.
i.ebayimg.com.edgesuite.net. 120 IN     CNAME   a1877.ca.akamai.net.
a1877.ca.akamai.net.    20      IN      A       217.212.246.51
a1877.ca.akamai.net.    20      IN      A       217.212.246.56

With EDNS turned on, I get the following instead (note the NXDOMAIN):

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47234
i.ebayimg.com.          3118    IN      CNAME   i.g.ebay.com.

Turns out the NXDOMAIN is actually returned from the Ebay servers,
triggered by EDNS extra info in the query generated by PowerDNS
recursor.

Doing a manual query towards g3.ebay.com (66.135.215.134), NS for
g.ebay.com, everything works:

% dig +norec +bufsize=1200 i.g.ebay.com. @66.135.215.134

I get the following when sniffing the traffic:

12:41:12.044165 IP 193.75.110.130.37904 > 66.135.215.134.53: 52959 [1au] A? i.g.ebay.com. (41)
12:41:12.197001 IP 66.135.215.134.53 > 193.75.110.130.37904: 52959*- 1/0/1 CNAME i.ebayimg.com.edgesuite.net. (82)

With PowerDNS recursor 3.5.3 running (on FreeBSD 8.4), starting with an
empty cache and querying the recursor for i.ebayimg.com, I get this as
part of the resolution process:

12:18:32.415616 IP 193.75.110.130.18626 > 66.135.215.134.53: 23698 [1au] A? i.g.ebay.com. (49)
12:18:32.576548 IP 66.135.215.134.53 > 193.75.110.130.18626: 23698 NXDomain*- 0/1/1 (91)

Notice the 8 additional bytes in the query, and NXDOMAIN reply from
g3.ebay.com. Looking closer at the queries, the first one contains a
normal EDNS OPT RR:

    193.75.110.130.37904 > 66.135.215.134.53: 52959 [1au] A? i.g.ebay.com. ar: . OPT UDPsize=1200 (41)
        0x0000:  4500 0045 6c33 0000 4011 c499 c14b 6e82  E..El3.. at ....Kn.
        0x0010:  4287 d786 9410 0035 0031 4a1e cedf 0000  B......5.1J.....
        0x0020:  0001 0000 0000 0001 0169 0167 0465 6261  .........i.g.eba
        0x0030:  7903 636f 6d00 0001 0001 0000 2904 b000  y.com.......)...
        0x0040:  0000 0000 00                             .....

The query generated by PowerDNS recursor 3.5.3 looks like this:

12:18:32.415616 IP (tos 0x0, ttl 64, id 42193, offset 0, flags [none], proto UDP (17), length 77)
    193.75.110.130.18626 > 66.135.215.134.53: 23698 [1au] A? i.g.ebay.com. ar: . OPT UDPsize=1200 (49)
        0x0000:  4500 004d a4d1 0000 4011 8bf3 c14b 6e82  E..M.... at ....Kn.
        0x0010:  4287 d786 48c2 0035 0039 4a26 5c92 0000  B...H..5.9J&\...
        0x0020:  0001 0000 0000 0001 0169 0167 0465 6261  .........i.g.eba
        0x0030:  7903 636f 6d00 0001 0001 0000 2904 b000  y.com.......)...
        0x0040:  0000 0000 0800 0500 0456 6086 8e         .........V`..

It seems the additional 8 bytes in the query from PowerDNS trigger
the NXDOMAIN reply from g3.ebay.com. So what are these 8 bytes? If
I use Wireshark to look at the data, I get a data length of 8, and
*unknown option code 5*, option length 4, data 5660868e, corresponding
to the following bytes of the query:

        0x0040:  .......00 0800 0500 0456 6086 8e

According to RFC 6975, Option code 5 of the OPT RR should be used to
signal DAU (DNSSEC Algorithm Understood) - however, I doubt that this
is really what PowerDNS recursor is trying to tell me here. It seems
more likely that the inclusion of these additional 8 bytes in the
query is a bug in PowerDNS recursor 3.5.3.

Anybody else seen this?

Full pcap files available on request.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no