Google Public DNS Problems?

Thu May 2 04:43:33 UTC 2013

On May 1, 2013 5:09 PM, "Christopher Morrow" <morrowc.lists at gmail.com>
wrote:
>
> On Wed, May 1, 2013 at 4:14 PM, Yang Yu <yang.yu.list at 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 at gmail.com>
> > wrote:
> > > Your IPs may have been rate limited...
> > >
> > > Andy
> > >
> > > Andrew Fried
> > > andrew.fried at 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 at hopcount.ca> wrote:
> > >>
> > >>>
> > >>> On 2013-05-01, at 12:09, Blair Trosper <blair.trosper at 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
> > >
> >
> >