Topic: A question about DNS and DHCP

[smoothfroggy]

Hello to everyone,

Please, forgive me if the following question appears to have already been answered many times ; I have crawled through forums and wiki for a while without finding an appropriate answer (at least, I think).

I have set a SME server on an old laptop some days ago as a bridge other a dedicated DSL connection in order to prepare small web site applications as well as remote email capabiliy. Things run rather smoothly and I must mention that I am happy with SME as it is : simple and efficient.

Though, I have a problem left with DHCP. The server provides, as expected, IP addresses to the machine on the LAN but, for some reason, does not seem to be able to ping these machine using the machine hostnames either on one of the machine of the LAN or on the SME server itself.
I have tested this behavior with Linux based machines and Windows based one. Talking about the Linux machine (Debian Lenny), the dhcp client is setup to send the hostname (file /etc/dhcp3/dhcp.conf includes the command 'send host-name "toto.tata.net";'. The Windows based machine also send the hostname as expected.
Digging a bit, the file /var/lib/dhcp/dhcpd.leases on the SME server appears to have the hostname recorded : the windows and linux machine names appears in clear.

I tried to ping from SME as follows :
- ping toto
- ping toto.tata.net
And the sole message always come back : ''ping: unknown host toto' or 'ping: unknown host toto.tata.net'

I have checked that the names are solved locally for the domain tata.net in the SME server manager but I am not sure that I can interpret this as SME acting as a local DNS server (there is some ambiguity there).

I would be very grateful if someone could help to understand the DNS/DHCP structure in SME, if this beahviro is to be expected and, if not, may suggest some ways to get this to operate as expected.

Regards,

Smoothfroggy

[cactus]

I tried to ping from SME as follows :
- ping toto
- ping toto.tata.net
And the sole message always come back : ''ping: unknown host toto' or 'ping: unknown host toto.tata.net'

What is the IP range of your local network you configured? Is the IP of your clients in this range? With the proper subnet?

[mmccarn]

You may want to run "dhcpactiv.sh" to see what your dhcp server is doing...

You can get it from http://bugs.contribs.org/show_bug.cgi?id=2641, or using

Code: [Select]

wget -O /usr/local/bin/dhcpactiv.sh http://bugs.contribs.org/attachment.cgi?id=947
chmod 755 /usr/local/bin/dhcpactiv.sh

By default, the SME DNS server pre-creates entries for all of the un-reserved IPs on your local LAN with entries like "pc-00001" ... "pc-00254".

The SME DHCP server does not update the DNS server with the client computer names - so if your network clients are depending on DNS you'll need to access your local systems using "PC-0001", etc.

Windows generates some confusion by trying a couple other technologies for finding local host names - so sometimes a windows box will be able to find another windows box on the local network by name even if the dns server doesn't return the same name.

The only non-custom way to fix this at present is to create dhcp reservations for your local systems using "Hostnames and addresses" in server-manager.

[smoothfroggy]

Hello,

To Cactus, thanks a lot for your answer. I should have mentioned that using the IP address of the local LAN machines, I can obviously ping them from any client and/or the SME server. I will not speak for the windows based machines as I don't know enough about their structures, but the Linux machines are using a dhcp client (dhcp3) that after launching the standard broadcast DHCP DISCOVER expect an offer DHCP OFFER from the server (if any on the LAN) and finally negotiate the IP address as well as subnet, DNS and gateway through the usual DHCP REQUEST and DHCP ACK. I have found these in the logs on the clients. I should also have mentioned that the IP range, subnet and gateway setups are the ones from an old router I build based on Linux and iptables about 5 years ago and I wouldn't expect those to be responsible for the behavior observed.

Mmcarn, thanks also a lot for your answer. From it, I now better understand the situation. I understand the workaround though it does not look very... nice... You are also right about Windows which use other principles to obtain network neighbourhood. Most of the machines on the LAN are Linux, the windows ones are welcome as guests from time to time, not on a permanent basis.
If I may ask the question, could you comment the reason the SME developers chose to setup the DHCP server to not update the DNS server ?
You seemed to mentioned that it was the only non-custom way. Would you have some advices on a custom way (may be modifying the templates that setup DHCP and DNS servers). Should you be able to help, it would be very appreciated.

[mmccarn]

Here's an existing bug for work on this issue: http://bugs.contribs.org/show_bug.cgi?id=2388

It looks as though the code required to have DHCPD update the local tinydns data files and refresh the dnscache information is mostly written...

[smoothfroggy]

Hello Michael,

Thanks for pointing on bugzilla. I will have some homework to do to understand the part linked to a specific daemon watching the lease file for change. Unless this has already been done, I will post results on that subject.

Best regards,

Smoothfroggy

[mmccarn]

For your purposes, assuming your workstation population is reasonably static, you could write a script that reads "dhcpd.leases", updates tinydns, then restarts dnscache... then schedule that in cron to run every 15 minutes or so...