Date: Mon, 25 Mar 2002 16:32:30 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Tim <tim@sleepy.wojomedia.com>, chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <3C9FC19E.9BAC6FB8@mindspring.com> References: <p05101505b8c430e28572@[10.0.1.9]> <000c01c1d3ab$6d2c6960$6600a8c0@penguin> <p05101509b8c47b17d088@[10.0.1.8]> <20020325015236.A97552@futuresouth.com> <p0510150eb8c48ba6b1f4@[10.0.1.8]> <3C9EFED0.DB176CB8@mindspring.com> <20020325115207.GA22032@sleepy.wojomedia.com> <3C9F1A16.207EA23E@mindspring.com> <20020325140022.GA23251@sleepy.wojomedia.com> <3C9FB0CB.C1C0CD89@mindspring.com> <20020325234504.GA31239@sleepy.wojomedia.com> <3C9FBE01.DE7FFFB4@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > It's not necessary to maintain teh consistency across the update > window for newly created zones. Specifically, it's OK if the > secondary contains an empty record that simply means that it is > a secondary, and a zone transfer from the primary is needed. > > The issue is that there is an update window. If I miss the update > window on the primary, I'm not going to be able to hit it again for > the update interval on the primary anyway, at which time the data is > re-derived (DNSUPDAT to the primary fixes that, actually, but I did > not use it in the design cited). > > The failure is safe because of the automatic replication of > data from the primary to the secondary. It occurs to me that it's not obvious from this discussion so far what I meant about the number of lines of code in the earlier discussion of using DNSUPDAT to do zone creation on the secondary. The primary issue in the number of lines of code in the earlier discussion was not to establish the security association, which can actually be done rather trivially; instead it was because the DNSNOT notification for a newly created zone via DNSUPDAT would need to result in a creation without a preexisting contact between the servers, to cover the case wehre the secondary delegation is to a transiently connected server on the customer premesis (these days, "DSL" qualifies as a transient connection, from my personal experience with a large customer base). The problem is that these things are UDP, and you have an order of operation issue that you have to resolve, without introducing a stall in the DNSUDAT of the primary. Basically, if you have a primary, and you set up a zone that designates a secondary, and the secondary is unaware of its responsibility at the time of the zone creation, then you need to notify the secondary in a way that it trusts that it is now secondary for the delegation. At the same time, you need to make sure that the not just anyone can elect you a secondary for their zone by being their own primary and then pointing at you, so you have to have a security association. The djbdns method of achieving this result is to move the complexity to some out of band mechanism involving per scripts, rdist, and a human being (that last component is the one with the lowest MTBF 8-)), and it still leaves the update of an active server to a reload operation, instead of an update. Realize that a fully distributed DNSUDAT mechanism capable of zone creation in both primary and secondary server resolves all race windows in a way that a manually replicated set of primaries could never hope to do. As usual, the work will happen eventually (but not now). Until then, we have to close the race windows with overlap, rather than with elimination. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C9FC19E.9BAC6FB8>