reverse zone of type forward when /28 subnet

Peter Andreev andreev.peter at gmail.com
Thu Dec 27 10:36:15 UTC 2012


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



-- 
AP



More information about the bind-users mailing list