UCS does not solve any domain/host

UCS - Univention Corporate Server
#1

UCS has /etc/resolv.conf:
domain somedomain.local
nameserver 172.18.8.194
nameserver 172.18.8.1
options timeout:2

Trying to solve any domain just leads to NXDOMAIN not found. If I edit /etc/resolv.conf, deleting line “nameserver 172.18.8.194” any host is immediately solvable.

The local resolver just does not solve any names! Two solutions come to mind:

  1. kick this local resolver
  2. Make sure it takes 172,18.8.1 to forward anything it does not know about.

I could not find a way to kick the local resolver. I can stop it, but a few minutes later it is running again. I can edit /etc/resolv.conf, but a few minutes later it is restored to what does not work. Any idea how to stop the system to kill dns resolving? Or: how to make the local resolver forward anything it does not know about to upstream?

#2

Hi,

first, do not edit your resolv.conf manually as it get overwritten frequently. Instead, use ucr variables.
For your DNS issue have a look at this article.
It tells you how to set correct settings for UCS servers.

/CV

#3

In this case: DNS is set by DHCP. The server is configured to use DHCP. Data delivered by DHCP is added to /etc/resolv.conf. But then the local resolver is entered first in /etc/resolv.conf without setting configuration in a way the local resolver forwards requests he cannot answer to upstream DNS.

domain somedomain.local
nameserver 172.18.8.194
nameserver 172.18.8.1
options timeout:2

host google.com – first entry in /etc/resolv.conf is asked:
-> NXNODOMAIN -> that is ok, since the server is up and alive -> google.com unknown

The local resolver would be correctly configured if it where configuered to ask the upstream DNS configured as second “nameserver”-line in /etc/resolv.conf.

Since this is DHCP configured stuff, it won’t be helpful to configure it using ucr-registry entries – the second line may change as soon as the server is connected to an other network. Configuration has to be automatic in such cases (and it was before last upgrade).
With the last upgrade DNS resolving was switched from dnsmasq(?) to systemd. dnsmasq automatically did what was expected: the first line was localhost. Thus all tools asked the local resolver. The second configured nameserver line was taken automatically as forwarder. dnsmasq this way would have noticed it does not know anything about “google.com” and forwarded the request to the second configured DNS.
systemd-resolver does NOT do it this way. In tune it is yours to configure it to forward all requests it can not answer to upstream. It is your tune to enter the DHCP provided DNS into the configuration for systemd-resolver!
I consider this a bug to be fixed!

#4

Did I skip something or why do you think dnsmasq or systemd are used? On my machines named from bind9 package is listening on port 53 UDP and it behaves like expected. Anyway using DHCP for a univention server is a bad idea, as changing the IP may break quite a lot of things.

#5

Sorry I have to disagree here. At least there is some sort of misunderstanding on your side.
Your are right, according to the man page the resolve queries the nameservers in order of entries. But when the resolver gets a reply it does not query the other hosts. And you showed us a successful query. Yes, NXDOMAIN is a successful query! It got back “no such domain”. Why should it nag other nameserver if the domain does not exist?
The order of nameservers is for the case the configured one can not be reached and does not reply at all!

On UCS you have the local resolver library using whatever is configured in /etc/resolv.conf. The broken thing here is your nameserver 172.18.8.194 as this guy is not able to query the domains (because of misconfiguration or security policy I assume). So it gives back a NXDOMAIN even though the domain appears to exist.

As @crbble already stated it is a very bad idea to have a domain controller server running on a dynamically assigned IP! And indeed, there is no such thing like dnsmasq on UCS. In UCS you have bind9 beeing the authoritative nameserver for it’s zone. And it bind should be queried first of all other dns servers otherwise you might run into serious trouble with your setup.

Sorry to say, but: fix your setup!

/CV

#6

Server configured for DHCP.

Your setup:
asking app -> first nameserver: local dns
> second nameserver: dhcp configured dns

This setup is automatically done if you choos dhcp for configuring your server. What will happen now. If local dns is running?

application querys local dns about “google.com”. Local dns does not know about and answers NXDOMAIN.
application is happy to tell you google does not exist. fin.

