Using SuSE with DDNS from ISC (Bind 9) or Win2k is from what I see broke. Adding the ISC client, with: # send dhcp-client-identifier "c32423-a" interface "eth0" { send host-name "grover.smi.sendmail.com"; } 1) The DHCP client needs to be able to (easily) send its host name along with its DHCP request when booting. Same functionality as the command line "dhcpcd -h <hostname>". 1b) Better still, how about a new feature, "-H if it's not already in use?" that automatically sends the current host name, but without anything after the first dot in the name. For example, a system whose hostname is "foo.bar.com" would send its registration as "foo", which would allow the DHCP server to add the default domain to the DDNS registration. 2) The way the client currently writes the /etc/resolv.conf file is not good. The current code outputs a file that looks just like the one generated by default with the ISC DHCP client. 3a) ISC has a dhcpc-client-exit-hooks script file that users can modify to force the file to be rewritten as necessary for the user's environment. If dhcpcd offers something similar, we missed it. example script: dhclient-exit-hooks #!/bin/sh echo domain $new_domain_name > /etc/resolv.conf echo search $new_domain_name sendmail.com >> /etc/resolv.conf for nameserver in $new_domain_name_servers do echo nameserver $nameserver >> /etc/resolv.conf done 2b) When the DHCP server passes back the client's domain name, dhcpcd uses the domain value to create the search directive in resolv.conf. But the result of this in a multiple sub-domain environment is that the name space of parent DNS domains will not be checked. For example, let's say my computer is in the DNS subdomain eng.foo.com. Because dhcpcd uses the directive "search", this means that a DNS lookup for www(.foo.com) would fail unless I fully qualified the lookup. Also, a lookup of a host on another internal DNS subdomain notices.hr(.foo.com) would have to be fully qualified with the .foo.com at the end. If the "domain" directive is used instead, most (but not all) DNS resolver libraries will automatically handle searches through the parent domains. For example, I'm on a host in eng.foo.com and I am looking for a couple of unqualified hosts. resolv.conf has the domain directive instead of search: Lookup of www: Resolver tries: www.eng.foo.com (fails) Resolver tries: www.foo.com (succeeds) lookup of hr.notices: resolver tries hr.notices.eng.foo.com (fails) resolver tries hr.notices.foo.com (succeeds) So how about using the DHCP server's domain value and using it to populate the domain field of resolv.conf? 2c) Another approach would be to automatically assign all parent domains of the current subdomain to the search directive. Consider a host in the domain "seattle.eng.foo.com". Right now, dhcpcd creates a search directive of just that domain. But it could (optionally or by default) create a search domain list including all parent domains. In this case, search seattle.eng.foo.com eng.foo.com foo.com This would have the same search path as would be automatically used by the resolver if the domain directive had been used. 3d) Best of both worlds: Use the DHCP domain value to set the domain result, and automatically generate the correct search list as well. Consider again a host in the domain "seattle.eng.foo.com". Its resolv.conf file should look like: domain seattle.eng.foo.com search seattle.eng.foo.com eng.foo.com foo.com nameserver 10.1.2.3 nameserver 10.4.5.6 Why set both the domain and the search directives? Some programs use the domain directive to determine their DNS domain, oddly enough. These programs may look in the search domain as a second choice, but might break when the search directive contains a list of domains. Setting the domain value to match the domain value assigned by the DHCP server avoids this entirely.. The search domain being set explicitly removes the reliance on the computers resolver libraries to automatically parse through the domain directive every time. (I've seen more than one OS where the resolver libs didn't handle DNS parent domain lookups automatically.) More importantly the resolv.conf file shows the user of the system (and any programs, too)*exactly* what's supposed to happen.