DNS Name Resolving

Name resolution problem in private and public DNS zones (applies not only to the Azure cloud)

Azure Name Resolving

Problem Description:

When you add a new Azure service (such as Azure Container Registry) with a private access type, all nodes in your cloud network either stop resolving other private DNS zones (if they exist) or are unable to resolve names in the newly created private DNS zone and cannot connect. to a newly added service (for example, Azure Container Registry).

In more detail the problem looks like this:
When adding a new Azure Service (for example Azure Container registry), we must specify the network access type for the service:
- Public Access. In this case, access to the service will be performed through the Public IP address and Public network. Of course, we can limit access to our repository by specifying the allowed IP addresses of clients and their accounts, but the traffic will pass through all public networks, and this is not always permissible for security reasons;
- Private Access. In this case, access to the service will be performed only through the internal Microsoft network, which is more secure for our network. In this case, we must create a Private Endpoint for our service and publish its Private IP address in the Private DNS zone.

Then the last part of the task remains: connecting this Private DNS zone to the client’s network settings so that it can resolve both public and private DNS names.

Connecting Private DNS zones to the client’s network settings

To add another DNS resolver to the client’s settings, we can add it to the Virtual Network/DNS Servers settings where our client is hosted. When adding a new server to the existing list of DNS servers, we must remember that in this case the order of the servers matters. And this is a very important issue for our discussion — the name resolving procedure on the client side.

The procedure for performing Name Resolving on the client side:

1. The client sends a domain name resolution request to the first DNS-resolver server in its DNS-resolvers list.
2. The first DNS server checks its local cache to see if it has a current entry for that domain.
3. If there is no current entry in the cache, the server contacts authoritative DNS servers for this domain zone.
4. An authoritative DNS server checks its database. If the domain name is not found, the server returns an NXDOMAIN (non-existent domain) response.
5. The primary DNS server receives a response with the address of the requested name, or NXDOMAIN (non-existent domain), and passes it back to the client.
6. If the first DNS server in the list does not respond within the specified time (usually about 50 ms), the request is sent to the next DNS server in the list and the process is repeated from points 1–5.
7. If none of the servers responded to the request, the local resolver will re-query them in the same order, but with an increased timeout. However, it is important to note that if one of the DNS servers returns a response that the requested domain name does not exist (NXDOMAIN), then the local resolver will not check the remaining servers and will immediately return that response.

If there are both private and public DNS resolver servers listed, and the public ones come first, when a client asks for a private domain name, the first public server won’t find it and will tell the client it doesn’t exist. So, the request will be denied.

Possible solutions to the problem:

1. Specify Private DNS server first in the list of DNS resolvers. To ensure quick and accurate responses, put the Private DNS server at the top of the resolver list. This way, it will handle requests first. If it’s a private request, it’ll respond authoritatively. But if it’s a public request, it’ll say it’s not found, and the client will move on to the next server.
   However, if there are multiple Private DNS zones, like an MS AD Private DNS zone, things get trickier. You’ll need to add multiple Private DNS Resolvers to the client’s resolver list, making the resolution process more complex.
   Also, if you’re using “systemd-resolved” for example on Ubuntu Servers, it might not respond with an error for unfamiliar public domain names. Instead, it might say the domain doesn’t exist, and the client won’t check other servers. This can lead to issues.
2. One DNS server knows about all zones: Install a single DNS Resolver on the network, which will process all client requests and forward requests to Private DNS zones to specific authoritative Private DSN servers. This is the best solution also in terms of security, because we will be able to control the entire flow of DNS requests on our network and send requests to the Internet from only one host. By having a local cache on this server, we will get better performance and reduce response time to requests.
3. Split DNS Client: On some clients, you can configure conditional resolution based on the domain name. For example, requests to *.domain1.com are directed to DNS server A, and requests to *.domain2.com are directed to DNS server B. However, not all client systems support this configuration.

Useful commands for working with DNS resolvers:
1. dig
# dig @8.8.8.8 www.azure.com и ее короткая версия:
#dig www.azure.com

2. nslookup
set type=soa (ns, a, cname, ptr, ..)

3. resolvectl commands
# service systemd-resolved restart
# resolvectl flush-caches
# resolvectl status

4. cat /etc/systemd/resolved.conf
View the list of installed DNS resolvers

4. vim /etc/systemd/resolved.conf.d/mydns.conf
Add a temporary DNS resolver to the DNS resolvers list
[Resolve]
DNS=168.63.129.16