Is anyone else seeing this? From Santa Clara, CA, on Comcast
Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and
8.8.4.4...
Level 3's own public resolvers are fine for me, as are OpenDNS's resolvers.
Blair
Works fine from here, Philadelphia, PA .edu and FIOS networks
Cheers,
Harry
Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. The expected behaviour in the case where a response does not validate is to return SERVFAIL to the client.
You could check that the queries you are sending are not suffering from poor signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation).
If this is a repeatable, consistent problem even for unsigned zones (or for zones that you've verified are signed correctly) and especially if it's widespread you might want to call google on the nanog courtesy phone and have them look for collateral damage from their recent foray into 8.8.8.8 validation.
Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly recommended if you need to take this further.
Joe
That's all well and good, but I certainly wouldn't expect "nslookup
gmail.com" or for "nslookup google.com" to return SERVFAIL
No issues on Comcast cable in the bay area, either Comcast business or
Comcast home.
Scott
$ nslookup gmail.com 8.8.4.4
Server: 8.8.4.4
Address: 8.8.4.4#53
Non-authoritative answer:
Name: gmail.com
Address: 74.125.239.149
Name: gmail.com
Address: 74.125.239.150
If you set the CD (checking disabled) in the request, a response that
would normally be SERVFAIL due to DNSSEC validation failure will
return with the non-authenticated answer. With dig the flag to add is
"+cd". I don't know if there's an equivalent for nslookup. For
example:
dig +cd @8.8.8.8 google.com
Casey
Goes all the way up to the A root server before failing spectacularly.
Europa:~ blair$ dig +cd @8.8.8.8 google.com A
; <<>> DiG 9.8.3-P1 <<>> +cd @8.8.8.8 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47332
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; AUTHORITY SECTION:
. 467 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013050100 1800
900 604800 86400
;; Query time: 46 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed May 1 10:05:46 2013
;; MSG SIZE rcvd: 104
8.8.4.4 is now replying SERVFAIL whereas 8.8.8.8 is suddenly working fine
again...
Do you have traceroutes to 8.8.8.8 and 8.8.4.4?
Goes all the way up to the A root server before failing spectacularly.
That is an extremely weird response. Are you sure your queries are not
being intercepted by a middlebox? What happens if you use dig +vc ?
Do you get a similar round-trip time when pinging 8.8.8.8 to the one
reported by dig?
Europa:~ blair$ dig +cd @8.8.8.8 google.com A
; <<>> DiG 9.8.3-P1 <<>> +cd @8.8.8.8 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47332
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0;; QUESTION SECTION:
;google.com. IN A;; AUTHORITY SECTION:
. 467 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013050100 1800 900 604800 86400;; Query time: 46 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed May 1 10:05:46 2013
;; MSG SIZE rcvd: 104
Tony.
Once upon a time, Joe Abley <jabley@hopcount.ca> said:
Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly recommended if you need to take this further.
Does Google (and OpenDNS for that matter) support any "special" queries
that identify the host/cluster/etc.? Something like BIND's CHAOS
HOSTNAME.BIND (which also works for Unbound and some other servers), or
UltraDNS's WHOAREYOU.ULTRADNS.NET.
Some places like Wayport/attwifi intercept all udp/53 traffic and direct it to their local server. You won't notice this with a ping, but you will see it in the 0 or 1ms reply 
- Jared
Traceroute is getting the right place and 8.8.8.8 is working, though
FWIW, no DNS intercepts happen on the Comcast networkŠ
Jason (Comcast)
It is very courteous to reply a SERVFAIL for requests being rate limited.
It is very courteous to reply a SERVFAIL for requests being rate limited.
I believe the 'rate-limit' response is actually 'no response' ... though I
haven't tested this myself
> It is very courteous to reply a SERVFAIL for requests being rate
limited.
>
>
I believe the 'rate-limit' response is actually 'no response' ... though I
haven't tested this myself
Yes if someone has a misbehaving program or is trying to DOS you, you don't
really want to reply with anything.
> > Your IPs may have been rate limited...
> >
> > Andy
> >
> > Andrew Fried
> > andrew.fried@gmail.com
> >
> >> That's all well and good, but I certainly wouldn't expect "nslookup
> >> gmail.com" or for "nslookup google.com" to return SERVFAIL
> >>
> >>
> >>
> >>>
> >>>
> >>>> Is anyone else seeing this? From Santa Clara, CA, on Comcast
> >>>> Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8
and
> >>>> 8.8.4.4...
> >>>>
> >>>> Level 3's own public resolvers are fine for me, as are OpenDNS's
> >>> resolvers.
> >>>
> >>> Google just turned on validation across the whole of 8.8.8.8 and
> 8.8.4.4.
> >>> The expected behaviour in the case where a response does not
validate
> is to
> >>> return SERVFAIL to the client.
> >>>
> >>> You could check that the queries you are sending are not suffering
from
> >>> poor signing hygiene (e.g. use the handy-dandy
dnsviz.netvisualisation).
> >>>
> >>> If this is a repeatable, consistent problem even for unsigned zones
(or
> >>> for zones that you've verified are signed correctly) and especially
if
Is that actually pertinent?
8.8 and 8.4 aren't *public zone servers* for Google's commercial domains,
are they? I have been assuming they were only open recursive resolver
nameservers...
Cheers,
-- jra
I think perry's question is: "Can you show me which networks you traversed
and which instance of the service you were talking to at the time of the
problem?" (or 'now' if the problem is persisting)