[SOLVED] Remove 127.0.0.1 from resolv.conf ??

[codedmind]

hmmm in dns server settings the domain isn't in dynamic
how can i change it?

[christian]

ok, THIS is the point 
I suppose it become dynamic based on DHCP configuration only. Did you try to restart both DHCP and DNS services as I'm not sure this setting is... dynamic 

[codedmind]

hummm ok give me two hours then i will reboot all zentyal.

[christian]

restarting DHCP as NO impact on clients, except if someone is asking for a new lease, which is very unlikely.
DNS restart is very fast too ;-)
but it's up to you.

[codedmind]

that i have done yet and domain isn't dinamic

[christian]

I don't know how to help further 
You could still try to delete and create again this domain in DNS section, assuming you don't have too many host to be then manually created.
Next step, if you still want to reboot and if it still doesn't work, will be ticket at support.

[codedmind]

ok dynamic domain is active

but didnt aolve the problem

[christian]

How did you activate it (just curious) ?

What I suggest now that DNS is active, is that you renew lease from one client. Registration in DNS should only happen, for what I understand, when lease is issued or perhaps renewed. Rebooting server will not help as lease is still valid. Reason why you new to release and renew from client side.

[codedmind]

i restart dns and dhcp and then it is done...

I will now reboot the zentyal, with that i will assume dhcp will atribute new leases, right?

[UdoB]

dmps@zentyal:~$ cat /etc/resolv.conf
search cariano.local
nameserver 127.0.0.1
nameserver 192.168.1.254
nameserver 81.92.193.1
nameserver 81.92.192.2
nameserver 81.92.192.3
nameserver 8.8.8.8
nameserver 8.8.8.4
dmps@zentyal:~$

This looks like a very "strange" configuration for me - especially knowing you are running "Infrastructer / DNS" as a Zentyal service (for good reasons).

• there is a non-functional entry: the last line is simply wrong. Probably you wanted to enter 8.8.4.4:
  

Code: [Select]

~$ host 8.8.4.4
4.4.8.8.in-addr.arpa domain name pointer google-public-dns-b.google.com.

• in my opinion there are much too many entries. On my systems there are usually two or three of them. Not more. If all three fail I have other severe problems than name resolution.
• I wonder if you understand which computer is actually using these entries: these are only used by the so called "resolver" locally on the server system, not for the clients in your local network. The clients will/must use the server defined in their DHCP query/answer. Running Windows as the main clients host OS it is a MUST to make them use this Zentyal machine running Samba. No other name servers (also no secondary or "Spare" server are of any use - except if the secondary one  replicates the data from the primary machine.) Samba 4 requires this. You can not choose.

So I am convinced that on a Zentyal/Samba machine you need to prepare the local DNS Server to know some (two or three) Forwarders which will then automatically will be queried to resolv external DNS-Names/IP-Adresses. When BIND is configured correctly

• the machine running the DNS-server and Samba should only contain nameserver 127.0.0.1 in /etc/resolv.conf to get consistent behavior.
• the clients will list nameserver ip-adress-of-zentyal in that file.

Test it on a command line on the host

Code: [Select]

~$ nslookup www.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.google.com
Address: 173.194.69.105
...
The very same query must work on Windows clients in your LAN.

Perhaps this helps...
Best regards

[christian]

no... wrong assumption 
Once lease is acquired by client,  :-\whatever DHCP server status, this lease is valid. reason why rebooting is useless as I explained above.
What you need to do is to renew this lease, from client side.

[christian]

@UdoB:
although you're not wrong, his problem was, but it took time for me to understand  , that DHCP was not registering dynamically hosts in DNS.
no more nor less.

It took time to get there because he had implemented some workarounds, using Windows DNS mixed with need to resolve external names but not via Zentyal DNS... well nothing simple while initial problem is quite simple.

At least we progress. I believe we are almost done now. This is just a matter of renewing lease so that is triggers registration in DNS 

[christian]

@codedmind: in case I was not clear enough, DHCP client on which you have to renew DHCP lease is the server or client you want to ping or reach because this is the one to be registered in DNS. for testing purpose. other DHCP clients will renew their lease at 50% of max lease duration, this is populate your DNS.

[codedmind]

Weel now i'm working remotly the thing is more difficult ... after reboot i loose http connections from clients (loose access to zentyal web)

anyway, remove zentyal-squid from terminal and up running again.

Please can we start from de begin

From network i will remove all the dns entry (this way only 127.0.0.1 will be in resolv.conf)
dhcp server should give what nameservers? zentyal ip plus one ou two nameservers like 8.8.8.8 and 8.8.4.4?

I must install samba in zentyal to run dns server?

[christian]

  why do you want to restart everything from scratch 
Furthermore, rebooting was not mandatory 

I suggest we do not discuss content of resolv.conf or any other file but focus on Zentyal configuration from GUI. Do not take it the wrong way but for the time being, given debate we have, I don't think you have yet reach the stage where we can look at config detail from CLI.

Zentyal as DNS client:
this is configured in network section !  be sure to add here some external DNS otherwise you will never resolve any external name

Zenyal as DNS server: do not change anything now that DNS is dynamic. Ensure DNS acts as cache.

DHCP server:
you can (should) push Zentyal as DNS server for clients.
adding external DNS is useless (again)

No you don't need to install Samba to have DNS working (furthermore you will not be able to do it because your network domain is not supported, due to the "local" TLD