reverse zone of type forward when /28 subnet
Dmitri Tarkhov
tarkhov at dionaholding.ru
Thu Dec 27 13:59:36 UTC 2012
Ok, thank you,
I'll try views first of all.
And I need some further clarification about this:
> I just meant that fencing your resolver without really good reasons is
> a bad idea.
By "fencing your resolver" do you mean converting a dns
server into only a source of information from its master zones
cutting severely any unnecessary functionality or anything else?
What is a bad idea and why?
In fact I want to do so because I want to protect it from
cache poisoning and any other attack of forge nature.
Peter Andreev wrote:
> 2012/12/27 Dmitri Tarkhov <tarkhov at dionaholding.ru>:
>
>>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.
>
>
> Actually, forwarding also doesn't work for queries without RD bit.
> Such queries are being sent by resolver in normal circumstances.
>
>
>>2. Sorry, "Unbound" - is it just another dns server?
>
>
> Yep, it is recursive-only dns server. It has an option called
> "local-zone", which is absolutelly what you are looking for. Note that
> Unbound has very limited capabilities to support authoritative data.
>
>
>>3. Thought about a script. Know Korn shell at middle level.
>> Nobody prohibits to maintain yet another copy of master zone.
>
>
> Nobody but zone owner.
>
>
>> 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.
>
>
> I just meant that fencing your resolver without really good reasons is
> a bad idea. If you do it "just for fun" in production environment, you
> should think twice.
>
>
>>
>>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
>>
>
>
>
>
--
Best regards,
Dmitri Tarkhov
More information about the bind-users
mailing list