DNS server mixes AUTHORITY/ADDITIONAL section into ANSWER section while responding to queries #5806
Comments
Neurone
changed the title
Neurone
changed the title
|
Thanks for the detailed report. I can't repro here, but I am pretty sure that's only because my ISP isn't coughing up any AUTHORITY/ADDITIONAL upstream. Please collect logs and backlink the feedback item. Your analysis looks awfully sound on its own merits, but having traces for the devs to look at is better than not. |
|
Sure. I updated the issue adding a query to an authoritative DNS - so you can see by your own even if your ISP does not act like mine - and I added the link to the feedback item. I also updated the new IP of the resolver (now 192.168.16.1) to reflect the recording of the feeedback. |
|
This happens for me too. Any fix in the works? This gets in the way of DNS administration. This happens for zones that are authoritative for your upstream DNS server. I see it on VPN for the office, but not when I'm not on VPN. |
|
This is still happening with build 10.0.19042.610. Really surprised to see so few people affected by this. The "ADDITIONAL SECTION" is added to the "ANSWER SECTION". This makes things really bad when you are managing thousands of targets with Ansible... |
|
I am affected by this issue as well. |
You should be able to reproduce this by pointing your windows DNS server(s) to servers that are authoritative for something instead of to your default ISP servers or public servers like google. I don't know of any public servers off hand that are both authoritative AND allow recursive lookups. This, however, is common for corporate DNS servers when on VPN connections. Often the company DNS servers handle internal non-routable names for the company domain as well as recursing requests for external domains. |
|
I have this issue as well! It commonly affects Terraform. When doing a packet capture, I can see the NS records for the lookup of registry.terraform.io being returned in the answer section. Then I see terraform making its request for the url using a NS record IP and not the actual site IP because the NS records were returned incorrectly. Please help! Here is the DNS response coming into my PC: Here is the DNS response coming into my WSL: |
|
Thank you guys all, I've tested on Hyper-V, and I also encountered this problem. I doubt this is problem with the Hyper-V's DNS server. Should anyone with WSL 1 test if this problem exists?
/cc @therealkenc |
Quick update: our university's DNS provides |
|
The issue does not appear to affect WSLv1. |
|
It did affect me back when I was running WSLv1. I've not been running v1 for a while now. The issue only happens if the upstream DNS server is providing authoritative/additional records. In this case the ADDITIONAL records are merged in to the reply, but I don't see any AUTHORITY records getting merged. Why is this taking so long to fix? This is obvious incorrect behavior. Is the source the the DNS proxy available so we can submit a patch? |
|
I agree, it definitely seems like something significant enough that it
should not still be dragging on after this long.
|
|
This is causing an issue with terraform in WSL2. Can you please fix this? |
|
More and more programs used in WSL2 stop working - Helm and Terraform, just to name a few. Can somebody take this bug seriously? |
|
As a quick workaround, use cloudflare or similar resolver. Modify For VPN or private zones, use appropriate DNS server. |
|
👍 to fix this, it is breaking Terraform usage on WSL2. |
|
This looks like it's an issue with the Hyper-V DNS resolver. Has this been reported to the Hyper-V team? I see similar behavior in other Hyper-V VMs. |
|
Affected too |
|
I've solved all issues regarding DNS and VPN using this tool: https://github.com/sakai135/wsl-vpnkit |
|
Affected too |
|
I have posted this issue in the Windows Feedback hub under Hyper-V, so make sure to upvote it: https://aka.ms/AAlwtcs (in the hope it helps). |
|
Confirmed to be an issue on my end, all DNS queries include root servers: |
|
How can something this fundamental still be an issue three years after it was first reported. Every other OS, even Vista, managed to do DNS correctly. |
Usually this is because the relevant code once belonged to an entirely different product team, which likely has been long disbanded, and as a result that code has become orphaned. Don't forget that some of that code base (Internet Connection Sharing?) is probably more than a quarter century old, and never was intended to serve DNS to a modern Linux environment via WSL. This DNS server/proxy functionality also seems entirely undocumented, so even finding it will be a challenge. Windows NT has lots of "skeletons in the closest", and the code behind this issue is probably one of those. I suggest the best way forward is to find an experienced code archeologist and start decompiling, as even the source code may have been lost. If you think I'm joking: https://arstechnica.com/gadgets/2017/11/microsoft-patches-equation-editor-flaw-without-fixing-the-source-code/ |
|
I'd suggest that this is a bigger issue than Microsoft will give credit for. It essentially makes it impossible to use DNS reliably in some environments, such as the case where a DNS proxy will forward some requests to Azure to take advantage of Azure private DNS. WSL simply cannot resolve some of these private hostnames because of this bug. |
|
This is a Hyper-V issue. Spin up an Hyper-V virtual machine and you will see the exact same bug. |
|
@mgkuhn even given all that, the fact it breaks so much stuff means there should be some priority on getting it fixed, even if it means rebuilding that library from scratch. Three years should be enough to get something done. |
And now test it on a separate Linux box connected to the Internet via Windows' "Internet Connection Sharing", all the way back to Windows 98 SE. Hyper-V may be just another environment affected, not the actual location of that DNS code. |
|
Will the newly announced dnsTunneling option help to circumvent the problem? |
|
Please try enabling "dnsTunneling" and let us know if it fixes the issue. thanks! |
|
It looks like dnsTunneling (I've combined this with the new mirrored networking mode as well) works like a charm 👍🏻 |
|
Is there a write up on how to do this somewhere? |
|
Well yes, its in this link as posted by @mgkuhn:
Just make sure to have the latest win11 22H2 feature updates (released yesterday, KB5030310) installed. |
|
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request. Thank you! |
|
I can't believe this is finally fixed, thanks. |
|
I was sceptical as the last message says the issue has been closed due to inactivity, not due to it actually being fixed, but I've just checked and it does appear to have been fixed. Four years and one day to get DNS working correctly, that is impressively bad going. |
|
I am actually not sure anymore, I still see issues on my end ... Tempted to re-open. |
|
@digininja What version of windows/wsl are you running? |
|
@jrabasco The box I checked on is Win 11 Home on 23H2 with WSL version 2.2.4.0. |
|
@jrabasco This was simply closed due to inactivity, nothing's been fixed. There's maybe a workaround with dns tunneling. |
|
On Thu, 26 Sep 2024, Jérémy Rabasco wrote:
I am actually not sure anymore, I still see issues on my end ... Tempted to re-open.
I cannot test it, I’ve not got access to a recent Windows system
any more, it was only for a test project, at work.
|
|
@sknolin I've not got DNS tunnelling setup and it is working for me. My original work around was just to run a script that changed I agree there has been no official fix mentioned, but something has changed that has got it working for me. I imagine that if someone did do an official fix they would be on here shouting about it which suggests it may be accidental. |
|
The dnsTunneling option was enabled by default in March 2024 in https://github.com/microsoft/WSL/releases/tag/2.2.1 |
|
This is still an issue. Please reopen. Please open an issue with whoever owns the DNS forwarder in Hyper-V and respond with a link to that issue here. |
and others
Environment
Steps to reproduce
Query the
TXTrecord of a domain, for example:Please note that DNS server
192.168.16.1comes from the Hyper-V Virtual Network Adapter and it is dynamically and automatically configured by WSL/ICS/Windows, so the exact DNS server's IP changes every time Windows restarts.Here the link to the collected log and feedback item: https://aka.ms/AA9dnzo
Expected behavior
Correct DNS response like the examples below, where the
ANSWERsection contains only theANSWERsection and not also some info from theAUTHORITY/ADDITIONALsections.The following query is done using the current authoritative DNS server for ultradns.com
The following query is done using my ISP's DNS.
The following query is done using Google's public DNS server.
Actual behavior
Info from the
AUTHORITY/ADDITIONALsections are mixed in theANSWERsection: this behaviour currently creates issues to other programs that need to process the answer.For example, in this issue geth cannot unmarshal the DNS message because it's greater then 512 bytes.
Geth is written in go, and go DNS client follows the RFC 1035 specification. This specification states that via UDP the maximum allowed message size is 512 bytes.
The program works fine with all other DNS servers because
ANSWERconfigured in the DNS server is correctly less then 512 bytes, but it fails with WSL that - with the addition of other information - creates anANSWERsection too big.This strange behavior potentially impacts every RFC 1035 compliant library, and at least it impatcs every program written in go-lang and that uses the native DNS client library.
As a final note, I don't know if it is related to the same problem or if it can provide some clues, you can also notice a warning message appearing at the beginning of the DNS response:
;; WARNING: recursion requested but not availableThe text was updated successfully, but these errors were encountered: