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 <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
_______________________________________________
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
