ipp.gov and Google DNS (8.8.8.8)
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
On Thu, May 30, 2013 at 09:04:44AM -0600, Josh Galvez <josh@zevlag.com> wrote 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.
On Thu, May 30, 2013 at 8:17 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Thu, May 30, 2013 at 09:04:44AM -0600, Josh Galvez <josh@zevlag.com> wrote 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.
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
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) On Thu, May 30, 2013 at 12:03 PM, Casey Deccio <casey@deccio.net> wrote:
On Thu, May 30, 2013 at 8:17 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Thu, May 30, 2013 at 09:04:44AM -0600, Josh Galvez <josh@zevlag.com> wrote 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.
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
On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu <guu@google.com> wrote:
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.
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.
On Thu, May 30, 2013 at 2:17 PM, Casey Deccio <casey@deccio.net> wrote:
On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu <guu@google.com> wrote:
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.
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.
Casey
* Although, that's only if the DO bit is set; interestingly, if I don't set the DO bit, the response times out.
Thus spake Casey Deccio (casey@deccio.net) on Thu, May 30, 2013 at 11:17:03AM -0700:
On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu <guu@google.com> wrote:
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.
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?
I would guess that it is to fit inside tunnels? You will also see smaller than usual MSS (ex: 1416) from some (all?) google tcp services. Dale
participants (5)
-
Casey Deccio -
Dale W. Carder -
Josh Galvez -
Stephane Bortzmeyer -
Yunhong Gu