Bind doesn't make zone delegation.

[Peter Andreev]

2012/4/19 Ellad G. Yatsko <eyatsko at ngs.ru>

>  Hello!
> Here is output:
> /etc/namedb> dig @172.16.0.1 sokol.msk.united-networks.ru. NS +norec
>
> ; <<>> DiG 9.4.3-P2 <<>> @172.16.0.1 sokol.msk.united-networks.ru. NS
> +norec
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14255
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;sokol.msk.united-networks.ru.  IN      NS
>
> ;; AUTHORITY SECTION:
> sokol.msk.united-networks.ru. 3600 IN   NS
> srvgate.sokol.msk.united-networks.ru.
>
> ;; ADDITIONAL SECTION:
> srvgate.sokol.msk.united-networks.ru. 3359 IN A 172.31.16.16
> srvgate.sokol.msk.united-networks.ru. 3359 IN A 172.16.16.1
>
> ;; Query time: 0 msec
> ;; SERVER: 172.16.0.1#53(172.16.0.1)
> ;; WHEN: Thu Apr 19 14:08:55 2012
> ;; MSG SIZE  rcvd: 100
>

Looks good for me.


> I noticed that after some time FreeBSD still tried to ask for
> sokol.msk.united-networks.ru from Ubuntu (srvgate.sokol.msk).
> It happened after 2-3 minutes after "named" was restarted on FreeBSD. But
> now FreeBSD doesn't ask for hosts in this zone.
> All what I was doing during this time period - I restarted freevrrp-daemon
> on FreeBSD machine. Could it be related to issue?
>

Is FreeBSD a master for sokol.msk.united-networks.ru? Looks like it is
trying to send notifies.


> Something very strange..  Another FreeBSD (9.0) works fine in the same (or
> much like) conditions...
>
> Kind regards,
> Ellad
>
> Hi,
>
> First of all, nslookup isn't a good tool for debug DNS problems. Use dig
> instead.
>
> Could you show the output of "dig @freebsdbox sokol.msk.united-networks.ru.
> NS +norec" run from freebsd box itself?
>
>
> 2012/4/19 Ellad G. Yatsko <eyatsko at ngs.ru>
>
>>
>>     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!
>>>
>>>    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
>>>
>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
>
> --
> AP
>
>
>


-- 
AP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120419/db4cddf5/attachment.html>