In message <fb979b33-df83-4460-a3e4-040cd165e...@newgeo.com>, Scott Haneda writ
es:
> On Jan 20, 2009, at 5:44 PM, Mark Andrews wrote:
>
> > In message <232b45f8-acd3-427a-95e9-bc3ca5fc9...@newgeo.com>, Scott
> > Haneda writ
> > es:
> >> Hello, looking at my logs today, I am getting hammered with these:
> >> 20-Jan-2009 15:39:06.284 security: info: client 66.230.160.1#48517:
> >> query (cache) './NS/IN' denied
> >> 20-Jan-2009 15:39:06.790 security: info: client 66.230.128.15#31593:
> >> query (cache) './NS/IN' denied
> >>
> >> Repeated over and over, how do I tell what they are, and if they are
> >> bad, what is the best way to block them?
> >> --
> >> Scott
> >
> > You should talk to your ISP to chase the traffic back to
> > its source and get BCP 38 implemented there. BCP 38 is ~10
> > years old now. There is no excuse for not filtering spoofed
> > traffic.
> >
> > If the source doesn't want to implement BCP 38 then de-peering
> > the source should be considered.
>
>
> Is BCP 38 really as solid and plug and play as it sounds? In a
> shared, or colo'd environment, can that ISP really deploy something
> like this, without it causing trouble for those that assume unfettered
> inbound and outbound traffic to their servers?
Yes it is. Everyone in a colo should be able to tell you which
source address (prefixes) they should be emitting. You filter
everything else.
The closer to the edge that you do this the easier it is to do.
Mark
> --
> Scott
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
