From owner-freebsd-chat Mon Mar 25 4:38:21 2002 Delivered-To: freebsd-chat@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 1ADAF37B416 for ; Mon, 25 Mar 2002 04:38:14 -0800 (PST) Received: from pool0008.cvx40-bradley.dialup.earthlink.net ([216.244.42.8] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16pTjj-0004T1-00; Mon, 25 Mar 2002 04:38:07 -0800 Message-ID: <3C9F1A16.207EA23E@mindspring.com> Date: Mon, 25 Mar 2002 04:37:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) References: <000c01c1d3ab$6d2c6960$6600a8c0@penguin> <20020325015236.A97552@futuresouth.com> <3C9EFED0.DB176CB8@mindspring.com> <20020325115207.GA22032@sleepy.wojomedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tim wrote: > I do have a question though: > > > It was not > > a problem to do the updates of the primary and secondary > > seperately, following an update of the database from which > > the domain data placed in the configuration files was derived, > > since there is implicit fail-over support based on having a > > hierarchical relationship between servers. With Dan's > > arrangement, the secondary answering in the negative is cached > > as authoritative, and the dmaon is off the air for at least > > another 300 seconds (if not longer), as that's the minimum > > default cache expiration time that most ISPs run on their > > caching name servers. > > Can you explain this further? I've read it about 5 times and I am > not sure I understand exactly. I was afraid this might become a question. It boils down to understanding derived data files, and some deep DNS voodoo. To create a zone in a secondary bind server, you have to list the zone in the secondary's list of zones for which it is a secondary, and therefore performs periodic zone transfers. If you are adding a domain to a virtual hosting system that includes DNS service for the domain, and the primary data source is actually a database, then daemon configuration files are actually derived data from the database. What that means is that when I add a new zone to the database, for it to take effect, I have to add it to the DNS servers. For the primary, I can relax the rule on zone creation via DNSUPDAT, and do it in software, without an interruption of service. But for a secondary, it is not possible to do the same thing, because of the semantics of the security policy. In other words, you are allowed to relax the rules for zone creation on a primary DNS server, but doing so on a secondary can't be done. What you could do, if you truly wanted to solve this problem, would be to establish a security association between the primary and the secondary. Then, if you trusted the primary not to send bogus zone creation requests to you, the secondary, you could piggyback the zone creations on the security association for a domain you already know about (the easiest one to use would be the domain for the hosting facility itself, if it were self-hosted in the same DNS). In practice, making this work would have been around 300 lines of code for a piggyback, and about 850 lines of code, if you wanted to add a new update type for "create zone in secondary" that would have to use a seperate security association for the created. Instead, what we did was just stagger the updates, and derive both the primary and secondary server from the central database, and then kick the DNS servers on both machines in the head. So we didn't use DNSUDAT, and we didn't hack bind or security code. Because the update-from-database-and-kick-in-the-head (SIGHUP) were staggered, it meant that the primary and secondary servers were never offline at the same time. This means that the worst case failure would be the client having to send a request, time out, and send another request to another server. The secondary update was staggered to occur after the primary; what this meant was that there would be an immediate zone transfer from the primary for the new zone in the secondary, so the only data that needed updating was the zone record itself. Everything else happened on the primary. Because the secondary was subservient in the hierarchy, the replication of the data to the secondary was automatic, and guaranteed correctness. In the djbdns case, both would be primary, and one might contain stale data relative to the other (e.g. a bad serial number) because the configuration data was derived. The 300 second timeout enforced by caching DNS servers (in violation of the RFC, but it's common practice) meant that if a client hit at the wrong time, everyone on the wrong side of the caching DNS server might have a negative cache entry for 5 minutes, using the djbdns approach (e.g. "don't bother me; the domain doesn't exist; believe me, I'm authoritative") plus however long the delay was in replicating the data, plus the delay for a kick-in-the-head to take effect. We had a 30 minute stagger, so it was a good 40+ minut window in which someone could be off the air, if they made a request through a cache at just the right time. This was really unacceptable for customers. If the DNS load had ever strained a machine, we could have gone to a "stealth primary". This is wehre you list the secondary servers as the primary and secondaries in the domain registration, so their delegation out of ".com" or whatever doesn't reference your primary. Then the primary does absolutely nothing but handle zone updates and referrals for unknown domains during the window between the primary update and the secondary update, when someone is hitting a delegation. Really, you want to be able to turn around a preliminary domain registration within a browser timeout, and have the customer functional. For something like an email hosting service, it's pretty stupid to communicate DNS registration stuff to a mailbox other than one you are hosting: if they have email service, then why the heck would they need to buy it again from you? The same goes for other service registration: sending them back to a competitor, over and over again, to comunicate with you is a lose-lose proposition. You might as well buy a gun and start engraving the word "foot" into your bullets, so they know where they are supposed to go. 8-). Unfortunately, the domain registrars aren't very cooperative when it comes to deploying dynamic update protocols, even if you are IBM doing the asking. It's really annoying. There are workarounds for the sneaky, but they require dead chickens and other dark talismans. ;^). DNS registration is like the old phone company slogan from the fortunes database: "We don't care. We don't have to. We're the phone company." -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message