Bind doesn't make zone delegation.
Barry Margolin
barmar at alum.mit.edu
Fri Apr 20 18:35:02 UTC 2012
In article <mailman.560.1334941694.63724.bind-users at lists.isc.org>,
"Ellad G. Yatsko" <eyatsko at ngs.ru> wrote:
> 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
Almost right. If you have forwarders configured, it depends on whether
you have "forward first" or "forward only" configured. The default is
"forward only", so it stops if the forwarders fail.
If "forward first" is configured, then if the forwarder doesn't answer
it will use the most specific delegation it knows for the domain,
working from the root servers if it doesn't yet know any delegation.
> 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?
It depends on whether the request asked for recursion or not. If
recursion was requested, and is enabled, the server will query the
forwarders or delegated servers. If recursion is not requested, it will
return the name and IP of the delegated server.
Since you're delegating to a private IP, I assumed that this was an
internal nameserver, and the clients are using it as their resolver.
Resolver clients request recursion.
>
> 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? :-)
The zone type is "forward", as I showed in my 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.
I don't think the OS version should matter, just BIND.
>
> 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
--
Barry Margolin
Arlington, MA
More information about the bind-users
mailing list