AdGuardHome icon indicating copy to clipboard operation
AdGuardHome copied to clipboard

Adguard Home doing DNS queries to devices

Open lordraiden opened this issue 2 years ago • 7 comments

Prerequisites

  • [X] I have checked the Wiki and Discussions and found no answer

  • [X] I have searched other issues and found no duplicates

  • [X] I want to report a bug and not ask a question

Operating system type

Linux, Other (please mention the version in the description)

CPU architecture

x86

Installation

Docker

Setup

On one machine

AdGuard Home version

0.107.8

Description

10.10.40.5 is the adguard IP, 10.10.10.0/24 is a network with devices that query adguard home

imagen

For some reason I don't understand adguard home is making DNS request (53) to clients (pc, smartphones, etc.)

Is this legit? what am I exactly blocking? what is the purpose of this traffic?

lordraiden avatar Aug 03 '22 12:08 lordraiden

It looks your firewall is blocking DNS responses from AdGuardHome to your devices. It should not. What firewall rule is hit?

amend: it's right in front of me ^^: "DMZ to LOCAL". Yeah, are you sure your want your local DNS in the DMZ?

yscialom avatar Aug 03 '22 13:08 yscialom

It looks your firewall is blocking DNS responses from AdGuardHome to your devices. It should not. What firewall rule is hit?

amend: it's right in front of me ^^: "DMZ to LOCAL". Yeah, are you sure your want your local DNS in the DMZ?

The DNS isn't actually in a DMZ despite the name

The clients should do DNS request to Adguard and not the other way around, so my question is why there is DNS traffic being originated in Adguard home towards the clients?

lordraiden avatar Aug 03 '22 15:08 lordraiden

Looks normal to me. I see IP 10.10.40.5 is sending over UDP from port 53 to the clients. The UDP scheme, unlike TCP, doesn't work with connections. The client sends a request message to the server at port 53 and doesn't wait for a response. When the server has processed the request it will send back a DNS response to the client, separate from the initial request.

Client:37611 -> Server:53 -> datagram -> END
[Server processing request]
Server:53 -> Client:37611 -> datagram -> END

If it were over TCP you would see clients connecting to the server, maintain the connection while receiving the response, and finally disconnect. It would all happen in one data pipe. For UDP there can be multiple pipes to send a message across.

fvdm avatar Aug 03 '22 15:08 fvdm

Looks normal to me. I see IP 10.10.40.5 is sending over UDP from port 53 to the clients. The UDP scheme, unlike TCP, doesn't work with connections. The client sends a request message to the server at port 53 and doesn't wait for a response. When the server has processed the request it will send back a DNS response to the client, separate from the initial request.

Client:37611 -> Server:53 -> datagram -> END
[Server processing request]
Server:53 -> Client:37611 -> datagram -> END

If it were over TCP you would see clients connecting to the server, maintain the connection while receiving the response, and finally disconnect. It would all happen in one data pipe. For UDP there can be multiple pipes to send a message across.

I understand but I have had my firewall in this way for months and DNS resolutions has been working fine, what you say could make sense but for example in any normal house if I configure a Client (PC) to use directly 1.1.1.1 I will be sending DNS requests over UDP (53) to 1.1.1.1 and 1.1.1.1 will never be able to initiate the connection to reach my client because the port would be closed in the router.

lordraiden avatar Aug 03 '22 16:08 lordraiden

Your router takes care of that with address translation.

https://networkengineering.stackexchange.com/a/62767

fvdm avatar Aug 03 '22 16:08 fvdm

Your router takes care of that with address translation.

https://networkengineering.stackexchange.com/a/62767

ok, so why it still works while it's blocked?

lordraiden avatar Aug 03 '22 17:08 lordraiden

I don't now. The screenshot looks like Sophos firewall? You may get better answers at their forums.

fvdm avatar Aug 03 '22 18:08 fvdm