zone files for subdomains...

[dj]

They are not quite right.

It will work on your server if you are querying it for host.sub.example.com
if the namec.conf holds example.com and sub.example.com.

However, if a recursive lookup is trying to resolve host.sub.example.com
then it will look for where example.com is delegated to from com., then it
needs to know where sub.example.com is delegated to from example.com -
therefore, you need the delegation within example.com to sub.example.com




"Jeff Lasman" <jblists at nobaloney.net> wrote in message
news:bjvgkr$20jf$1 at sf1.isc.org...
> While I'm not a newbie, I'm stuck on this one.  I've already searched
> both online and in "DNS and Bind" and "Linux DNS Server
> Administration".  I may not know how to do this search, so I hope you'll
> bear with me...
>
> I've just started moving domains I'm hosting from a Sun Cobalt RaQ4
> server to a DirectAdmin server.  The Sun Cobalt RaQ4 server doesn't
> automate DNS setup; it requires I do it manually.
>
> So when setting up a domain such as sub.example.com I've always put the
> records for "sub" into the example.com zone file.  That's always worked,
> and reading all the references I've mentioned above, I believe that's
> one way it should be done.
>
> The only other way I've found how to do it, again following all the
> references I could find, is to delegating the subdomain "sub" to another
> zone, and putting all the records for "sub" into the new zone.
>
> However, the programmers who wrote DirectAdmin do it slightly
> differently...
>
> Whenever I set up a domain such as sub.example.com, they automatically
> set up a new zone file for it, but they don't delegate in the master
> (such as example.com).
>
> They tell me it's not necessary to do it the way I've been doing it,
> that bind will always search for the specific domain first in the conf
> file and if it finds a reference for it, it will use that zone file.
>
> Are they right?  Is the behavior documented and likely to continue in
> future releases?  Is it "reasonable" for them to make the presumption?
>
> Thanks!
>
> Jeff
> -- 
> Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA  92517 US
> Internet & Unix/Linux/Sun/Cobalt Consulting +1 909 324-9706
> Our jblists address used on lists is for list email only
> To contact us offlist: "http://www.nobaloney.net/contactus.html"
>