ipp.gov and Google DNS (8.8.8.8)

Mailman List Mirror (Read Only)
1

Google Public DNS (8.8.8.8, 8.8.4.4) is failing to resolve ipp.gov,
returning a SERVFAIL. Other DNS servers seem to resolve this just fine
(ie. OpenDNS)

If I use dig +trace, I get appropriate results all the way down.

DNSSEC seems to be validating properly.
http://dnssec-debugger.verisignlabs.com/ipp.gov
http://dnsviz.net/d/ipp.gov/dnssec/

Is there any one here from Google that can help with this?

See dig results and traceroutes below.

-Josh

$ dig @8.8.8.8 ipp.gov soa +trace

; <<>> DiG 9.8.3-P4 <<>> @8.8.8.8 ipp.gov soa +trace
; (1 server found)
;; global options: +cmd
. 2209 IN NS e.root-servers.net.
. 2209 IN NS h.root-servers.net.
. 2209 IN NS d.root-servers.net.
. 2209 IN NS i.root-servers.net.
. 2209 IN NS k.root-servers.net.
. 2209 IN NS j.root-servers.net.
. 2209 IN NS l.root-servers.net.
. 2209 IN NS a.root-servers.net.
. 2209 IN NS b.root-servers.net.
. 2209 IN NS c.root-servers.net.
. 2209 IN NS f.root-servers.net.
. 2209 IN NS g.root-servers.net.
. 2209 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 1218 ms

gov. 172800 IN NS a.gov-servers.net.
gov. 172800 IN NS b.gov-servers.net.
;; Received 132 bytes from 128.63.2.53#53(128.63.2.53) in 113 ms

ipp.gov. 86400 IN NS ns1.federalreserve.org.
ipp.gov. 86400 IN NS ns2.federalreserve.org.
ipp.gov. 86400 IN NS ns3.federalreserve.org.
;; Received 97 bytes from 69.36.157.30#53(69.36.157.30) in 375 ms

ipp.gov. 30 IN SOA ns1.federalreserve.org.
dns.ids.frb.org. 5 1200 1800 1209600 21600
ipp.gov. 30 IN NS ns1.federalreserve.org.
ipp.gov. 30 IN NS ns3.federalreserve.org.
ipp.gov. 30 IN NS ns2.federalreserve.org.
;; Received 193 bytes from 199.169.208.138#53(199.169.208.138) in 40 ms

$ dig @8.8.8.8 ipp.gov soa

; <<>> DiG 9.8.3-P4 <<>> @8.8.8.8 ipp.gov soa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ipp.gov. IN SOA

;; Query time: 3353 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu May 30 14:55:08 2013
;; MSG SIZE rcvd: 25

$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
1 ve1003.mpls1.core.prco.etv.net (66.111.113.1) 5.989 ms 0.534 ms
0.222 ms
2 interface-74-214-233-10 (74.214.233.10) 5.205 ms 2.618 ms 2.615 ms
3 te-8-3.car2.SaltLakeCity1.Level3.net (4.53.42.153) 146.414 ms 178.280
ms 3.753 ms
4 ae-11-11.car1.SaltLakeCity1.Level3.net (4.69.133.121) 30.170 ms
33.988 ms 40.203 ms
5 * * *
6 ae-91-91.csw4.LosAngeles1.Level3.net (4.69.137.14) 30.178 ms 30.058 ms
    ae-81-81.csw3.LosAngeles1.Level3.net (4.69.137.10) 30.047 ms
7 * * *
8 GOOGLE-INC.edge1.LosAngeles9.Level3.net (4.53.228.6) 30.293 ms 29.913
ms 29.950 ms
9 216.239.46.40 (216.239.46.40) 30.129 ms
    64.233.174.238 (64.233.174.238) 86.755 ms
    216.239.46.40 (216.239.46.40) 30.164 ms
10 64.233.174.192 (64.233.174.192) 67.074 ms
    64.233.174.188 (64.233.174.188) 30.725 ms
    64.233.174.186 (64.233.174.186) 46.088 ms
11 72.14.239.153 (72.14.239.153) 42.234 ms
    72.14.239.159 (72.14.239.159) 42.772 ms
    72.14.239.160 (72.14.239.160) 43.318 ms
12 64.233.174.129 (64.233.174.129) 41.513 ms 41.510 ms
    64.233.174.131 (64.233.174.131) 42.157 ms
13 * * *
14 google-public-dns-a.google.com (8.8.8.8) 42.258 ms 42.423 ms 42.408
ms

