reverse zone of type forward when /28 subnet
Mark Andrews
marka at isc.org
Thu Dec 27 19:18:13 UTC 2012
In message <50DC2B79.1040502 at dionaholding.ru>, Dmitri Tarkhov writes:
> 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.
RFC 2317 style delegations are for convience as they reduce the
number of zones that need to be configured. If your ISP won't
permit the transfer of the parent zone, which prevents local reverse
lookups working when the upstream link is broken, you should revert
to traditional delegations. That is 1 zone per IP address.
Note any ISP that prevents the parent zone being transfered to the
customer, when doing RFC 2317 style delegations, doesn't know what
they are doing as they are forcing you to run a configuration that
depends upon the link working 100% of the time.
Mark
zone "241.Z.X.Y.IN-ADDR.ARPA" {
type master;
file "241.Z.X.Y.IN-ADDR.ARPA";
};
...
zone "255.z.x.y.IN-ADDR.ARPA" {
type master;
file "255.Z.X.Y.IN-ADDR.ARPA";
};
241.z.x.y.IN-ADDR.ARPA:
@ 3600 SOA .....
@ 3600 NS ....
@ 3600 NS ....
242.z.x.y.IN-ADDR.ARPA:
@ 3600 SOA .....
@ 3600 NS ....
@ 3600 NS ....
@ 3600 PTR ....
...
255.z.x.y.IN-ADDR.ARPA:
@ 3600 SOA .....
@ 3600 NS ....
@ 3600 NS ....
> 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 whol
> e
> >>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
>
> _______________________________________________
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list