EugeneOne1
commented
1 year ago @Ry0OBSSc9H8VjeVE, hello, and apologies for the late response. It actually looks like some queries (answered with NXDOMAIN rcode) aren't intended to be resolved due to security reasons. The thing is that only local clients, i.e. within local networks, should be able to reach the information about other local clients. However, the localhost should be able to resolve those unless the value of private_networks field of the configuration file specified.
By default, this field is empty, which makes AGH use a default RFC 6303 set of locally served networks. Any specified value throws this set, thus to expand the set, all the default networks should be specified first. See the wiki page.
Is the issue still reproducable with latest releases? If so, and the information above isn't appear relevant, could you please collect a verbose log for us? You may send it to devteam@adguard.com.
ghost
All blacklisted domains from custom rules are blocked with 0.0.0.0, as expected, but rule that blocks in-addr reverse DNS results in NXDOMAIN reponse. Why? How to force 0.0.0.0 response for all in-addr queries?
EDIT: Actually, sometimes response is NXDOMAIN and other times its 0.0.0.0. Whenever I use NSLOOKUP to test in-addr addresses, response is the correct one - 0.0.0.0, but during WAN attacks (detected by router's IPS/IDS), AGH shows localhost trying resolve rDNS addresses for selected upsteam DoH servers with NXDOMAIN response. It also happens when I switch ISP gateway from NAT router mode to bridged mode, but AGH is not exposed to WAN, only LAN.
BTW, does AGH have any anti-DDoS measures? DNS reflection attacks are difficult to withstand.