Date: Mon, 25 Mar 2002 04:37:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Tim <tim@sleepy.wojomedia.com> Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <3C9F1A16.207EA23E@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C9F1A16.207EA23E>