search

TechnitiumSoftware / DnsServer

Technitium DNS Server
https://technitium.com/dns/
GNU General Public License v3.0
4.4k stars 430 forks source link

Locally unavailable upstream problem? #238

Closed Potterli20 closed 3 years ago

Potterli20 commented 3 years ago

Hello, author, I have a problem that dotnet is in the upstream local DNS, some websites cannot access the upstream local DNS, the upstream has the function of DNSSEC, I am confused now. The default on the system is 127.0.0.1 DNS.

ShreyasZare commented 3 years ago

Thanks for the post. Please describe your scenario in more detail like:

Potterli20 commented 3 years ago

Thanks for the post. Please describe your scenario in more detail like:

* are you running the DNS server on your computer or running on a network?

* what OS are you running where you face the issue?

* are you using forwarders in the DNS server? if yes then what are those?

* any other detail? like the error you see etc?

My DNS server is on the cloud server, and the system is Debian. I used the primary DNS for dotnet and the secondary DNS for AdGuardHome. The primary DNS is the local upstream secondary DNS.I use AdGuardHome as the forwarder because it supports the diversion of domain names, such as Google domain name using dns.google, Baidu domain name using dns.alidns.com.

ShreyasZare commented 3 years ago

From your description, it seems you are using Technitium DNS server as primary DNS and AdGuard as secondary DNS. This setup is not going to work well and so you should configure only one of them on your computer and use conditional forwarding as per required. This is because a DNS query will sometimes get resolved from primary DNS and sometimes from secondary DNS so you wont get consistent response that you are expecting.

I would suggest that you use Technitium DNS Server and configure it as primary DNS on your computer/network. Then configure conditional forwarder zones like for Google domains you can configure google DNS and for Baidu use Ali DNS. You can forward all other traffic to AdGuard using the forwarder option in settings.

Potterli20 commented 3 years ago

From your description, it seems you are using Technitium DNS server as primary DNS and AdGuard as secondary DNS. This setup is not going to work well and so you should configure only one of them on your computer and use conditional forwarding as per required. This is because a DNS query will sometimes get resolved from primary DNS and sometimes from secondary DNS so you wont get consistent response that you are expecting.

I would suggest that you use Technitium DNS Server and configure it as primary DNS on your computer/network. Then configure conditional forwarder zones like for Google domains you can configure google DNS and for Baidu use Ali DNS. You can forward all other traffic to AdGuard using the forwarder option in settings.

Some domain names do not have access to Adguard's local DNS, so it is confusing.

ShreyasZare commented 3 years ago

I am not able to clearly understand your setup. Please describe it in more details.

Potterli20 commented 3 years ago

I am not able to clearly understand your setup. Please describe it in more details.

For example, Lanzou.com can't feed back IP address on dotnet, but it can feed back IP address on upstream local DNS. image

ShreyasZare commented 3 years ago

Thanks for the details. Do you have "127.0.0.1:54" set as a forwarder in dotnet?

Do you have any conditional forwarder zone configured?

On Thu, Mar 18, 2021, 21:33 potterli @.***> wrote:

I am not able to clearly understand your setup. Please describe it in more details.

For example, Lanzou.com can't feed back IP address on dotnet, but it can feed back IP address on upstream local DNS. [image: image] https://user-images.githubusercontent.com/28734349/111657302-431d1600-8846-11eb-8dfd-e72a62dcd444.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TechnitiumSoftware/DnsServer/issues/238#issuecomment-802049010, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMLM3FGSEWHCGRSV24WEW3TEIP6NANCNFSM4ZKTLY2Q .

ShreyasZare commented 3 years ago

If possible also post screenshots of your settings here.

Potterli20 commented 3 years ago

Thanks for the details. Do you have "127.0.0.1:54" set as a forwarder in dotnet? Do you have any conditional forwarder zone configured?

I only configured forwarder image

Potterli20 commented 3 years ago

If possible also post screenshots of your settings here.

Error logging 2021-03-18.zip

Potterli20 commented 3 years ago

Thanks for the details. Do you have "127.0.0.1:54" set as a forwarder in dotnet? Do you have any conditional forwarder zone configured?

I only configured forwarder image

image

Potterli20 commented 3 years ago

image

ShreyasZare commented 3 years ago

If possible also post screenshots of your settings here.

Error logging 2021-03-18.zip

Thanks for the error logs. From the error log it looks like the DNS server is trying to forward request to "127.0.0.1:54" but is getting no response. I am not sure of the reason for this. You can try disabling the "QNAME Randomization" option in the settings and see if that makes any difference. This is just in case the adguard DNS resolver running on port 54 may not return correct response for randomized QNAMEs in the query which will case the DNS server to reject those responses.

