Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Oct 2001 13:13:25 +0200 (CEST)
From:      "Patrick M. Hausen" <hausen@punkt.de>
To:        Jan Mikkelsen <janm@transactionware.com>
Cc:        =?ISO-8859-1?Q?David_Sieb=F6rger?= <drs-stable@rucus.ru.ac.za>, Ingeborg Hellemo <Ingeborg.Hellemo@cc.uit.no>, freebsd-stable@FreeBSD.ORG
Subject:   Re: Reverse delegation of CIDR addresses (was: sdflkj)
Message-ID:  <200110041113.f94BDPp70487@hugo10.ka.punkt.de>
In-Reply-To: <013201c14cc1$68b05430$0a01a8c0@mosm1>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110041113.f94BDPp70487>