Fixing Name Resolution Error

A Guide to Local DNS Troubleshooting in Azure

When managing a production environment, infrastructure "resets" can often lead to unexpected downtime. Recently, while managing a Zammad instance on an Azure VM, a domain/SSL reset by the client caused the following critical error in our Python scripts:

HTTPSConnectionPool(host='...', port=443): Max retries exceeded (Caused by NameResolutionError: Failed to resolve 'your-domain.cz')

Here is the step-by-step technical breakdown of how we diagnosed and fixed it.

1. The Symptom: Server "Blindness"

The application was accessible via external browsers, but the server itself couldn't resolve its own domain name.

Diagnostic Command:

Bash

nslookup your-domain.cz

Output:

** server can't find your-domain.cz: NXDOMAIN

This confirmed that the internal Azure Recursive Resolver (168.63.129.16) was missing the DNS record for this host.

---

2. Checking Service Identity

Before fixing the DNS, we verified the server's local IP and ensured the web server (Nginx) was still configured to listen for the correct domain.

Check Internal IP:

Bash

hostname -I
# Output: 10.x.x.x (Internal Private IP)

Verify Nginx Configuration:

Bash

cat /etc/nginx/sites-available/zammad.conf | grep server_name
# Output: server_name your-domain.cz;

---

3. The Fix: Manual Host Mapping

To restore service immediately, we bypassed the faulty DNS resolver by manually mapping the domain to the local IP address in the Linux hosts file.

File Location: /etc/hosts

The Command:

Bash

sudo nano /etc/hosts

The Update:

We added the internal IP and the domain name to the end of the file:

Plaintext

# Local DNS Mapping
10.x.x.x  your-domain.cz

---

4. Final Verification

After saving the file, we performed a two-step verification to ensure both connectivity and SSL integrity were restored.

Step A: Connectivity Test

Bash

ping your-domain.cz

The server now successfully routes traffic to itself (10.x.x.x).

Step B: SSL and API Layer Test

Since certificates were also reset, we ran a verbose curl to ensure the HTTPS handshake was successful.

Bash

curl -vI https://your-domain.cz

Successful Output Indicators:

• SSL certificate verify ok.

• HTTP/2 200 (Success!)

---

Summary of Commands Used

Task	Command
Check DNS	nslookup your-domain.cz
Check Local IP	hostname -I
Edit Host Mapping	sudo nano /etc/hosts
Test Connectivity	ping your-domain.cz
Validate SSL	curl -vI https://your-domain.cz

Conclusion

While the local /etc/hosts update is a valid "hotfix," the permanent solution requires re-adding the A Record in the Azure Private DNS Zone so that the entire Virtual Network (VNet) can resolve the domain without manual intervention.