Bind doesn't make zone delegation.
Peter Andreev
andreev.peter at gmail.com
Thu Apr 19 12:58:59 UTC 2012
2012/4/19 Ellad G. Yatsko <eyatsko at ngs.ru>
> Nope. FreeBSD is not the master for sokol.msk.united-networks.ru. It
> delegates zone sokol.msk only.
> Not more.Master for sokol.msk.united-networks.ru is
> srvgate.sokol.msk.united-networks.ru (Ubuntu
> server).
>
> Indeed, now when I try nslookup sokol.msk.united-networks.ru - it returns
> me its IP. FreeBSD asks for zone
> information Ubuntu. Ubuntu answers. But when I try to resolve what is "
> ap-1131.sokol.msk.united-networks.ru"
> FreeBSD is silent as before. It does not ask Ubuntu. It does not return
> any IP: NXDOMAIN.
>
> Kind regards,
> Ellad
>
Is zone united-networks.ru <http://sokol.msk.united-networks.ru/> listed in
external view? If so has it records for
sokol.msk.united-networks.ru<http://sokol.msk.united-networks.ru/>?
Is option "recursion yes" global or view-specific? Could you provide
configuration details for recursing and forwarding?
>
> 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 <http://172..16.0.1>
>> sokol..msk.united-networks.ru <http://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 <http://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 <http://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<http://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 <http://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
>
>
>
--
AP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120419/261f554f/attachment.html>
More information about the bind-users
mailing list