$ traceroute 8.8.4.4
traceroute to 8.8.4.4 (8.8.4.4), 64 hops max, 40 byte packets
1 ve1003.mpls1.core.prco.etv.net (66.111.113.1) 0.287 ms 0.290 ms
0.175 ms
2 interface-74-214-233-10 (74.214.233.10) 7.919 ms 2.576 ms 2.687 ms
3 te-8-3.car2.SaltLakeCity1.Level3.net (4.53.42.153) 2.848 ms 2.767 ms
2.758 ms
4 ae-11-11.car1.SaltLakeCity1.Level3.net (4.69.133.121) 30.160 ms
30.289 ms 30.147 ms
5 * * *
6 ae-81-81.csw3.LosAngeles1.Level3.net (4.69.137.10) 30.222 ms
    ae-61-61.csw1.LosAngeles1.Level3.net (4.69.137.2) 30.070 ms 30.220 ms
7 * * *
8 GOOGLE-INC.edge1.LosAngeles9.Level3.net (4.53.228.6) 30.086 ms 30.301
ms 30.325 ms
9 64.233.174.238 (64.233.174.238) 30.178 ms 30.228 ms
    216.239.46.40 (216.239.46.40) 30.440 ms
10 64.233.174.192 (64.233.174.192) 30.392 ms
    64.233.174.190 (64.233.174.190) 30.564 ms
    72.14.238.0 (72.14.238.0) 42.441 ms
11 72.14.239.155 (72.14.239.155) 41.626 ms 42.002 ms
    72.14.239.157 (72.14.239.157) 42.397 ms
12 216.239.48.167 (216.239.48.167) 41.958 ms
    64.233.174.131 (64.233.174.131) 42.470 ms
    216.239.48.167 (216.239.48.167) 42.106 ms
13 * * *
14 google-public-dns-b.google.com (8.8.4.4) 41.619 ms 41.725 ms 41.527
ms

2

a message of 135 lines which said:

DNSSEC seems to be validating properly.

Since Google Public DNS returns SERVFAIL even with the +cd option
(Checking Disabled), I suspect that it is not a DNSSEC issue at all.

3

That's not my experience:

$ dig +cd @8.8.8.8 ipp.gov | grep status:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16884
$ dig @8.8.8.8 ipp.gov | grep status:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57555

The resolvers seem to be choking on the DNSKEY (with or without CD):

$ dig +cd @8.8.8.8 ipp.gov dnskey | grep status:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19590

Casey

4

Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from
its authoritative name servers. If there is anyone on this list who manages
ipp.gov DNS servers, please take a look. Our resolver IPs can be found at
https://developers.google.com/speed/public-dns/faq#locations.

Thanks
Yunhong (Google Public DNS)

5

I get a response for DNSKEY just fine*. However, the payload of the
response is 1279 bytes, and Google's resolvers set the maximum UDP
receive payload to 1232, which results in the truncated response.
Unfortunately, the ipp.gov servers don't respond over TCP, so the
resolvers aren't able to retrieve ipp.gov/DNSKEY.

The problem here is that the ipp.gov servers aren't responding on
TCP/53. But of curiosity, why a max payload size of 1232 for the
Google resolvers? It seems like that would result in a lot more TCP
transactions (and overhead) for queries to signed zones.

Casey

* Although, that's only if the DO bit is set; interestingly, if I
don't set the DO bit, the response times out.

6

> Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from
its
> authoritative name servers. If there is anyone on this list who manages
> ipp.gov DNS servers, please take a look. Our resolver IPs can be found
at
> Frequently Asked Questions  |  Public DNS  |  Google for Developers.
>
>

I get a response for DNSKEY just fine*. However, the payload of the
response is 1279 bytes, and Google's resolvers set the maximum UDP
receive payload to 1232, which results in the truncated response.
Unfortunately, the ipp.gov servers don't respond over TCP, so the
resolvers aren't able to retrieve ipp.gov/DNSKEY.

Thanks, I suspected this problem but tried to verify using a wrong buffer
size by mistake.

The problem here is that the ipp.gov servers aren't responding on
TCP/53. But of curiosity, why a max payload size of 1232 for the
Google resolvers? It seems like that would result in a lot more TCP
transactions (and overhead) for queries to signed zones.

There is still chance for fragmented UDP responses to get dropped nowadays,
so we want response in single UDP packets or otherwise from TCP. Overhead
should be insignificant due to the cache in resolvers. That being said, we
are testing 4k max UDP buffer and may turn it on in the near future.

7

Thus spake Casey Deccio (casey@deccio.net) on Thu, May 30, 2013 at 11:17:03AM -0700: