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 <tark...@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 <tark...@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@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >> >> >> >> >> > > -- > Best regards, > Dmitri Tarkhov > -- AP _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users