Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Force DNS Redirection #1111

Closed
3 tasks done
ghost opened this issue Oct 23, 2019 · 9 comments
Closed
3 tasks done

Force DNS Redirection #1111

ghost opened this issue Oct 23, 2019 · 9 comments
Labels
question

Comments

@ghost
Copy link

ghost commented Oct 23, 2019

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

Problem Description

I have an ISP-issued modem/router that provides the internet connection (Router 1). Behind it I have my Wifi router providing the actual connectivity to all other devices (Router 2). I am forcing all dns queries to my AdguardHome server (Raspberry Pi 3B+) by setting the IP address of the AdguardHome server as the sole static DNS address in Router 2 and tick "Force DNS Redirect" (in DD-WRT firmware) to make sure everything runs via Adguard. So far so good.

The problem is that the ISP modem/router is apparently forcing any DNS request to whatever is set in that modem (Router 1), and it is not possible to enable DoH or DoT on that device. Whatever I set as upstream DNS servers in AdguardHome is completely ignored. Thus, although I have Cloudflare's DoH or DoT set as upstream DNS servers in AdguatdHome I can clearly detect that these aren't used. I checked with https://1.1.1.1/help and https://www.cloudflare.com/ssl/encrypted-sni/

Proposed Solution

I am not sure if this is at all possible but an elegant solution to this problem would be if you could add a feature similar to DD-WRT firmware that forces any DNS requests that reach AdguardHome and are not filtered to exclusively be redirected to whatever is set in AdguardHome. Also, I am pretty sure that I am not the only one having a similar issue as most of us don't own there internet connection I would assume.

Alternatives Considered

Additional Information
@ameshkov
Copy link
Member

Thus, although I have Cloudflare's DoH or DoT set as upstream DNS servers in AdguatdHome I can clearly detect that these aren't used.

I don't understand how a router can mess with DoH/DoT.

Are you sure AdGuard Home is really used by the device you're using to test this?
Do you see these DNS queries in the AdGuard Home log?

@ghost
Copy link
Author

ghost commented Oct 23, 2019 via email

@ghost
Copy link
Author

ghost commented Oct 23, 2019 via email

@ameshkov
Copy link
Member

Let's see what's in AG Home logs then.

  1. Configure AdGuard Home to collect logs:
    • Specify log_file
    • Set verbose to True
  2. Restart AdGuard Home and reproduce the issue
  3. Post the log file here.

@ghost
Copy link
Author

ghost commented Oct 24, 2019 via email •
edited by ameshkov
Loading

@phixion
Copy link

phixion commented Oct 30, 2019

you can only redirect outbound dns traffic on your router, no dns resolver can handle that. You suspect your ISP intercepting DNS on router1 so on router2 everything should be okay -> validate that with logs/tcpdump also validate your dns redirect on router2 by manually setting a client's dns to a random external one and do some lookups they should be redirected to adguard. Your redirect rules must not include the adguard's addresses.

whats the output of on adguard/client/router of:

  • curl -H 'accept: application/dns-message' -v 'https://cloudflare-dns.com/dns-query?dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | hexdump

  • nslookup -d2 google.com (windows client)

  • dig google.com (linux client)

  • https://1.1.1.1/help

  • your adguard config

sample tcpdump for router2 validation eth0 being the lan facing interface
tcpdump -i eth0 -n udp port 53 or tcp port 53

@ghost
Copy link
Author

ghost commented Nov 5, 2019 via email

@ameshkov ameshkov closed this as completed Nov 7, 2019
@phixion
Copy link

phixion commented Nov 8, 2019

glad it works, I'm not a fan of bloating issuetrackers with opinions but I'll play devils advocate for a bit:

A few things to think about with using 3rd party vpn and DoH upstreams, none of of those magically give you "more security" in fact you achieve the opposite (less security) by handing your traffic and/or name resolution to an additional party, which are most of the time profit-orientated busineses and you entirely rely on their claims and security. without esni in larger scale DoH brings little to no benefit as your isp would still see your connect to the IP address. Well, you rule out everyone listening on the wire at least, so theres something.

i guess in most cases running a local resolver and using your isps upstream dns is probably faster (in numbers, I dont think a human can distinguish between a lets say 17ms and a 54ms dns query) and leaves out other people entirly, which means no loss of security.

@ameshkov
Copy link
Member

ameshkov commented Nov 8, 2019

without esni in larger scale DoH brings little to no benefit as your isp would still see your connect to the IP address

ESNI by itself is quite a problematic standard (at least in its current state) pushed by a few CDNs.

@GTVolk GTVolk mentioned this issue Nov 5, 2022
Open
@GTVolk GTVolk mentioned this issue Dec 25, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ameshkov @phixion