Migrating Ubuntu 10.04 Users to Zentyal 3.0

[Escorpiom]

Christian, the only possible explanation would be that resolv.conf is being overwritten because one or more of your external interfaces is doing DHCP.
I have both external interfaces set as static and resolv.conf reflects exactly what has been set in the Zentyal interface.

Cheers.

[christian]

You are perfectly right:  I realized exactly the same last night and indeed, for some reason, one external interface was left (changed?) to DHCP. No real impact in term of address as my router is configured with reserved IP for Zentyal MAC address but this changes resolv.conf content obviously.

[UdoB]

Hello OliverSteele,

we needed to have all three nameserver IPs listed first in resolv.conf

From the GUI
Zentyal >> Network >> DNS >> + Add New
You may add as much as you want (I just tried it and it worked for me).

My understanding of DNS is a little bit different: it is a hierarchical system. You can not add several independent name servers into resolv.conf which are responsible for different domains and expect to resolve all of the zones.

For a new query only ONE server is picked and asked to resolve the name. When this NS answers "no, that host you asked for has no ip address" the resolver will NOT ask the other nameservers.

The point is that all nameservers should know "Forwarders". When a NS does not know a hosts name by itself it asks them. On of those upstream systems will reply either with the correct data or the query will result in "unknown host name".

To have more than one NS is recommended for redundancy - they must supply identical value. But the second/third... one will only get to be asked if the first one does not answer at all.

In other words: several several NS entries will rise the reliability, they will NOT offer the sum of knowledge of all of them.

One solution is to tell BIND about those zones: if you must resolve several independent zones you need to configure your primary name server (BIND on Zentyal in this case) explicitly to ask specific primary NS, responsible for that specific zone. This is not magic, it works. But it is a completely different approach to solve that issue than having "simply" several nameserver-entries configured in resolv.conf. Keep in mind that you need to copy BIND's *.mas to /etc/zentyal/stubs to make it persistent. The "normal" Forwarders can/should be told to BIND via the Zentyal Webgui.

This BIND instance, running on 127.0.0.1 is the ONLY entry in /etc/resolv.conf then. 

Disclaimer: I did not modify Zentyal's BIND yet, so I am not sure if this all one needs to know.

Best regards

[christian]

For a new query only ONE server is picked and asked to resolve the name. When this NS answers "no, that host you asked for has no ip address" the resolver will NOT ask the other nameservers.

The point is that all nameservers should know "Forwarders". When a NS does not know a hosts name by itself it asks them. On of those upstream systems will reply either with the correct data or the query will result in "unknown host name".

To have more than one NS is recommended for redundancy - they must supply identical value. But the second/third... one will only get to be asked if the first one does not answer at all.

In other words: several several NS entries will rise the reliability, they will NOT offer the sum of knowledge of all of them.

+1
Here I've configured 2 DNS entries for each ISP + another one in case (very unlikely) none from ISP answers but I do not expect different answer depending on which (external) DNS is requested.

[OliverSteele]

Does anyone know if there is a way to specify more than one search domain? I am of the understanding that more than domain is allowed after the "search" option in resolv.conf.


Also, the following problem is perplexing me. If anyone has some idea about why this might happen, please tell:

Zentyal box has two network cards set up as such:

eth0: local network, static IP of 192.168.0.1, domain name of electron.internal.local
eth1: external network, static IP of 25.10.10.1, domain name of electron.defense.uk (names and IPs have been changed to protect the innocent)

Can ping both electron.internal.local and electron.defense.uk  *however*  "ping electron.internal.local" returns a response from the outward facing IP, i.e.

64 bytes from electron.internal.local (25.10.10.1):  .....

instead of

64 bytes from electron.internal.local (192.168.0.1): .....

Additionally, "ssh user1@electron.defense.uk" from an internal network computer works as expected, however "ssh user1@electron.internal.local" will prompt for the password, but then always respond "Permission denied, please try again." even though we're 100% sure we're typing the right password. The firewall is set to allow any connection from an internal computer to electron, so I wouldn't think that is the problem, but I don't know.

[OliverSteele]

I should also note that "ssh user1@25.10.10.1" and "ssh user1@192.168.0.1" are both successful, which doesn't clarify things for me at all, but may be useful to someone more knowledgeable than I.

[christian]

Regarding your SSH issue:

- be sure that nsswitch.conf contains "file dns"
- then be sure that /etc/hosts contains an entry for localhost matching 127.0.0.1 and also entry for your Zentyal server (quite often 127.0.1.1 fqdn host)
- last, look at resolv.conf => it should contain entry for 127.0.0.1 so that local (Zentyal) DSN is used to resolve local (internal) domain.

If everything is correct, you should be able to resolve electron.internal.local on Zentyal server itself.
Does this work ?

[OliverSteele]

Each of those details seems to be correct, yes. "ssh user1@electron.internal.local" from electron itself works correctly, just not from any of the client computers on the LAN. It kind of depends on what you mean by "resolve" electron.internal.local I think. When I execute "host electron.internal.local" from a LAN computer (or electron, actually), the response is:

electron.internal.local has address 192.168.0.1
electron.internal.local has address 25.10.10.1
electron.internal.local has IPv6 address ::1

When I execute "host electron.defense.uk" the response is simply:
electron.defense.uk has address 25.10.10.1

[OliverSteele]

A few more related details/questions. Sorry about the deluge:

Isn't it an error that "host electron.internal.local" on a client computer is showing the IPv6 address as ::1? That's loopback right? I did a little experiment and it seems to comfirm my hypothesis:

- I ssh'd from electron to a LAN computer called dipole. That worked fine. I'm now on dipole as user "localuser".
- I deleted ~/.ssh/known_hosts.
- I typed "ssh localuser@electron.internal.local" **There is no user named localuser on electron!!!**
- One of the lines is "The authenticity of host 'electron.internal.local (::1)' can't be established.
- It prompts me for my password, so I type the password for dipole. It succeeds!

So for some odd reason, A) the LAN computers are suddently using IPv6 by default when ssh-ing to electron, but B) electron is telling these LAN computers that its IPv6 address is really the loopback address which obviously points to the computer I'm currently working on. Madness. It should be noted that adding the -4 flag to ssh allows successful ssh-ing to electron from LAN computers using the local domain, i.e. "ssh -4 user1@electron.internal.local" works correctly.

Under the DNS tab, the only listed domain is internal.local, however the "domain IP addresses" has both 192.168.0.1 AND 25.10.10.1, and similarly when I click on "hostnames" electron shows up, but that has two IP addresses as well. Should there be a separate ".defense.uk" domain with the 25.x.x.x information?