reverse zone of type forward when /28 subnet
Peter Andreev
andreev.peter at gmail.com
Thu Dec 27 13:28:07 UTC 2012
2012/12/27 Dmitri Tarkhov <tarkhov at dionaholding.ru>:
> Hi,
> thanks a lot for the information.
> Contains key reason and sounds interesting.
>
> 1. Do you mean I can isolate zone "z.y.x.in-addr.arpa"
> into a separate view where recursion is enabled but all
> other zones are excluded? If so, it's very promising.
Actually, forwarding also doesn't work for queries without RD bit.
Such queries are being sent by resolver in normal circumstances.
> 2. Sorry, "Unbound" - is it just another dns server?
Yep, it is recursive-only dns server. It has an option called
"local-zone", which is absolutelly what you are looking for. Note that
Unbound has very limited capabilities to support authoritative data.
> 3. Thought about a script. Know Korn shell at middle level.
> Nobody prohibits to maintain yet another copy of master zone.
Nobody but zone owner.
> But I don't want to indulge into such remote circumventions.
> 4. That's possible to not bother about the issue but for now
> I am not ready to fold hands.
I just meant that fencing your resolver without really good reasons is
a bad idea. If you do it "just for fun" in production environment, you
should think twice.
>
>
> Peter Andreev wrote:
>
>> Forwarding does not work without recursion enabled.
>>
>> There is a few ways to solve the problem:
>> 1. Using views;
>> 2. Using another dns resolver (for example Unbound);
>> 3. Downloading the zone via script (bad idea from any point);
>> 4. Do not bother where your resolver get authoritative data (I'd
>> recommend this one).
>>
>> Actually, I'm afraid you won't be able to achieve your goal without
>> needless overcomplication.
>>
>> 2012/12/27 Dmitri Tarkhov <tarkhov at dionaholding.ru>:
>>
>>> Well, it's Ok with that. I indeed am the owner of small reverse
>>>
>>> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
>>> named with accordance with rfc2317 CNAME trick and can edit it.
>>> The changes are transferred one way to the ISP side and make part of
>>> their zone "z.y.x.in-addr.arpa". So my changes are seen by the world.
>>> But this small subzone cannot be used for direct reverse resolving right
>>> at my dns. It can only be done at class C (or B, or A) granularity.
>>> So to achieve exactly what I want I need to pull somehow this class C
>>> zone "z.y.x.in-addr.arpa" to my dns. Either as slave zone (which is
>>> denied by ISP) or as forward zone which I cannot tune to work.
>>> May be some other unknown by me approach exists.
>>> Again, there is no problem with reverse resolving in general but
>>> I cannot achieve this directly at my dns, that is to receive a response
>>> from it no matter wherever it forwards the request or from where it
>>> gets the PTR records.
>>>
>>>
>>> Peter Andreev wrote:
>>>
>>>
>>>> Please correct me if I'm wrong: you'd like to edit PTR records for
>>>> your part of the /24 zone?
>>>> If so, what you ISP says about rfc2317?
>>>>
>>>> 2012/12/27 Dmitri Tarkhov <tarkhov at dionaholding.ru>:
>>>>
>>>>
>>>>> Hi,
>>>>> I've searched the list archives and Google and don't see anything
>>>>> to answer my question subj.
>>>>> we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
>>>>> We want to have a master DNS without unnecessary extra functionality.
>>>>> (Including no caching)
>>>>>
>>>>> This is the named.conf with obscured addresses:
>>>>> # cat /dns992/etc/named.conf
>>>>> key "rndc-key" { ... };
>>>>> controls { ... };
>>>>> acl nameservers { A; B; };
>>>>> options { directory "/var/named";
>>>>> allow-query { any; };
>>>>> recursion no;
>>>>> version "Some Server";
>>>>> listen-on { x.y.z.w; };
>>>>> pid-file "/var/run/named.pid";
>>>>> };
>>>>> zone "company" IN { type master;
>>>>> file "company.dat";
>>>>> allow-transfer { nameservers; };
>>>>> };
>>>>> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
>>>>> file "company.rev";
>>>>> allow-transfer { nameservers; };
>>>>> };
>>>>> zone "z.y.x.in-addr.arpa" IN { type forward; forward only;
>>>>> forwarders { intranet.1; }; };
>>>>>
>>>>> //zone "z.y.x.in-addr.arpa" IN { type slave;
>>>>> // file "z_y_x_in-addr.arpa";
>>>>> // masters { A; B; };
>>>>> //};
>>>>>
>>>>> zone "localhost" IN { type master;
>>>>> file "master.localhost";
>>>>> allow-update { none; };
>>>>> };
>>>>> zone "0.0.127.in-addr.arpa" IN { type master;
>>>>> file "localhst.rev";
>>>>> notify no;
>>>>> };
>>>>>
>>>>> Direct resolving works fine. Our subzone is delegated from ISP
>>>>> properly.
>>>>> dig +trace shows due CNAMEs and in general reverse resolving works as
>>>>> well.
>>>>> But I want to achieve reverse resolving on our DNS itself.
>>>>> It is a quite natural desire, to be self sufficient or at least pretend
>>>>> to
>>>>> be,
>>>>> isn't it ...
>>>>> The simplest way to achieve that would be to have a slave zone for the
>>>>> whole
>>>>> class C network x.y.z.0/24 but the ISP don't allow zone transfer.
>>>>> A can understand why transfers of direct zones are limited by security
>>>>> reasons. But reverse zones do not contain any private subdomains or
>>>>> whatever.
>>>>> There is nothing in the reverse zone that cannot be collected by simple
>>>>> queries. And, BTW nothing to hide.
>>>>> Well, another way would be to have a reverse zone for
>>>>> z.y.x.in-addr.arpa
>>>>> of type forward with forward only clause and due forwarders.
>>>>> But it doesn't seem to work. I've tried external forwarders including
>>>>> 8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
>>>>> at "intranet/24".1
>>>>> This internal dns produces perfect reverse resolving but only for
>>>>> internal
>>>>> users, of course the "internals" acl includes the address of external
>>>>> dns.
>>>>> It has this set of options:
>>>>> options {
>>>>> directory "/var/named";
>>>>> forward first;
>>>>> version "not available";
>>>>> forwarders { A; B; };
>>>>> allow-query { internals; };
>>>>> allow-transfer { "none"; };
>>>>> allow-recursion { internals; };
>>>>> listen-on { intranet.1; };
>>>>> };
>>>>>
>>>>> What I have when performing reverse resolving at external dns is:
>>>>>
>>>>>
>>>>>> x.y.z.k
>>>>>
>>>>>
>>>>>
>>>>> Server: x.y.z.w
>>>>> Address: x.y.z.w#53
>>>>>
>>>>> ** server can't find k.z.y.x.in-addr.arpa: REFUSED
>>>>>
>>>>> and setting set d2 in nslookup v9.9.2 doesn't reveal anything
>>>>> catching attention although I see that there is an attempt to
>>>>> contact the forwarder.
>>>>>
>>>>> trying origin "company.internal" (obscured as well)
>>>>> recursive query
>>>>> add_question()
>>>>> starting to render the message
>>>>> done rendering
>>>>> create query 0x402a4010 linked to lookup 0x82168c0
>>>>> do_lookup()
>>>>> send_udp(0x402a4010)
>>>>> bringup_timer()
>>>>> have local timeout of 5
>>>>> working on lookup 0x82168c0, query 0x402a4010
>>>>> sockcount=1
>>>>> recving with lookup=0x82168c0, query=0x402a4010, sock=0x402a5008
>>>>> recvcount=1
>>>>> sending a request
>>>>> unlock_lookup dighost.c:3530
>>>>> lock_lookup dighost.c:2328
>>>>> success
>>>>> send_done()
>>>>> sendcount=0
>>>>> check_if_done()
>>>>> list empty
>>>>> unlock_lookup dighost.c:2357
>>>>> recv_done()
>>>>> lock_lookup dighost.c:3053
>>>>> success
>>>>> recvcount=0
>>>>> lookup=0x82168c0, query=0x402a4010
>>>>> before parse starts
>>>>> after parse
>>>>> next_origin()
>>>>>
>>>>> So for some reason the list is empty and recvcount=0 in the second
>>>>> occasion.
>>>>> From the same shell, from the very same nslookup instance with
>>>>>
>>>>>
>>>>>> server <local dns>
>>>>>
>>>>>
>>>>>
>>>>> the reverse lookup is OK.
>>>>>
>>>>> And of course I am more interested in some working solution than
>>>>> digging in subtleties of traces provided that I don't need to
>>>>> allow recursion and forward in general options section for
>>>>> my external dns.
>>>>>
>>>>> I look forward for any suggestions, working examples, corrections,
>>>>> sources of indepth information. TIA.
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Dmitri Tarkhov
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Best regards,
>>> Dmitri Tarkhov
>>>
>>
>>
>>
>>
>
> --
> Best regards,
> Dmitri Tarkhov
>
--
AP
More information about the bind-users
mailing list