From owner-freebsd-stable Thu Oct 4 4:14:10 2001 Delivered-To: freebsd-stable@freebsd.org Received: from hugo10.ka.punkt.de (kagate.punkt.de [194.77.232.254]) by hub.freebsd.org (Postfix) with ESMTP id A822F37B407 for ; Thu, 4 Oct 2001 04:14:04 -0700 (PDT) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.11.4/8.11.4) id f94BDPp70487; Thu, 4 Oct 2001 13:13:25 +0200 (CEST) (envelope-from ry93) From: "Patrick M. Hausen" Message-Id: <200110041113.f94BDPp70487@hugo10.ka.punkt.de> Subject: Re: Reverse delegation of CIDR addresses (was: sdflkj) In-Reply-To: <013201c14cc1$68b05430$0a01a8c0@mosm1> To: Jan Mikkelsen Date: Thu, 4 Oct 2001 13:13:25 +0200 (CEST) Cc: =?ISO-8859-1?Q?David_Sieb=F6rger?= , Ingeborg Hellemo , freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL92 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all! Though this is way off topic, I feel urged to add in my 2 cents. Any suggestions, where to take this discussion? firewall-wizards? ;-) Jan Mikelsen wrote: > While the example from the original URL is wrong, as is pointed out in this > quote, that doesn't mean that you must use CNAMEs to accept reverse > delegation. There is a better way. > > (There may be BIND syntax errors here; I use djbdns now, where everything > is much better). > > For example, on the parent server: > > 4.3.2.1.in-addr.arpa. IN NS a.ns.4.3.2.1.in-addr.arpa. > 4.3.2.1.in-addr.arpa. IN NS b.ns.4.3.2.1.in-addr.arpa. > a.ns.4.3.2.1.in-addr.arpa. IN A 5.6.7.8 > b.ns.4.3.2.1.in-addr.arpa. IN A 5.6.7.9 > > and on the child server: > > 4.3.2.1.in-addr.arpa. IN SOA blah blah ; see, syntax error right there > 4.3.2.1.in-addr.arpa. IN NS a.ns.4.3.2.1.in-addr.arpa. > 4.3.2.1.in-addr.arpa. IN NS b.ns.4.3.2.1.in-addr.arpa. > a.ns.4.3.2.1.in-addr.arpa. IN A 5.6.7.8 > b.ns.4.3.2.1.in-addr.arpa. IN A 5.6.7.9 > 4.3.2.1.in-addr.arpa. IN PTR 4.3.2.1 > > Add additional nameservers as required. First, here's what we do - as an ISP - for/with our customers: 1. Urge customers to use a hidden primary setup with our nameservers as the official ones, if they want manage their own zones. Reason: when they mess up their setup and the respobsible person at their site is out of town, sick, or not accessible for some other reason, we can quickly change slave zones for master zones on our servers until they fixed everything. 2. When they want to manage their own PTR records, use RFC 2317. Reason: standardized, reliable, works well with 1, in case they still mess up. Now, let's compare the amount of entries it takes with a typical /29 delegation for one of our customers: RFC 2317: On our server: entries in one existing zone, namely 3 NS records for the new zone 7 CNAMEs 1 additional slave zone on 3 servers On their server: one master zone, containing 1 SOA record 3 NS records 8 PTR records Your proposal: On our server: entries in one existing zone, namely 24 NS records for the new zones 8 additional slave zone on 3 servers On their server: eight master zones, containing 1 SOA record 3 NS records 1 PTR record This looks like a lot of trouble to me compared to RFC 2317. Our zones are centrally managed and pushed to all servers. So setting up a slave zone requires adding one line to the master setup file and one call of "make". Adding a master zone requires adding a zonefile, of course. Did I miss a point? Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100 76135 Karlsruhe http://punkt.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message