bind configuration help

Wed Nov 11 23:32:40 UTC 2009

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:

***
$TTL    604800
@       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 <jlightner at 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-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Kevin Darcy
> Sent: Wednesday, November 11, 2009 12:53 PM
> To: bind-users at 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 <lcaron at 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 at 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
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> Proud partner. Susan G. Komen for the Cure.
>
> Please consider our environment before printing this e-mail or attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>