`server misbehaving` error when running `azd up` under WSL

[aaronpowell]

• [x] Make sure you've installed the latest version using instructions in the wiki

Output from azd version Run azd version and copy and paste the output here:

azd version 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96)

Describe the bug

Running azd up (or other commands) occationally reports server misbehaving from login.microsoftonline.com:

$> azd up --debug
2024/02/01 05:58:15 main.go:54: azd version: 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96)
2024/02/01 05:58:15 main.go:208: using cached latest version: 1.5.1 (expires on: 2024-02-01T23:45:06Z)
2024/02/01 05:58:15 project.go:113: Reading project from file '/workspaces/azure-openai-service-proxy/azure.yaml'
Error: failed to authenticate: server response error:
 Get "https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=https%3A%2F%2Flogin.microsoftonline.com%2Forganizations%2Foauth2%2Fv2.0%2Fauthorize": dial tcp: lookup login.microsoftonline.com on 127.0.0.11:53: server misbehaving

To Reproduce

I can't find a way to force the bug to happen, but when it starts happening it can take minutes to resolve.

Expected behavior

The server to be reported as behaving

Environment Information on your environment: * VS Code Insiders * WSL2 * Devcontainer

Additional context

This is probably more related to WSL than azd, but some better error handling (or error reporting) would help diagnose the root cause.

I tried az account show to see if the Azure CLI was also going to report this error (or similar) but it worked, meaning something in the auth flow for azd is the problem.

[vhvb1989]

From quick bing AI search:

The error message you’re encountering—“dial tcp: lookup login.microsoftonline.com on 127.0.0.11:53: server misbehaving”—indicates a DNS resolution issue. Let’s explore some potential solutions:

DNS Resolution Issues:
The DNS response for login.microsoftonline.com might be too large to fit into the DNS UDP packet. [The original RFC limited the packet size to 512 bytes, and if the response exceeds this, it fails over to using TCP](https://github.com/microsoft/WSL/issues/5991)[1](https://github.com/microsoft/WSL/issues/5991).
[Consider configuring custom DNS settings on your router to serve clients with the correct DNS information](https://github.com/microsoft/WSL/issues/5991)[2](https://techcommunity.microsoft.com/t5/microsoft-365/dns-resolution-issues-when-attempting-to-connect-to-login/td-p/146379).
[Alternatively, you can edit the /etc/resolv.conf file (if you’re using Linux) and change the existing nameserver to a reliable one, such as Google’s (8.8.8.8)](https://github.com/microsoft/WSL/issues/5991)[3](https://stackoverflow.com/questions/33893150/dial-tcp-lookup-xxx-xxx-xxx-xxx-no-such-host).
Network Policies:
Check if there are any network policies or firewalls blocking traffic to login.microsoftonline.com. [Sometimes, network configurations can interfere with DNS resolution](https://stackoverflow.com/questions/67624530/error-response-from-daemon-get-https-azure-v2-dial-tcp-lookup-azure-no-su)[4](https://stackoverflow.com/questions/67624530/error-response-from-daemon-get-https-azure-v2-dial-tcp-lookup-azure-no-su).

@chlowell , have you seen this ever?

@aaronpowell , can you share your devcontainer file? (or mention the linux-distro and version it is running?). Also, confirm if you have some VPN or custom DNS settings.

[chlowell]

I haven't seen this before. I notice the DNS server is on a loopback address, so I would start by investigating what that is exactly and whether it works for other tools. I suggest trying something like nslookup, dig, curl, wget, etc. because az account show may not involve an HTTP request.

[vhvb1989]

@aaronpowell , are you still seeing this?

Did you use client-secrets to login azd? (like azd auth login --client-id xxx --client-secret xxxx --tenant-id xxxx ??

I recently saw this same issue/behavior when using a client-secret and it got resolved by adding double quotes to the login, like: azd auth login --client-id "xxx" --client-secret "xxxx" --tenant-id "xxxx"

[dss010101]

im seeing something similar, but when using terraform with azurerm

[LennartSchmidtKern]

I am seeing something similar when using Ory Kratos' social-sign-in functionality in a dev environment. It relies on Entra ID and calling login.microsoftonline.com from inside a docker container running on WSL.

[vhvb1989]

I havent seen this in a while. I am closing as aged. Feel free to re-open if you see it again