ShreyasZare commented 3 years ago

image

The response from the other DNS resolver on port 54 looks fabricated/fake primarily because there is a CNAME record at zone apex for google.com zone which is not allowed as per DNS standards.

What ever DNS resolver is running on port 54 is not working as per DNS standards or there is something on your network that is interfering with the DNS query from that resolver.

ShreyasZare commented 3 years ago

I would suggest that you use the built in DNS Client tab and try to query "127.0.0.1:54" and see if you get any response. You can also try using other DNS-over-HTTPS servers in the list there and see any of that works.

If you find some server working on DNS Client then you can use that server as a forwarder.

Potterli20 commented 3 years ago

Thanks for the error logs. From the error log it looks like the DNS server is trying to forward request to "127.0.0.1:54" but is getting no response. I am not sure of the reason for this. You can try disabling the "QNAME Randomization" option in the settings and see if that makes any difference. This is just in case the adguard DNS resolver running on port 54 may not return correct response for randomized QNAMEs in the query which will case the DNS server to reject those responses.

The "QName Randomization" option has been disabled in Settings, but it still doesn't work

Potterli20 commented 3 years ago

image

The response from the other DNS resolver on port 54 looks fabricated/fake primarily because there is a CNAME record at zone apex for google.com zone which is not allowed as per DNS standards.

What ever DNS resolver is running on port 54 is not working as per DNS standards or there is something on your network that is interfering with the DNS query from that resolver.

I did it on purpose, lol, but every other site has the same problem, the log I showed you is upstream, local 54, it's the same problem

Potterli20 commented 3 years ago

I would suggest that you use the built in DNS Client tab and try to query "127.0.0.1:54" and see if you get any response. You can also try using other DNS-over-HTTPS servers in the list there and see any of that works.

If you find some server working on DNS Client then you can use that server as a forwarder.

图片 图片

ShreyasZare commented 3 years ago

I am not exactly sure why its not working in your setup. I would recommend that you use the DNS Client tab to find out what upstream servers you are able to query. If you are able to get a response in DNS Client then it would mean that the DNS server can use it as forwarder. So, before you configure any forwarder or conditional forwarder, just make sure the upstream is reachable using DNS Client tool on the web console. If the upstream is not responding to DNS Client queries then it wont work if you try to use it as forwarder or conditional forwarder.

ShreyasZare commented 3 years ago

Additionally, if you know how to use tcpdump, then do try to capture traffic on your loopback adapter. Once you have tcpdump running to capture packets in a pcap file, try to query "127.0.0.1:54" from DNS Client tab in web console. Stop the capture and see the pcap file in Wireshark. This will make the issue clear and you will know exactly what is going wrong. If you find it hard to analyze the pcap file then you can send it over to me to find out the issue.

Potterli20 commented 3 years ago

Additionally, if you know how to use tcpdump, then do try to capture traffic on your loopback adapter. Once you have tcpdump running to capture packets in a pcap file, try to query "127.0.0.1:54" from DNS Client tab in web console. Stop the capture and see the pcap file in Wireshark. This will make the issue clear and you will know exactly what is going wrong. If you find it hard to analyze the pcap file then you can send it over to me to find out the issue.

ok

Potterli20 commented 3 years ago

Additionally, if you know how to use tcpdump, then do try to capture traffic on your loopback adapter. Once you have tcpdump running to capture packets in a pcap file, try to query "127.0.0.1:54" from DNS Client tab in web console. Stop the capture and see the pcap file in Wireshark. This will make the issue clear and you will know exactly what is going wrong. If you find it hard to analyze the pcap file then you can send it over to me to find out the issue.

dns.trli.club/log.zip

ShreyasZare commented 3 years ago

Additionally, if you know how to use tcpdump, then do try to capture traffic on your loopback adapter. Once you have tcpdump running to capture packets in a pcap file, try to query "127.0.0.1:54" from DNS Client tab in web console. Stop the capture and see the pcap file in Wireshark. This will make the issue clear and you will know exactly what is going wrong. If you find it hard to analyze the pcap file then you can send it over to me to find out the issue.

dns.trli.club/log.zip

Getting error on the URL:

 Error 522 Ray ID: 632d64e66e96de42 • 2021-03-20 07:58:14 UTC
Connection timed out

Attach the file here itself or send it as email.

ShreyasZare commented 3 years ago

Ok it tried it and got the file downloaded. The pcap capture file does not contain the local traffic for 127.0.0.1. All I see is your live traffic.

