Hi,
first of all thanks to everyone for the interest and for pointing me
out my mistakes :) I've already changed recursion and transfer to
trusted acls. But unfortunately, I've been administering this server
for a short time and as I'm reading more and more through the
configuration, I'm starting to think that this DNS server is
completely misconfigured. Before I ask my next question, I'll try to
explain my situation a little:
The server I'am administering is one of nine, let's say, units,
which are parts of bigger organization (let's say organization.com, it
doesn't really matter). They units are given domain names from
first.organization.com to ninth.organization.com. Each unit's server
is responsible for their subdomains, i.e. a.first.organization.com,
b.first.organization.com, and so on... At the same time, they should
be synchronized with the main dns server of the organization, let's
say dns.organization.com, and also act as a dns server of it's own,
providing information about i.e. for first, *.first.organization.com.
I think my name cannot be resolved after some time problem
(NXDOMAIN, I've checked it) lies somewhere in the synchronization
part. I'll post a part of my zone file, which is responsible for the
domain and which is, I think, the source of this problem:
***
$TTL604800
@ IN SOA dns.organization.com. first.organization.com. (
2006120508 ; Serial
3600 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
NS first.organization.com.
NS dns.organization.com.
***
The problem is, I don't even know if *I* should synchronize with
*them* (the main dns server) or vice versa, maybe it's not my problem
at all. Also, who should I allow-update {} the zone, should the zone
be of type master and what is the authoritative server for the zone:
the one I'm administering or the main dns server or maybe both are ok?
Thanks in advance:)
On Wed, Nov 11, 2009 at 7:09 PM, Jeff Lightner jlight...@water.com wrote:
I can't quite agree with that.
While public information is indeed public it is intended to be so for
specific lookups not for zone transfers. Someone external to you asking get
a zone transfer may be looking for what he can exploit. Maybe he can find
that information anyway with enough digging but why make it easy for him?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
Sent: Wednesday, November 11, 2009 12:53 PM
To: bind-users@lists.isc.org
Subject: Re: bind configuration help
Holger Honert wrote:
Security issues!
Usually you only want *trusted* clients to use your server recursively.
And you don't really want to allow *any* fetching your hosted zones
for doing something bad, i.e. getting (unwanted!) infos
over your network and infrastructure.
If the infos are public, they're public, the only difference is that
zone transfers are a more efficient way of fetching more than about 2 or
3 records in a single transaction, compared to querying each one
individually.
If you want your network and infrastructure infos to be private, then
put them in a private zone that can't be queried from the Internet at all.
- Kevin
Regards
Holger
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or
allow any transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
___
bind-users mailing list
