Leen Besselink wrote:
Christof Meerwald wrote:
Hi,

since about Friday late evening I am seeing lots of pdns errors in my syslog
like:

  Not authoritative for '', sending servfail to 76.9.31.42 (recursion was
  desired)

Over in comp.protocols.dns.bind there is already some discussion about these
DNS requests (which apparently use a spoofed source IP address).

Is there anything a DNS server/PowerDNS can do to avoid being used as a DDoS reflector, like rate-limiting SERVFAILs per IP address? What's the general
opinion?


The idea of the DOS-attack is to try and get the authoritive or public recursive nameserver to send a larger amount of packets or size then the original request. PowerDNS (atleast the installations I checked) doesn't
do that, it just sends a ServFail of the pretty much the same size.

Other then dropping the packet with a firewall-rule as I have (that IP-address specifically, I actually will remove it after it has stopped !) I don't think there is a lot you could do. Maybe someone could implement some kind of rules in PowerDNS to, again not answer this
query specifically. But well, that would just be wrong and make it
easier to make a DNS cache poisoning attack at some recursor more effective.

Only other thing I can think about is, that maybe a rate limiter
could be kinda useful.

As I've mentioned in other fora, people should just filter their
egress traffic from spoofed addresses, that would get rid of the
whole problem.


Maybe there is a way to find the badguys, because I did notice one
thing, the TTL is pretty much always the same and they are all arriving from the same Transit-provider. So that means it's probably just a very small number of badguys, fairly close together.

The TTL I have here is 56 or 57:

# tcpdump -c 10 -vvntpi XXX host 76.9.31.42
tcpdump: listening on XXX, link-type XXX
76.9.31.42.39499 > XXX.XXX.XX.XXX.53: [udp sum ok] 47478+ NS? . (17) (ttl 57, id 28226, len 45) 76.9.31.42.35973 > XXX.XXX.XX.XXX.53: [udp sum ok] 31418+ NS? . (17) (ttl 56, id 40252, len 45) 76.9.31.42.10658 > XXX.XXX.XX.XXX.53: [udp sum ok] 47176+ NS? . (17) (ttl 56, id 23872, len 45) 76.9.31.42.41104 > XXX.XXX.XX.XXX.53: [udp sum ok] 20777+ NS? . (17) (ttl 57, id 6198, len 45) 76.9.31.42.25856 > XXX.XXX.XX.XXX.53: [udp sum ok] 12812+ NS? . (17) (ttl 57, id 32978, len 45) 76.9.31.42.61992 > XXX.XXX.XX.XXX.53: [udp sum ok] 8502+ NS? . (17) (ttl 56, id 7053, len 45) 76.9.31.42.28488 > XXX.XXX.XX.XXX.53: [udp sum ok] 64677+ NS? . (17) (ttl 56, id 38187, len 45) 76.9.31.42.32527 > XXX.XXX.XX.XXX.53: [udp sum ok] 49277+ NS? . (17) (ttl 56, id 59157, len 45) 76.9.31.42.25435 > XXX.XXX.XX.XXX.53: [udp sum ok] 719+ NS? . (17) (ttl 56, id 27208, len 45) 76.9.31.42.3991 > XXX.XXX.XX.XXX.53: [udp sum ok] 14463+ NS? . (17) (ttl 57, id 12013, len 45)

The Transit provider in my case is AboveNet.

If people with a higher TTL would give some information where they think it's arriving from maybe we would be able to find pinpoint them.


Christof


_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users

Reply via email to