2012/12/27 Dmitri Tarkhov <tark...@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 <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 >>> >> >> >> >> > > -- > 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