Prev: "Display-name" rewriting
Next: client certificate handling with TLS + sasl
From: LuKreme on 25 Feb 2010 14:36
On 25-Feb-2010, at 05:35, Larry Stone wrote:
>
> example.com. 60 IN MX 10 mail.example.com.
>
> where the 60 is the time-to-live in seconds and the 10 is the priority.

Er, that's not what my MX looks like at all in bind9.


MX 10 mail.example.com.

all the TTLs are set in the SOA line up at the top of the file.

<http://tldp.org/HOWTO/DNS-HOWTO-7.html>

Scroll to 7.4 and that's very similar to what my zone file looks like. What every zone file I've ever dealt with looks like, in fact (and that many thousands over the years)

--
Charlie don't surf!

From: brian moore on 25 Feb 2010 15:22
On Thu, 25 Feb 2010 12:08:03 +1100
Adrian Overbury <adrian(a)inomial.com> wrote:

> I think that there's an important step here that I always use when I'm
> doing a mail migration. It could really go anywhere above the 'wait for
> a Friday night' step, really. "Reduce the TTL on the domain to
> something quite small, ie: 5 minutes." The point of this is that you'll
> get an idea rather quickly of whether or not it works and, if it
> doesn't, you'll be able to change it back without a portion of the users
> experiencing long downtimes because of DNS records pointing to the wrong
> server.

Let's see if I remember the steps I had to use a few years ago when
we took over an ISP with an aging server across town. Since the server needed
to be replaced anyway, I think I did the following:

1) Install pop3/imap proxy on new server. I used perdition for this.
I set so that users not in a database would be proxied back to the old
server, others would be proxied to 127.0.0.1 where the "real" pop3/imap
daemons were bound.

2) Set a transport in postfix to send all mail for that domain to their old server.

3) Change DNS to insert myself in the middle of every pop3/imap/smtp/etc transaction.

(Wait for DNS to propogate, play games, do whatever.)

Now the fun of moving the users!

I set up a per-user transport db: I think I made the default be "forward to old server"
for the domain, and "local" transport for users specifically listed.

I set up a 'move a single user' script that would do the following (again, it's been 9
years, so I may be forgetting something):

. Set user to 'deferred' mailer (remember i had that nifty per-user transport!)
. rsync any .forward on old server to new server
. set .forward on old server to point to new server (the old server ran icky sendmail,
so I had limits on trickery there.. postfix is much easier to abuse with
strange rulesets. this was so any mail that somehow made it to the old server
would come to the new one instead of getting in their inbox.

Now at this point, all mail will funnel back to newserver where it will get into
the deferred queue.

, rsync users mailbox from old server to new server
. set perdition to send that user to new server instead of old
. set transport for that user to be 'local'.

That as I recall is all I did, well that and running the 'move a single user' a few
thousand times, though almost always in large clusters like "all the A users".

Eventually I removed perdition and made pop3/imap answer on the real interfaces
as well as localhost as well as removing the transport map.

I think I'm missing a step in there somewhere, but damned if I remember what it
was.

The result was something like 5200 users moved and not a single user noticed.

YMMV, users with persistant IMAP connections would have problems with this method
no doubt. POP3 users are pretty simple to move.

From: Larry Stone on 25 Feb 2010 15:52
On Thu, 25 Feb 2010, LuKreme wrote:

> On 25-Feb-2010, at 05:35, Larry Stone wrote:
>>
>> example.com. 60 IN MX 10 mail.example.com.
>>
>> where the 60 is the time-to-live in seconds and the 10 is the priority.
>
> Er, that's not what my MX looks like at all in bind9.
>
>
> MX 10 mail.example.com.
>
> all the TTLs are set in the SOA line up at the top of the file.

This is off-topic for this list but many of the fields in a Resource
Record are optional and if not stated, use defaults including values
specified earlier in the zone file. In your example, you have not
specified the NAME (example.com.) which defaults from the last NAME
specified on a resource record, the CLASS (which I believe always defaults
to IN), and the TTL, which defaults to the default value you, as you have
said, have specified earlier.

My example is "complete" and does not rely on any defaults. It will always
work regardless of what default values have been set earlier in the zone
file.

> <http://tldp.org/HOWTO/DNS-HOWTO-7.html>
>
> Scroll to 7.4 and that's very similar to what my zone file looks like.
> What every zone file I've ever dealt with looks like, in fact (and that
> many thousands over the years)

I don't know that site but it appears their examples rely on defaults
without telling you that's what they're doing. As a result, some of the
resource records are dependent on their ordering. You cannot reorder the
records in "workstations" section of their example without risk of
breaking things as each MX record defaults the NAME from the previous A
record.

I've always relied on the O'Reilly "DNS and Bind" book. It has not steered
me wrong yet.

-- Larry Stone
lstone19(a)stonejongleux.com

First  |  Prev  | 
Pages: 1 2
Prev: "Display-name" rewriting
Next: client certificate handling with TLS + sasl