Why does it happen?
Because local dns DOES NOT FORWARD any UNKNOWN host to upstream. Why shall this be neccessary? Because you decided to allow for virtual machines you want to have names instead ip-adresses and those are expected never to show up somewhere else. They are local, nated and firewalled. And they have their own interface. But you do not want to type ip-addresses all time you want to access these VM from your host, so you decided to set up a local dns – this local dns is configured to answer all local known names and it would forward all names not locally known to upstream servers. But you decided to never configure the forwarder …

Since we are on dhcp this has to be changed every time a lease is granted. And this has to be done automatically – not by some human typing ucr variable settings! Or you should decide not to configure such VM using a locally running dhcp.

#7

You can use names for your local machines without any issues.

Again, fix your setup. Configure 172.18.8.194 so it can query internet servers. Or at least 172.18.8.1.

As soon as your “local” server can resolve Internet domain you will not get back NXDOMAIN.

/CV

#8

I can configure this manually. Until I am connected to an other network. I’ll have to reconfigure. Reconfigure at home, at company, at an other bureau, at an other building, … If this was intended …

#9

Hi,

but you are talking about a server, right? Who is moving a server with frequent change of locations???

And besides- the issue is NOT the dhcp configuration of your UCS server. It is your nameserver which is at least partially misconfigured. As I said: fix it!

Once your nameserver is able to resolve you clients AND your ucs will work flawlessly. Stop complaining and fix your local nameserver.

/CV

#10

I cant. Because you are overwriting all fixes I could introduce. Your writing /etc/resolv.conf: first “nameserver” line is the locally used interface address. Second “nameserver” line is what is provided by dhcp. As you pointed out: it is frequently written.

Trying to tell the used dns-resolver to forward to the dhcp provided dns works like a charm – for a short time. then it is overwritten and stops working.

Using the provided idea to set ucr variables does help – until you change your network. You’ve to reconfigure to what dhcp provides to make it work again …!

Switching to a static ip configuration kills a variety of services as soon as you have to change addresses. Not useful. BTW. these work with dhcp, regardless of address changes.

It is your nameserver which is at least partially misconfigured.

No. The Server is correctly configured, but without any forwarder it does not know where to go if an address is not known. And it would be your tune to tell the dns what forwarder to use. I am not a dhcp client! So fix your automatism to tell the running dns where to find the forwarder every time dhcp assigns a new address, and dns.

#11

It is a good habit to operate servers with fixed network configuration (including IP addresses, gateways, routes and DNS). And yes, if you move a server to another network you need to reconfigure!

UCS takes DNS forwarder configuration via UCR variable dns/forwarder1.
So do as root on UCS command-line (replace the IP with the DNS server you want to use!):
ucr set dns/forwarder1=192.168.x.x
And that should be it. That works for me an any fresh UCS install.

Documentation can be found here: http://docs.software-univention.de/manual-4.3.html#computers:Configuring_the_name_servers

If that still does not work it is very likely that you broke some config in your attempts.
You can run ucr commit to recreate all config files from their UCS templates.
Or you do a fresh install.

BR,
Jörn

#12

Before we are discussing ANY further you will have to tell us exactly about your setup. I am not willing to guess any longer.

What IP is your UCS? Is this a fixed IP? Why do you not want the UCS to be able to forward DNS queries?

I guess (!) you initially want to have nameserver UCS for local zone including your clients. And second nameserver for all other zones. Right?
So you want your client to ask DNS1 for zone A and DNS2 for all other zones, right?
This is not going to work as by concept you can usually not assign your clients to different nameservers for different zones.

No. The Server is correctly configured, but without any forwarder it does not know where to go if an address is not known. And it would be your tune to tell the dns what forwarder to use. I am not a dhcp client! So fix your automatism to tell the running dns where to find the forwarder every time dhcp assigns a new address, and dns.

So you intentionally disallowed the UCS to use any forwarder and now you are complaining it is not resolving correctly? What else would “misconfigured” mean?

Anyways, make clear statements about your goals, your IP ranges, your configuration and then we can see any further. Not guessing any more.

/CV

Mastodon