Am 30.11.20 um 11:12 schrieb Marc Roos:
Are newer version of bind still logging like this
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to
3.9.41.0/24
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]:
the source of dns amplification is *always* spoofed because it's by
design the IP of the victim and not the offender
the goal of dns amplification is to flood the connection of the victim
until no regular traffic is possible
the same /24 is sharing the same line and so it doesn't make sense i
You assume incorrectly that every such log entry is from spoofed
traffic.
This is about correct logging. Even if it is spoofed, logging the
correct spoofed address is better than logging a range (that include
ip's that are maybe not even participating)
There is only, but only one advantage
Regardless if the source is spoofed or not, one should log it.
Especially with this amazon abuse cloud, how can you report abuse, they
want to have an ip address to be able to investigate if something
originated from their network.
If you log 0/24 you might as well log no range at all.
Be careful 'rejecting' these outright. These queries are UDP
traffic(not TCP) and the source address is easily forged. RRL is the
correct way to limit these.
Lyle Giese
LCR Computer Services, Inc.
On 11/30/20 4:12 AM, Marc Roos wrote:
Are newer version of bind still logging like this
Are newer version of bind still logging like this
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to
3.9.41.0/24
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses to
Hi,
We've been seeing a huge increase in 'denied queries' against a couple of
Bind servers we look after (Bind 9.16.9) - these are currently logged as:
"
Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN'
denied
"
This appears like it might be someone trying (unsu
7 matches
Mail list logo
