reverse zone of type forward when /28 subnet
Dmitri Tarkhov
tarkhov at dionaholding.ru
Thu Dec 27 13:06:44 UTC 2012
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.
2. Sorry, "Unbound" - is it just another dns server?
3. Thought about a script. Know Korn shell at middle level.
Nobody prohibits to maintain yet another copy of master zone.
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.
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
More information about the bind-users
mailing list