Bind doesn't make zone delegation.
Peter Andreev
andreev.peter at gmail.com
Thu Apr 19 11:11:57 UTC 2012
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>
More information about the bind-users
mailing list