Date: Mon, 25 Mar 2002 18:25:28 +0100 From: Brad Knowles <brad.knowles@skynet.be> To: Terry Lambert <tlambert2@mindspring.com>, Tim <tim@sleepy.wojomedia.com> Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <p05101517b8c509834501@[10.0.1.8]> In-Reply-To: <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> <3C9F1A16.207EA23E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:37 AM -0800 2002/03/25, Terry Lambert wrote: > 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. Right, this is the /etc/named.conf file (or #include'd from it). Indeed, this really isn't any different on the primary than it is on the secondary. > 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. Do you mean that the primary is directly using the database, and not the standard /etc/named.conf files? > 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. Right. > 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. Once you start using DNSUPDATE (assuming you're doing so based on cryptographic keys), you can't use manual administrative methods on the same server. With BIND 8, you could kind of hack this by shutting the server down and having it flush all its updated zones back to the configuration files and the zone files, but this doesn't work with BIND 9. > 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. Sure. Secondaries can forward updates to primaries that they are configured to know about, as well as to other servers that they are configured to send them to. You can do the same from the primary perspective using "also-notify". > 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). Using cryptographic keys, you can make this part of the process as trustworthy as the original update. > 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. This also works. We did this sort of thing at my previous employer, although we used a stealth primary and the advertised servers were secondaries of the internal primary. > Really, you want to be able to turn around a preliminary > domain registration within a browser timeout, and have the > customer functional. Absolutely. > 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." Sadly, this is very true. Indeed, the problem is even worse. According to the RFCs (including RFC 2870, "Root Name Server Operational Requirements", see <http://www.faqs.org/rfcs/rfc2870.html>), root nameservers are supposed to be authoritative-only, in part to avoid cache pollution problems, etc.... Now, you would think that the same requirements would apply to all TLD nameservers around the world. Unfortunately, this is not true. It turns out that ns.eu.net is one of the advertised authoritative nameservers for something like 72 TLDs (mostly ccTLDs), and not only is it also a public recursive caching nameserver (i.e., anyone can ask it any question and it will try to obtain the appropriate information and provide it to you), it also allows zone transfers. So, if you want to screw up any of these domains, you can get a zone transfer of the entire domain, and then using knowledge of cache pollution techniques, you can then hijack the entire domain. This kind of thing basically puts the entire Internet at serious risk. Now, you would think that the authors of the above RFC would care about this kind of problem. And one of the authors (D. Karrenberg) is the head of the RIPE NCC, so he would be in an ideal position to do something about it. However, when I asked him, it didn't seem to bother him a bit that this was going on. Now there is hypocrisy and apathy for you, from the kind of guy you would think should care most about these kinds of problems. -- Brad Knowles, <brad.knowles@skynet.be> Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook page at <http://www.rodos.net/outlook/>; and see how much fun you can have. "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. 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?p05101517b8c509834501>