Bind doesn't make zone delegation.

[Ellad G. Yatsko]

Dear Barry!

Please, excuse me, but I feel that you are wrong.

First, when DNS keeps a zone the search order begins from its own zones. 
If domain does not belongs
to this DNS server tries to use forwardes. If forwardes does not answer 
or return negative answer, DNS
server forwards request to Root servers using "root.hint" file. In any 
event I got accustomed to think so.
That is forwardes have lower priority in comparision with own zones. 
Whed Bind sees united-networks.ru
in tail of "bla-bla-bla.unted-networks.ru" it begins to look for that 
bla-bla-bla in "united-networks.ru" file,
doesn't it? And when it understands that there is a fact of zone 
delegation it decides to return to requester
the IP address of the next DNS-server. Am I wrong?

Second. If I use delegation for some zone the condition to keep the same 
zones as "slave" is not
obligatory. Or what type of the zone did you mean in your example? :-)

Third. You probably missed the fact that the same situation is simulated 
fine on neighbor server but with
higher version of operation system (FreeBSD 9.0 in opposite to FreeBSD 
7.2, and both are x64 systems).
I think that certainly Bind on FreeBSD 7.2 doesn't work correctly! And I 
try to understand why - because this
server in production as opptosite to test FreeBSD 9.0. I must to "win" 
this situation just on FreeBSD7.2.

Unconditionally I try what you recommended. But... It is still strange 
to me... :-)

Kind regards,
Ellad G. Yatsko


> In article<mailman.545.1334821108.63724.bind-users at lists.isc.org>,
>   "Ellad G. Yatsko"<eyatsko at ngs.ru>  wrote:
>
>>>      Hello!
>>>
>>>      I have FreeBSD 7.2 x64 installed. And Bind 9.4:
>>>
>>>      /etc/namedb>  named -v
>>>      BIND 9.4.3-P2
>>>
>>>      I have zone "/united-networks.ru/" and I try to do the following:
>>>      ...
>>>      $ORIGIN sokol.msk.united-networks.ru.
>>>      @                       IN NS   srvgate
>>>      srvgate                 IN A    172.31.16.16
>>>      $ORIGIN united-networks.ru.
>>>      ...
>>>
>>>      As I understand I delegated the SOA (IN NS) to server with name
>>>      srvgate.sokol.msk.united-networks.ru ("srvgate" has no tailing "dot"
>>>      so domain "sokol.msk.united-networks.ru" from $ORIGIN operator
>>> will be
>>>      appended), then I placed "glue"-record with srvgate.sokol.msk's
>>> address.
>>>      It is because as I understood nameserver of delegated zone is in it.
>>>
>>>      From here I thought on the server 172.31.16.16 (it's Ubuntu) I must
>>>      receive DNS-requests related to zone sokol.msk.united-networks.ru.
>>> For
>>>      example if I try do nslookup sokol.msk.united-networks.ru on FreeBSD
>>>      7.2 x64. But:
>>>
>>>      /etc/bind# hostname -f
>>>      srvgate.sokol.msk.united-networks.ru
>>>      /etc/bind# tshark -ta -ni tun0 -R dns
>>>      Running as user "root" and group "root". This could be dangerous.
>>>      Capturing on tun0
>>>
>>>      ...there is nothing! And FreeBSD issues NXDOMAIN. I say more -
>>> FreeBSD
>>>      tries to resolve name "sokol.msk.united-networks.ru" through its
>>> forwarder in
>>>      external world!
> When forwarders are enabled, they get used instead of following
> delegations.  You need to add this to your named.conf to override the
> forwarders for this zone:
>
> zone "sokol.msk.united-networks.ru" {
>    type forward;
>    forwarders {};
> };
>
>>>      Where am I wrong? I simulated this situation with the same
>>> configurations
>>>      on Ubuntu (Bind 9.7.0-P1) and fresh-installed FreeBSD 9.0 x64
>>> (Bind 9.8.1-P1).
>>>      All works fine!
>>>
>>>      -------------------------------------- related portion of
>>> named.conf --------------------------------------
>>>      options {
>>>               directory       "/etc/namedb";
>>>               pid-file        "/var/run/named/pid";
>>>               dump-file       "/var/dump/named_dump.db";
>>>               statistics-file "/var/stats/named.stats";
>>>
>>>               listen-on       {
>>>                       ....
>>>                       127.0.0.1;
>>>                       172.16.0.1;
>>>                       172.16.1.1;
>>>                       172.16.2.1;
>>>                       172.31.0.1;
>>>               };
>>>
>>>               forwarders {
>>>                       89.222.167.2;
>>>                       8.8.8.8;
>>>               };
>>>               recursion yes;
>>>               allow-recursion {0/0;};
>>>      };
>>>
>>>      ...
>>>
>>>      view internal {
>>>               match-clients {
>>>                       127.0.0.0/8;
>>>                       172.16.0.0/12;
>>>               };
>>>      ...
>>>               zone "united-networks.ru" {
>>>                       type master;
>>>                       file "master/forward/united-networks.ru.internal";
>>>                       allow-transfer {
>>>                               172.16.0.2;
>>>                               172.16.16.2;
>>>                               172.31.16.16;
>>>                               172.31.17.0;
>>>                               172.31.18.0;
>>>                       };
>>>               };
>>>      ...
>>>      };
>>>      ...
>>>
>>> ----------------------------------------------------------------------------
>>> -------------------------------
>>>
>>>      Kind regards,
>>>      Ellad