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 On 05/01/2013 12:09 PM, Blair Trosper wrote:
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
On 2013-05-01, at 12:09, Blair Trosper <blair.trosper@gmail.com> wrote:
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.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 On Wed, May 1, 2013 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-01, at 12:09, Blair Trosper <blair.trosper@gmail.com> wrote:
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.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
On Wed, May 1, 2013 at 9:38 AM, Blair Trosper <blair.trosper@gmail.com> wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
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 On Wed, May 1, 2013 at 9:58 AM, Casey Deccio <casey@deccio.net> wrote:
On Wed, May 1, 2013 at 9:38 AM, Blair Trosper <blair.trosper@gmail.com> wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
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
8.8.4.4 is now replying SERVFAIL whereas 8.8.8.8 is suddenly working fine again... On Wed, May 1, 2013 at 10:07 AM, Blair Trosper <blair.trosper@gmail.com>wrote:
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
On Wed, May 1, 2013 at 9:58 AM, Casey Deccio <casey@deccio.net> wrote:
On Wed, May 1, 2013 at 9:38 AM, Blair Trosper <blair.trosper@gmail.com> wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
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
Blair Trosper <blair.trosper@gmail.com> wrote:
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. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
On May 1, 2013, at 1:39 PM, Tony Finch <dot@dotat.at> wrote:
Blair Trosper <blair.trosper@gmail.com> wrote:
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?
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 :) On Wed, May 1, 2013 at 11:23 AM, Jared Mauch <jared@puck.nether.net> wrote:
On May 1, 2013, at 1:39 PM, Tony Finch <dot@dotat.at> wrote:
Blair Trosper <blair.trosper@gmail.com> wrote:
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?
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
On 5/1/13 2:23 PM, "Jared Mauch" <jared@puck.nether.net> wrote:
On May 1, 2013, at 1:39 PM, Tony Finch <dot@dotat.at> wrote:
Blair Trosper <blair.trosper@gmail.com> wrote:
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?
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 :)
FWIW, no DNS intercepts happen on the Comcast networkŠ Jason (Comcast)
Your IPs may have been rate limited... Andy Andrew Fried andrew.fried@gmail.com On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
On Wed, May 1, 2013 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-01, at 12:09, Blair Trosper <blair.trosper@gmail.com> wrote:
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.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
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com <http://gmail.com>" or for "nslookup google.com" to return SERVFAIL
Do you have traceroutes to 8.8.8.8 and 8.8.4.4?
----- Original Message -----
From: "Perry Lorier" <isomer@gmail.com>
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com <http://gmail.com>" or for "nslookup google.com" to return SERVFAIL
Do you have traceroutes to 8.8.8.8 and 8.8.4.4?
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Thu, May 2, 2013 at 10:32 AM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Perry Lorier" <isomer@gmail.com>
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com <http://gmail.com>" or for "nslookup google.com" to return SERVFAIL
Do you have traceroutes to 8.8.8.8 and 8.8.4.4?
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...
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)
----- Original Message -----
From: "Christopher Morrow" <morrowc.lists@gmail.com>
On Thu, May 2, 2013 at 10:32 AM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Perry Lorier" <isomer@gmail.com>
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com <http://gmail.com>" or for "nslookup google.com" to return SERVFAIL
Do you have traceroutes to 8.8.8.8 and 8.8.4.4?
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...
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)
Sure, Chris. But since Perry's problem is *inability to resolve names in google's public zones*, the *path to the ZONE servers* is the thing diagnostics would require a trace to, no? If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it has), then how you get there is irrelevant. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 2013-05-02, at 11:51, Jay Ashworth <jra@baylink.com> wrote:
But since Perry's problem is *inability to resolve names in google's public zones*, the *path to the ZONE servers* is the thing diagnostics would require a trace to, no?
Blair's problem, I think. Perry was just being helpful. Blair's point was that if Google DNS is not able to resolve Google domains, then you know something is wrong.
If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it has), then how you get there is irrelevant.
Well, if you're trying to troubleshoot the performance or functionality of a service that is deployed using anycast, knowing what anycast node is giving problems is pretty useful. I say this as someone who has to help troubleshoot problems with anycast DNS services pretty regularly. Since there's no obvious way (in the draft-jabley-dnsop-anycast-mapping sense) to identify a Google DNS anycast node in-band, traceroute and RTT are pretty much what we're left with. Joe
Joe, That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using. charles On Thu, May 2, 2013 at 11:55 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 11:51, Jay Ashworth <jra@baylink.com> wrote:
But since Perry's problem is *inability to resolve names in google's public zones*, the *path to the ZONE servers* is the thing diagnostics would require a trace to, no?
Blair's problem, I think. Perry was just being helpful. Blair's point was that if Google DNS is not able to resolve Google domains, then you know something is wrong.
If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it has), then how you get there is irrelevant.
Well, if you're trying to troubleshoot the performance or functionality of a service that is deployed using anycast, knowing what anycast node is giving problems is pretty useful. I say this as someone who has to help troubleshoot problems with anycast DNS services pretty regularly.
Since there's no obvious way (in the draft-jabley-dnsop-anycast-mapping sense) to identify a Google DNS anycast node in-band, traceroute and RTT are pretty much what we're left with.
Joe
On 2013-05-02, at 11:59, Charles Gucker <cgucker@onesc.net> wrote:
That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using.
Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query. If I can rely upon there being an Akamai auth server every place there's a Google 8.8.8.8 server, then that does seem fun and useful for identifying the Google node I'm using. Is that the case? (If I ask 8.8.8.8, which is somewhere 30ms from Toronto, about identity.l.root-servers.org/IN/TXT then the answer I get just now is "Paris, France". L-Root and Google/8.8.8.8 are not colocated. So the usefulness of this technique in general to identify Google nodes depends on deployment assumptions.) Joe
On 2013-05-02, at 12:10, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 11:59, Charles Gucker <cgucker@onesc.net> wrote:
That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using.
Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query.
Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit. Never mind, I understand now :-) Joe
On May 02, 2013, at 12:12 , Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 12:10, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 11:59, Charles Gucker <cgucker@onesc.net> wrote:
That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using.
Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query.
Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit.
Never mind, I understand now :-)
For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net. We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user. It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers. In case anyone is wondering, we do not do any special logging or watching of this hostname. It is logged for a short time on the local hard drive the same as any other DNS query, but unless someone actually looks, we will not notice if you query for it. So feel free to use it for your own purposes as much as you like. We have a bit of spare DNS capacity. :) -- TTFN, patrick
On 2 May 2013 11:12, Patrick W. Gilmore <patrick@ianai.net> wrote:
On May 02, 2013, at 12:12 , Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 12:10, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 11:59, Charles Gucker <cgucker@onesc.net> wrote:
That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using.
Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query.
Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit.
Never mind, I understand now :-)
For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net.
We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user.
It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers.
In case anyone is wondering, we do not do any special logging or watching of this hostname. It is logged for a short time on the local hard drive the same as any other DNS query, but unless someone actually looks, we will not notice if you query for it. So feel free to use it for your own purposes as much as you like. We have a bit of spare DNS capacity. :)
No IPv6 at akamai.net, huh? :p Cns# host whoami.akamai.net whoami.akamai.net has address 216.66.80.30 Cns# host 216.66.80.30 30.80.66.216.in-addr.arpa domain name pointer tserv1.fra1.he.net. Cns# Does anyone run a DNS whoami that's IPv6-ready? C.
On May 02, 2013, at 14:42 , "Constantine A. Murenin" <mureninc@gmail.com> wrote:
On 2 May 2013 11:12, Patrick W. Gilmore <patrick@ianai.net> wrote:
For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net.
We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user.
It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers.
In case anyone is wondering, we do not do any special logging or watching of this hostname. It is logged for a short time on the local hard drive the same as any other DNS query, but unless someone actually looks, we will not notice if you query for it. So feel free to use it for your own purposes as much as you like. We have a bit of spare DNS capacity. :)
No IPv6 at akamai.net, huh? :p
No, sorry. We're working on it. Of course, v6 is available on most other Akamai products. And if someone wants to pay us for v6 on whomai..... :) -- TTFN, patrick
Cns# host whoami.akamai.net whoami.akamai.net has address 216.66.80.30 Cns# host 216.66.80.30 30.80.66.216.in-addr.arpa domain name pointer tserv1.fra1.he.net. Cns#
Does anyone run a DNS whoami that's IPv6-ready?
C.
On Thu, May 2, 2013 at 2:12 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
On May 02, 2013, at 12:12 , Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 12:10, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-02, at 11:59, Charles Gucker <cgucker@onesc.net> wrote:
That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using.
Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query.
Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit.
Never mind, I understand now :-)
For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net.
We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user.
It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers.
'the unicast address of the exit for upstream/cache-fill lookups' .. since the topology behind the anycast node isn't necessarily: internet -> anycast-ip -|host|- unicast-ip ... there could be some networking between |host| and the outside world, or other things going on. anyway... nit-picking-aside, cool that there's a way to figure this sort of thing out :) google has a similar method, which I can't find today :( <darn webcrawler!!!>
On 2013-05-03 4:57 am, Christopher Morrow wrote:
anyway... nit-picking-aside, cool that there's a way to figure this sort of thing out :) google has a similar method, which I can't find today :( <darn webcrawler!!!>
dig -t txt o-o.myaddr.l.google.com
On 2 May 2013 15:41, Cameron Daniel <cdaniel@nurve.com.au> wrote:
On 2013-05-03 4:57 am, Christopher Morrow wrote:
anyway... nit-picking-aside, cool that there's a way to figure this sort of thing out :) google has a similar method, which I can't find today :( <darn webcrawler!!!>
dig -t txt o-o.myaddr.l.google.com
That's cool, but still no IPv6. Cns# dig -t txt o-o.myaddr.l.google.com ; <<>> DiG 9.4.2-P2 <<>> -t txt o-o.myaddr.l.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53188 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;o-o.myaddr.l.google.com. IN TXT ;; ANSWER SECTION: o-o.myaddr.l.google.com. 60 IN TXT "216.66.80.30" ;; Query time: 9 msec ;; SERVER: 2001:470:20::2#53(2001:470:20::2) ;; WHEN: Thu May 2 15:46:22 2013 ;; MSG SIZE rcvd: 66 Cns#
On Thu, 02 May 2013 15:48:08 -0700, "Constantine A. Murenin" said:
On 2 May 2013 15:41, Cameron Daniel <cdaniel@nurve.com.au> wrote:
dig -t txt o-o.myaddr.l.google.com
That's cool, but still no IPv6.
o-o.myaddr.l.google.com. 60 IN TXT "216.66.80.30"
You're complaining that there's no IPv6 data in a *descriptive TXT* record? Man, if that's the biggest IPv6 issue we have, we're on easy street. :)
On Thu, May 2, 2013 at 11:51 AM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Christopher Morrow" <morrowc.lists@gmail.com>
On Thu, May 2, 2013 at 10:32 AM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Perry Lorier" <isomer@gmail.com>
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com <http://gmail.com>" or for "nslookup google.com" to return SERVFAIL
Do you have traceroutes to 8.8.8.8 and 8.8.4.4?
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...
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)
Sure, Chris.
But since Perry's problem is *inability to resolve names in google's
s/perry/blair/
public zones*, the *path to the ZONE servers* is the thing diagnostics would require a trace to, no?
I think, from some troubleshooting with blair yesterday he was having some odd problems with queries to google-public-dns (gdns), where everything he asked came up servfail. I wasn't able to repro this, which was annoying ;( We (perry/others) were interested in verifying that something odd wasn't happening between blair and the server answering his question(s)...
If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it has), then how you get there is irrelevant.
8.8.8.8 is just an open resolver... oh, jabley replied as well (alway a cogent reply from him)
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
It is very courteous to reply a SERVFAIL for requests being rate limited. On Wed, May 1, 2013 at 1:17 PM, Andrew Fried <andrew.fried@gmail.com> wrote:
Your IPs may have been rate limited...
Andy
Andrew Fried andrew.fried@gmail.com
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
On Wed, May 1, 2013 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-01, at 12:09, Blair Trosper <blair.trosper@gmail.com> wrote:
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.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
On Wed, May 1, 2013 at 4:14 PM, Yang Yu <yang.yu.list@gmail.com> wrote:
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 :)
On Wed, May 1, 2013 at 1:17 PM, Andrew Fried <andrew.fried@gmail.com> wrote:
Your IPs may have been rate limited...
Andy
Andrew Fried andrew.fried@gmail.com
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
On Wed, May 1, 2013 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-01, at 12:09, Blair Trosper <blair.trosper@gmail.com>
wrote:
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 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
On May 1, 2013 5:09 PM, "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Wed, May 1, 2013 at 4:14 PM, Yang Yu <yang.yu.list@gmail.com> wrote:
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.
On Wed, May 1, 2013 at 1:17 PM, Andrew Fried <andrew.fried@gmail.com> wrote:
Your IPs may have been rate limited...
Andy
Andrew Fried andrew.fried@gmail.com
On 5/1/13 12:38 PM, Blair Trosper wrote:
That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL
On Wed, May 1, 2013 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-05-01, at 12:09, Blair Trosper <blair.trosper@gmail.com>
wrote:
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 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
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
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 On Wed, May 1, 2013 at 9:09 AM, Blair Trosper <blair.trosper@gmail.com>wrote:
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
participants (20)
-
Andrew Fried -
Blair Trosper -
Cameron Daniel -
Casey Deccio -
Charles Gucker -
Chris Adams -
Christopher Morrow -
Constantine A. Murenin -
Harry Hoffman -
Jared Mauch -
Jay Ashworth -
Joe Abley -
Livingood, Jason -
Patrick W. Gilmore -
Perry Lorier -
Scott Howard -
shawn wilson -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
Yang Yu