sub domain for ddns - resolving

[Kevin Darcy]

Vernon A. Fort wrote:

>I have successfully configured an internal name server to allow for ddns 
>for my dynamic ip address (dhcpd), both forward and reverse within 
>separate files.  My initial intension was to keep the primary/static 
>hosts within a manually editable file.  Unfortunately, I discovered you 
>cannot push out a Search List to the workstations via dhcpd AFTER I got 
>well into the setup.  I have googled and read several posts with similar 
>issues but no conclusions.
>
>DETAIL:
>       primary domain:      mysite.int with "20.168.192.in-addr.arpa"
>       secondary domain:   ddns.mysite.int with 
>"20.168.192.ddns.in-addr.arpa"
>
>  So, how does one have the ddns sub-domain assigned to the Workstation 
>resolve hosts entries within the primary domain.  As I understand, named 
>is NOT a resolver, it just returns answers to the query from the 
>workstation?
>
>  What I need is the workstation host (wkst01.ddns.mysite.int) to 
>resolve serverone (serverone.mysite.int) without the FQDN.
>
>      1.  Is there something I missed, similar to the $GENERATE 
>statement for the in-addr.arpa
>       2.  Run Dual name server, the sub-domain forwarding to the primary?
>
>Or should I just scrap the sub-domain idea and just have everything 
>within two zone files, using nsupdate to add/modify/remove?  I have 
>already invested 12 hours, most of it reading.  I know this has been 
>asked several times but I have not found any firm conclusion.  Some 
>advise PLEASE!
>
My inclination would be to scrap the subdomain idea and use nsupdate, 
perhaps with some sort of wrapper around it that does sanity checks, etc.

If you have anything bigger than just a "toy" network, I'd also give 
serious consideration to using fully-qualified domain names exclusively 
instead of shortnames. Once you get beyond a certain number of 
subdomains, shortnames become problematic, but, unfortunately, it may be 
too late by then, because using shortnames is one of those bad habits 
that tends to be hard to get users to break.

                                                                         
                                                   - Kevin