[dns-operations] Interesting messages in our logs

[Lyle Giese]

On 11/01/14 12:21, Paul Vixie wrote:
>
>
>> Stephane Bortzmeyer <mailto:bortzmeyer at nic.fr>
>> Saturday, November 01, 2014 8:49 AM
>> On Sat, Nov 01, 2014 at 10:10:07AM -0500,
>>   Lyle Giese<lyle at lcrcomputer.net>  wrote
>>   a message of 23 lines which said:
>>
>>> Interesting error messages.  Someone was running a host name scan
>>> against a domain hosted here and it looks like they were doing it
>>> via Google DNS.
>>
>> It seems also that RRL started and sent SLIP answers, leading Google
>> Public DNS to retry with TCP.
>
Yes, that part is expected behavior.  Why someone is doing a host name 
scan against one of our authoritative domains is a different question.  
Doing it via Google may be a DoS vector they are trying to exploit or 
are they really looking for hostnames in a given domain?(not sure why 
the later would of any interest).

> what we've learned from random-subdomain flood attacks is that the 
> nxdomain limit (in BIND9 that's nxdomains-per-second) and the slip 
> ratio both have to be higher than we thought. at the moment i'm going 
> to say nxdomains-per-second of at least 20, and a slip ratio of 5.
>>> Oct 31 04:10:52 linux1 named[2899]: client
>>> 2607:f8b0:4001:c07::151#61651: no more TCP clients: quota reached
>>
>> If you wish to handle this amount of requests, you can raise
>> the tcp-clients parameter.
>>
>> options { tcp-clients 300; };
>
> there is no number you can insert here, including the largest number 
> your OS can support, such as 2^16, which will make your tcp listener 
> robust in the face of attacks. even if both sides of a non-attack flow 
> (so, client and server) fully implemented the recommendations of 
> <https://tools.ietf.org/html/draft-dickinson-dnsop-5966-bis-00>, 
> intentional tcp state exhaustion will remain a viable attack vector.
>
> -- 
> Paul Vixie
While interesting and I learn from discussions like this, it doesn't 
answer my original question.  When Named goes into SLIP via UDP queries, 
the other party should(and did) retry using TCP.  What happens when we 
throttle via TCP, like above?  Does NAMED just drop the connection? Or 
does it send back a meaningful error message or status of some sort?

Lyle Giese
LCR Computer Services, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141101/914c4fd8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141101/914c4fd8/attachment.jpg>