reverse zone of type forward when /28 subnet

Dmitri Tarkhov tarkhov at
Thu Dec 27 11:05:29 UTC 2012

Well, it's Ok with that. I indeed am the owner of small reverse
zone "" 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 "". 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 "" 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>:
>>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/";
>>zone "company" IN { type master;
>>        file "company.dat";
>>        allow-transfer { nameservers; };
>>zone "" IN { type master;
>>        file "company.rev";
>>        allow-transfer { nameservers; };
>>zone "" IN { type forward; forward only;
>>        forwarders { intranet.1; }; };
>>//zone "" IN { type slave;
>>//        file "";
>>//        masters { A; B; };
>>zone "localhost" IN { type master;
>>        file "master.localhost";
>>        allow-update { none; };
>>zone "" 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
>>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
>>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
>>of type forward with forward only clause and due forwarders.
>>But it doesn't seem to work. I've tried external forwarders including
>> + 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:
>>Server:         x.y.z.w
>>Address:        x.y.z.w#53
>>** server can't find 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
>>starting to render the message
>>done rendering
>>create query 0x402a4010 linked to lookup 0x82168c0
>>have local timeout of 5
>>working on lookup 0x82168c0, query 0x402a4010
>>recving with lookup=0x82168c0, query=0x402a4010, sock=0x402a5008
>>sending a request
>>unlock_lookup dighost.c:3530
>>lock_lookup dighost.c:2328
>>list empty
>>unlock_lookup dighost.c:2357
>>lock_lookup dighost.c:3053
>>lookup=0x82168c0, query=0x402a4010
>>before parse starts
>>after parse
>>So for some reason the list is empty and recvcount=0 in the second
>>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 to
>>unsubscribe from this list
>>bind-users mailing list
>>bind-users at

Best regards,
Dmitri Tarkhov

More information about the bind-users mailing list