On Tue, Apr 17, 2001 at 11:15:03PM -0500, will trillich wrote: > how do you manage the migration?
Somewhat painfully... Basically, I've set up the firewall to route between the three internal IP ranges in use and (once I've got the kinks worked out of that) my plan is to, as each user machine needs to be touched, change its IP address, add it to the appropriate west/east.company.com zone, and make its old company.net DNS entry into a CNAME pointed at the new name. It's kinda ugly, it'll take a good while to complete, but it should work great once I get the routing to work right. > i've got > > /etc/bind/ > serensoft > serensoft.rev > lan > lan.rev Let's see... In the name server's /etc/bind, I have company.net, company.com, east.company.com, west.company.com, their corresponding reverse zones (which, incidentally, I generate automagically using a perl script called mkrdns-2_0pre2, which I think I found on freshmeat - it makes life much easier...), and, of course, the standard db.0/127/255/local/root that debian installs with the package. > ERROR: "mail.serensoft.com. A 208.33.90.85", but the PTR record for > 85.90.33.208.in-addr.arpa. is "ns.serensoft.com." > One of the above two records are wrong unless the host is a name > server or mail server. > To have 2 names for 1 address on any other hosts, replace the A record > with a CNAME record: > mail.serensoft.com. IN CNAME ns.serensoft.com. Technically, you're only supposed to have one A record per IP address and every A should have a corresponding PTR in the reverse zone. dlint is complaining because your ns's reverse lookup points to the IP address in mail's A record. In theory, if you want multiple names pointing to the same IP, exactly one of those names should have an A record and all the others should be CNAMEs pointing to it. In this case, you would have to do that by making mail a CNAME to ns (just like the example entry dlint suggested) and changing all your MX records to point at ns instead of mail. (IIRC, NS and MX records are required to point to A records, not CNAMEs. If you break this rule, it will still work, but hostmasters the world over will be plagued with warnings from BIND that say things like named[2795]: ns_forw: query(10.73.147.206.in-addr.arpa) NS points to CNAME (www.arcc.org:) learnt (CNAME=206.147.75.5:NS=137.192.240.3) The other way around this, if you have an IP address or two to spare, would be to set up IP aliasing in your kernel and give the machine a separate IP address for each service. Or at least for mail. Other services can be easily split apart by just changing the name's DNS entry, but for a mail server, you have to track down all the MXes pointing at it and change them also (since they shouldn't point to CNAMEs). > WARNING: the zone serensoft.com. has an A record but no reverse PTR record. > This is probably OK. Like it says, that's probably OK. Unless you want to have an IP address with a null hostname in your domain, this is inevitable. And null hostnames are rare enough that I don't know why dlint would bother to complain about this. > and i'd like > 208.33.90.85 to be serensoft.com eth1, visible everywhere (as > it already is) > 192.168.1.100 to be mac.serensoft.com > but invisible to the outside net, and > it should be able to ping win.serensoft.com > 192.168.1.200 would be win.serensoft.com > which is not visible to the outwise world > 192.168.1.1 to be server.serensoft.com eth0, internal-lan only Like Patrick suggested, you'll pretty well need to run dual name services. AFAICT, there isn't any way to tell BIND to resolve a name only for eth0, but not for eth1. ISTR that some lesser-known DNS server(s?) has this ability, but that's all I could tell you about it. Using serensoft.com externally and foo.serensoft.com internally complicates things a little, too. Unless I'm mistaken, it means that you'll have to maintain two independent zone files (one containing only serensoft.com's external address and one with everything), but I'd say you probably want to do that anyhow so that, for the internal machines, serensoft.com resolves to that machine's internal address instead of its external address. > how to i separate the internal/private 'no-update' addresses from > the public 'update'-able addresses, in bind/dns? What do you mean by "update"? -- That's not gibberish... It's Linux. - Byers, The Lone Gunmen Geek Code 3.1: GCS d? s+: a- C++ UL++$ P++>+++ L+++>++++ E- W--(++) N+ o+ !K w---$ O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv b+ DI++++ D G e* h+ r y+