To debug the issue of "127.0.0.1:54" not working as forwarder, you need to use tcpdump to capture on loopback interface and not your ethernet interface.

Potterli20 commented 3 years ago

Ok it tried it and got the file downloaded. The pcap capture file does not contain the local traffic for 127.0.0.1. All I see is your live traffic.

To debug the issue of "127.0.0.1:54" not working as forwarder, you need to use tcpdump to capture on loopback interface and not your ethernet interface.

http://dns.trli.club/log.pcap

ShreyasZare commented 3 years ago

Ok it tried it and got the file downloaded. The pcap capture file does not contain the local traffic for 127.0.0.1. All I see is your live traffic. To debug the issue of "127.0.0.1:54" not working as forwarder, you need to use tcpdump to capture on loopback interface and not your ethernet interface.

http://dns.trli.club/log.pcap

I checked this new pcap logs and it all looks good. When I apply dns.flags.rcode==2 filter for server failure, i am seeing 7 failure responses that are coming from the upstream running on "127.0.0.1:54". This pcap file contains no DNS request/response which has the issue you are describing in this post. In fact, there is json output of the DNS server dashboard too in the pcap and it showing good stats with very limited/resonable server failures.

You need to make sure that the issue you are describing in this post gets captures in pcap file. When you start tcpdump capture on loopback, you need to make queries using DNS Client tab that you are describing here. When you get server failure response in DNS Client, the DNS data that is captured in pcap will give details on why there was server failure response. You can also use the dig command like you did above which capturing pcap file so that the data is available on the issue you are describing for analysis.

Potterli20 commented 3 years ago

dns.flags.rcode==2

so?-wuwuwu......

Potterli20 commented 3 years ago

this? log (2).zip

ShreyasZare commented 3 years ago

Thanks for the log. I tried to find out the Server Failure responses in this log and all such responses are coming from your upstream DNS server that you are running on port 54. Just have a look at this screenshot:

image

It seems that the upstream DNS server that you are using is giving Server Failure responses and also not responding quickly causing timeout errors in the Technitium DNS Server logs.

ShreyasZare commented 3 years ago

image

What probably happening here is that Technitium DNS Server is not getting response from the upstream quick enough and it will send a Server Failure response after 4 seconds elapses for your dig request. Now when you query your upstream using dig again, the upstream DNS has managed to get the domain resolved so its responding to your second dig command.

I would suggest that you can test this by first querying using dig to your upstream server running on 127.0.0.1:54 and then query to 127.0.0.1:53. Once your upstream returns the answer, the Technitium DNS server too should return the answer. Make sure to clear cache once for both the DNS servers once before doing this test.

Potterli20 commented 3 years ago

image

What probably happening here is that Technitium DNS Server is not getting response from the upstream quick enough and it will send a Server Failure response after 4 seconds elapses for your request. Now when you query your upstream using again, the upstream DNS has managed to get the domain resolved so its responding to your second command.dig``dig``dig

I would suggest that you can test this by first querying using to your upstream server running on and then query to . Once your upstream returns the answer, the Technitium DNS server too should return the answer. Make sure to clear cache once for both the DNS servers once before doing this test.dig``127.0.0.1:54``127.0.0.1:53

It's actually forbidden on the server, but it's cached, and I don't know why. I just have to respond.

ShreyasZare commented 3 years ago

It's actually forbidden on the server, but it's cached, and I don't know why. I just have to respond.

I didn't get it. What is forbidden? and what is cached?

Potterli20 commented 3 years ago

image No DNS cache on

Potterli20 commented 3 years ago

image Here we go again. Woo-hoo.

Potterli20 commented 3 years ago

image

ShreyasZare commented 3 years ago

Here we go again. Woo-hoo.

You are not trying to understand the test that I told you do. You tested for the domain baidu.com for which you got conditional forwarder setup that points to 2 other DoH setup.

You are querying to your local adguard DNS running on port 54 which responds and then you query to Technitium DNS which gives Server Failure since those 2 DoH conditional forwarders didnt respond in time.

The purpose of the test I told you is defeated by this. For this test to have any meaning, you need to remove the conditional forwarder zone and then do the test again so that Technitium DNS uses your adguard DNS as upstream.

Getting server failure response is not a bug. It just means that the server could not get the domain resolved in 4 sec timeout that is configured internally.

If you see an error in logs other than errors like connection timeout then that could be an bug. But the thing you are reporting is mostly network issues and not a bug.

ShreyasZare commented 3 years ago

Closing the issue since no bug was diagnosed.