reverse zone of type forward when /28 subnet
Peter Andreev
andreev.peter at gmail.com
Thu Dec 27 12:30:09 UTC 2012
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
>
--
AP
More information about the bind-users
mailing list