* wbr...@e1b.org wrote:
> Any idea how long it takes before the formerly abusable server gets taken
> off the lists of open recursive servers?
About a week. Then the attacks calm down.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
ht
Mark Andrews wrote on 03/06/2013 07:20:58 PM:
> It is still polite. Delegations to servers not configured for a
> zone happen all the time. Go look at the logs of any recursive
> server that reports these.
Any idea how long it takes before the formerly abusable server gets taken
off the list
On Thu, Mar 7, 2013, at 09:29 AM, nudge wrote:
> On Wed, Mar 6, 2013 Vernon Schryver wrote:
> ...
> > I know of no way to use authentication on end user computers except
> > by something like installing a forwarding, caching DNS server on every
> > end user computer.
>
> What would be the effect
On Mar 7, 2013, at 12:02 AM, Joe Abley wrote:
> I don't think this is a necessarily harmful approach.
It isn't harmful - on the contrary, it's beneficial, because it keeps
out-of-bailiwick queries off the nameservers themselves in the first place It
is a BCP.
Thanks Mark, much appreciated!
Roy
On Mar 7, 2013, at 4:28 PM, Mark Andrews wrote:
>
> In message , Roy Arends writes:
>> [1] BIND responds with SERVFAIL to a query where the QNAME is longer than
>> 255 bytes. When all the servers for a domain are BIND, th
>> is often leads to a burst of requ
In message , Roy Arends writes:
> [1] BIND responds with SERVFAIL to a query where the QNAME is longer than 255
> bytes. When all the servers for a domain are BIND, th
> is often leads to a burst of requests, striped over all the authoritative
> servers for that domain. Naturally, a resolver sho
On Mar 7, 2013, at 7:06 AM, Edward Lewis wrote:
>
> On Mar 6, 2013, at 20:33, Paul Vixie wrote:
>> if the authority server in question is configured to be a primary or
>> secondary server for a zone which is at or above the qname, then the correct
>> answer is either authoritative-positive, au
> From: Edward Lewis
> We chose SERVFAIL instead of REFUSED for that - in the sense that the =
> service failed by sending the querier to the wrong place. I don't think =
> either is better than the other, just saying this because it's not =
> always clear what's the right RCODE.
It seems at be
On Mar 6, 2013, at 20:33, Paul Vixie wrote:
> if the authority server in question is configured to be a primary or
> secondary server for a zone which is at or above the qname, then the correct
> answer is either authoritative-positive, authoritative-negative, or servfail.
Or a non-authoritativ
On Wed, Mar 6, 2013 Vernon Schryver wrote:
...
> A few recursive servers such as those at 8.8.8.8 apparently want to
> attract requests from the whole Internet. I agree that most recursive
> servers should know their client bases by IP address or authenticating
> token, but in practice that has pr
Scott Brynen wrote:
> if you're not using the absolute latest bind, you can do a quick and nasty
> using IPTABLES.
likewise ipfw. however, these would be request-based thresholds, which
has an unacceptably high rate of both false positive and false negative.
i strongly recommend against this ap
...
wbr...@e1b.org wrote:
> I mistakenly wrote on 03/06/2013 11:36:20 AM:
>
>> Given that no properly configured server should be querying this
> recursive
>> name server for isc.org,
>
> I meant to describe it as an authoritative server. Duh. I'm having one of
> those days
>
> Sorry for
In message ,
wbr...@e1b.org writes:
> I recently help close down an open recursive resolver. It is still
> getting a lot of queries for isc.org/ANY which get a refused response
> (unless slipped/dropped by RRL). Granted, this doesn't amplify the attack
> since REFUSED is a fairly small packe
On Wed, Mar 6, 2013 at 10:12 AM, Vernon Schryver wrote:
> > From: Casey Deccio
>
>
> > Seems like a REFUSED response fits into its own RRL category. Is there
> any
> > reason why name servers wouldn't simply drop them if they exceed the
> > configured RRL threshold--or even perhaps a lower thre
Joe Abley wrote on 03/06/2013 12:49:22 PM:
> On 2013-03-06, at 12:36, wbr...@e1b.org wrote:
>
> > Is there any reason why recursive queries to an authoritative server
that
> > would normally get a REFUSED reply shouldn't be dropped instead of
getting
> > an answer?
>
> There's no amplificat
> From: Casey Deccio
> On Wed, Mar 6, 2013 at 8:36 AM, wrote:
> > (unless slipped/dropped by RRL). Granted, this doesn't amplify the attack
> > since REFUSED is a fairly small packet, but it is still traffic to the
> > attacked site.
> Seems like a REFUSED response fits into its own RRL categ
if you're not using the absolute latest bind, you can do a quick and nasty
using IPTABLES.
Basically; if you get more than 12 hits in 75 seconds from the same IP, start
dropping them. There are few DNS situations where a client would make that
many requests back to back to back, and even if yo
I mistakenly wrote on 03/06/2013 11:36:20 AM:
> Given that no properly configured server should be querying this
recursive
> name server for isc.org,
I meant to describe it as an authoritative server. Duh. I'm having one of
those days
Sorry for the confusion.
So to rephrase the questio
Jo Rhett wrote on 03/06/2013 12:18:26 PM:
> > I don't see these recursive requests as much different than spam
>
> In the case of DNS requests I agree that dropping requests that are
> improper makes sense. There's no human sitting there wondering why
> they didn't get a response.
So how do
On 2013-03-06, at 12:36, wbr...@e1b.org wrote:
> Is there any reason why recursive queries to an authoritative server that
> would normally get a REFUSED reply shouldn't be dropped instead of getting
> an answer?
>
> Maybe now that I've had lunch the brain will work better.
There's no amplifi
On Mar 6, 2013, at 8:36 AM, wbr...@e1b.org wrote:
> The RFCs state we should either reject during SMTP or if we
> accept a message, we should either deliver or generate a delivery failure.
Yes.
> Now we filter and drop spam on the floor.
So you stopped caring about e-mail delivery, huh? Glad
On 2013-03-06, at 11:36, wbr...@e1b.org wrote:
> I recently help close down an open recursive resolver. It is still
> getting a lot of queries for isc.org/ANY which get a refused response
> (unless slipped/dropped by RRL). Granted, this doesn't amplify the attack
> since REFUSED is a fairly
On Wed, Mar 6, 2013 at 8:36 AM, wrote:
> I recently help close down an open recursive resolver. It is still
> getting a lot of queries for isc.org/ANY which get a refused response
> (unless slipped/dropped by RRL). Granted, this doesn't amplify the attack
> since REFUSED is a fairly small packe
I recently help close down an open recursive resolver. It is still
getting a lot of queries for isc.org/ANY which get a refused response
(unless slipped/dropped by RRL). Granted, this doesn't amplify the attack
since REFUSED is a fairly small packet, but it is still traffic to the
attacked si
24 matches
Mail list logo
