reverse zone of type forward when /28 subnet

Thu Dec 27 11:05:29 UTC 2012

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