Comment 8 for bug 1003842

Simon Kelley might have written dnsmaskq with the assumption that all DNS servers upstream have the same view about the namespace. However, this is not how RFC sees it nor how it is set up in a majority of installations.

Consider a small installation where the main server also serves DHCP address leases and has to maintain DNS names. All names end in an internal domain name domain.intern (like MS SBS not only recommends but enforces). The DNS server is set up to forward unresolvable requests to the upstream DNS server. Clearly the upstream DNS has no clue about domain.intern addresses.

Why not set up DNS to use the internal server to serve all requests and forward what cannot be resolved? Quite simple - speed and resillience.

If the internal server cannot answer the DNS request, the client redirects the query to the next server. This eliminates the internal server as a resolution bottleneck and allows the clients to continue with a basic set of functionality in case of a server outage (planned or not).

So now you easily have two separate DNS servers, on dealing internal requests and one external.

In our case, the router binds DNS so that it can forward DNS requests. This gives us extra resilience in case of a DNS server outage with our main provider. We use the router to forward to a different DNS server.

Server down -> No mail, no fileservices, no printing services, no database BUT Internet access still works
Router down -> OK, we have a problem
Upstream DNS down -> No problem at all

Also our internal DNS server serves requests to our own external domain as well as some others. So it definitely does not have the same view as upstream DNS. None of this violates RFC definitions.

@callegar: I agree with you: If dnsmask handles DNS resolution it MUST resolve the issue. That means either Kelley adapts his position or dnsmask has to go.

@jdthood: As a user I wasn't asking for dnsmask. It was chosen to improve DNS resolution. Which it does not. In a LTS release this is pretty hard (it is pretty hard in any release). Good design not only suggests but enforces that if a technology substitutes a predicessor it is required to provide a fallback in case of error.

Commenting dns=dnsmask in /etc/NetworkManager/NetworkManager.conf is a workaround but certainly not a solution.

Finding an automatism to resolve different DNS resolution paths would be the responsibility of the programmer in my (simplified) view.