bogus_nxdomain does not block responses when at least one IP address is not listed as bogus

[PussAzuki]

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

• [✔] I am running the latest version
• [✔] I checked the documentation and found no answer
• [✔] I checked to make sure that this issue has not already been filed

Issue Details

It's easy to reproduce.

1. Select a domain name with at least two IP addresses and write down its IP address
2. Add one or more of the above IP addresses to the software that blocks IP access, and confirm that the blocking is successful and at least one IP address can be accessed successfully.
3. Confirm that at least two DNS servers that do not belong to the same provider have been added to the upstream part of the AGH and confirm that AGH uses the fastest IP mode.
4. Attempt to request the above domain name on any host in the network segment monitored by AGH.

Expected Behavior

Only IP that is not blocked in the above operation is returned.

Actual Behavior

As if the above blocking operation is invalid, it is possible to return an unblocked IP address and a blocked IP address.

Additional Information

bug_example
bug_example2

[ameshkov]

Moved it to v0.105.0 since the only that's required is updating dnsproxy to v0.33.5.
Changeset: AdguardTeam/dnsproxy@f0c00d2

[ainar-g]

Should be fixed as of snapshot fd7b061. Can you please check if our solution fixes the issue for you?

[PussAzuki]

2020/12/17 21:24:09 8250#1 [debug] Upstream 0: 192.168.7.1:5353
2020/12/17 21:24:09 8250#1 [info] Starting the DNS proxy server
2020/12/17 21:24:09 8250#1 [info] 1 bogus-nxdomain IP specified
2020/12/17 21:24:09 8250#1 [info] Creating the UDP server socket
2020/12/17 21:24:09 8250#1 [info] Listening to udp://127.0.0.1:53535
2020/12/17 21:24:09 8250#1 [info] Creating a TCP server socket
2020/12/17 21:24:09 8250#1 [info] Listening to tcp://127.0.0.1:53535
2020/12/17 21:24:09 8250#6 [info] Entering the UDP listener loop on 127.0.0.1:53535
2020/12/17 21:24:09 8250#7 [info] Entering the tcp listener loop on 127.0.0.1:53535
2020/12/17 21:24:16 8250#19 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).udpHandlePacket(): Start handling new UDP packet from 127.0.0.1:39241
2020/12/17 21:24:16 8250#19 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 49853
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;avatars0.githubusercontent.com.	IN	 A

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 4096
; COOKIE: 95e58acf3d43b655

2020/12/17 21:24:16 8250#19 [debug] 192.168.7.1:5353: sending request A avatars0.githubusercontent.com.
2020/12/17 21:24:16 8250#19 [debug] 192.168.7.1:5353: response: ok
2020/12/17 21:24:16 8250#19 [debug] github.com/AdguardTeam/dnsproxy/proxy.exchangeWithUpstream(): upstream 192.168.7.1:5353 successfully finished exchange of ;avatars0.githubusercontent.com.	IN	 A. Elapsed 5 ms.
2020/12/17 21:24:16 8250#19 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).Resolve(): Received IP from the bogus-nxdomain list, replacing response
2020/12/17 21:24:16 8250#19 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).Resolve(): RTT: 5 ms
2020/12/17 21:24:16 8250#19 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NXDOMAIN, id: 49853
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;avatars0.githubusercontent.com.	IN	 A

I tested it with the dnsproxy of the master branch, and without the bogus-nxdomain function, it returned full results (including the one with access problems). After that, all the results were gone.

I'm not sure if this is what it should have been.

[ainar-g]

@ameshkov, I'm not quite sure what the verdict here should be. Should we recheck if dnsmasq does the same?

[ameshkov]

@ainar-g I already checked and this is exactly how it works in dnsmasq.

[ainar-g]

@ameshkov, I meant that OP probably wanted AGH to only exclude the blocked IP, and not the whole response (@PussAzuki, can you confirm?). But if you think that what we do now is more correct, then I guess we can close the issue?