Protection against PTR Requests (Private reverse DNS resolving) flood/loop
#6,693 创建于 2024年1月31日
描述
Prerequisites
-
I have checked the Wiki and Discussions and found no answer
-
I have searched other issues and found no duplicates
-
I want to request a feature or enhancement and not ask a question
The problem
When AGH instance points to Private reverse DNS resolver and the said resolver is using AGH as upstream (e.g. main router, or some coredns, docker resolver or other service) it often happens that the private client IP is not reverse resolvable (e.g. after client changes IP, the router no longer has information about that IP, or docker container changes IP and adguard home is restarted at that time or else) it happens that the Private reverse DNS resolver forwards the unresolvable PTR request from AGH back to AGH, which creates infinite loop and thus essentially DDOS-like attack internally.
I've replicated this successfully several times, my exact setup is as follows: AGH -> coredns_omada (omada clients IPs) -> docker 127.0.0.11 (docker containers IPs) -> AGH
But it should be easily reproducible on similar setup: AGH -> router -> AGH
Then simply do nslookup <nonexistent private IP> <IP of AGH> to create loop and flood of:
2024/01/31 21:40:02.567621 [error] dnsproxy: upstream 127.0.0.1:5053 failed to exchange ;22.0.20.172.in-addr.arpa. IN PTR in 2.004519601s: exchanging with 127.0.0.1:5053 over udp: read udp 127.0.0.1:45093->127.0.0.1:5053: i/o timeout
When client IP is resolvable, there is no problem, both internal network as well as docker containers client IPs are successfully resolved.
Adding *20.172.in-addr.arpa to disallowed domains resolves this loop problem of course.
Proposed solution
Not really sure how to tackle this, open to ideas. Of course the very ideal scenario would be that the Private DNS resolver uses different upstream than AGH, but thats sometimes not possible, e.g. when you set AGH as upstream in some routers, because you want your whole network using AGH.