2012/12/27 Dmitri Tarkhov <tark...@dionaholding.ru>:
> 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?
You are trying to cut some ways of information obtaining for resolver.
That is what I mean.
>
> In fact I want to do so because I want to protect it from
> cache poisoning and any other attack of forge nature.
I can't say these attacks are very common. Actually I can't recall any
cases of such attacks in a wild nature. Also, in-addr.arpa isn't a
good target.
As for now the best defence against cache poisoning is DNSSec and
since we have signed all russian TLDs you could implement it.
>
>
> Peter Andreev wrote:
>
>> 2012/12/27 Dmitri Tarkhov <tark...@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 <tark...@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 <tark...@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@lists.isc.org
>>>>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Dmitri Tarkhov
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Best regards,
>>> Dmitri Tarkhov
>>>
>>
>>
>>
>>
>
> --
> Best regards,
> Dmitri Tarkhov
>
--
AP
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
