DNS traffic tracking

Peter Coghlan bind at beyondthepale.ie
Mon May 9 14:54:44 UTC 2022


Alex K wrote:
>On Mon, May 9, 2022 at 2:46 PM Bjørn Mork <bjorn at mork.no> wrote:
>>
>> FWIW I agree with the rate-limit recommendation.  It solves both this
>> and your original problem without any complicated and messy tracking.
>> Just make DNS "free" up to some reasonable query rate.  If there are
>> clients with higher legitimate needs, then you could consider creating
>> separate rate-limit classes for those clients.  And even charge extra
>> for that, if it's important.
>>
> Does such DNS traffic has different characteristics from the normal one?
> Perhaps, apart from limiting, I could block such traffic with the packet
> size or similar.
>

In a different message you said "I see sometime 700MB of DNS traffic for
2GB of Internet browsing within one month."  This seems like a huge figure
and it suggests that something very undesirable is happening somewhere.

If you are counting traffic between your client's resolvers and their
nearest caching nameserver, perhaps adding caching nameservers closer to
or at your client's sites would be helpful?

Maybe someone is attacking your clients with lots of bogus DNS queries?

Maybe some of your clients have been infected with malware and are
attacking the rest of the world with lots of bogus DNS queries?

Someone else suggested your clients could be doing IP over DNS.

Maybe something else we haven't thought of is happening?

Rather than speculating as to what is the cause of this huge figure
for DNS traffic, or trying to generate and analyse logs which may or
may not cover the traffic in question, I would suggest doing some
packet sniffing with tcpdump or wireshark or whatever works in your
environment and figuring out exactly what the traffic is and getting
a better idea of who is responsible for generating it and why.

In my opinion, in the absence of knowing what the problem is,
experimenting with stuff like rate limiting or blocking is unlikely
to solve the problem.

Regards,
Peter Coghlan.


More information about the bind-users mailing list