t;[EMAIL PROTECTED]>
To:
Sent: Sunday, June 20, 2004 5:19 PM
Subject: Re: how to relocate servers transparently
...
Can you explain that a little further? If my nameserver caches a record with
TTL 86400, and someone asks for it again an hour later I hand them the record
from my cache
On Jun 20, 2004, at 9:19 AM, Fraser Campbell wrote:
On June 18, 2004 12:49 am, Nate Duehr wrote:
No, this isn't right. You must lower the TTL time at a bare minimum
2 *
(Current TTL) ahead of time. Why? Because nameservers out in the
real
world will not even query your nameservers again until
t;[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 20, 2004 5:19 PM
Subject: Re: how to relocate servers transparently
...
Can you explain that a little further? If my nameserver caches a record with
TTL 86400, and someone asks for it again an hour later I hand them the
On Jun 20, 2004, at 9:19 AM, Fraser Campbell wrote:
On June 18, 2004 12:49 am, Nate Duehr wrote:
No, this isn't right. You must lower the TTL time at a bare minimum
2 *
(Current TTL) ahead of time. Why? Because nameservers out in the
real
world will not even query your nameservers again until
On June 18, 2004 12:49 am, Nate Duehr wrote:
> No, this isn't right. You must lower the TTL time at a bare minimum 2 *
> (Current TTL) ahead of time. Why? Because nameservers out in the real
> world will not even query your nameservers again until the TTL has
> expired, meaning that if you chan
On June 18, 2004 12:49 am, Nate Duehr wrote:
> No, this isn't right. You must lower the TTL time at a bare minimum 2 *
> (Current TTL) ahead of time. Why? Because nameservers out in the real
> world will not even query your nameservers again until the TTL has
> expired, meaning that if you chan
Rhesa Rozendaal wrote:
So here is what we'll do:
- Lower the ttl on all zones three days before the move
No, this isn't right. You must lower the TTL time at a bare minimum 2 *
(Current TTL) ahead of time. Why? Because nameservers out in the real
world will not even query your nameservers agai
Rhesa Rozendaal wrote:
So here is what we'll do:
- Lower the ttl on all zones three days before the move
No, this isn't right. You must lower the TTL time at a bare minimum 2 *
(Current TTL) ahead of time. Why? Because nameservers out in the real
world will not even query your nameservers agai
man, 14.06.2004 kl. 17.22 skrev Andreas John:
> Hello Adrian!
>
> NAT is only working with IPs "directly connected" to your ethernet card.
> or NAT-ed IPs not arbitrary ones.
>
> Or?
>
> rgds,
> j.
As NAT is done on the IP-layer, iptables doesn't care about ethernet and
other (MAC layer) stuff
man, 14.06.2004 kl. 17.22 skrev Andreas John:
> Hello Adrian!
>
> NAT is only working with IPs "directly connected" to your ethernet card.
> or NAT-ed IPs not arbitrary ones.
>
> Or?
>
> rgds,
> j.
As NAT is done on the IP-layer, iptables doesn't care about ethernet and
other (MAC layer) stuff
Hello Adrian!
NAT is only working with IPs "directly connected" to your ethernet card.
or NAT-ed IPs not arbitrary ones.
Or?
rgds,
j.
Adrian 'Dagurashibanipal' von Bidder wrote:
On Monday 14 June 2004 14.59, Gavin Hamill wrote:
Yep, rinetd is a simple userspace proxy. I used it for a while, but
i
Hello Adrian!
NAT is only working with IPs "directly connected" to your ethernet card.
or NAT-ed IPs not arbitrary ones.
Or?
rgds,
j.
Adrian 'Dagurashibanipal' von Bidder wrote:
On Monday 14 June 2004 14.59, Gavin Hamill wrote:
Yep, rinetd is a simple userspace proxy. I used it for a while, but
i
On Monday 14 June 2004 14:57, Adrian 'Dagurashibanipal' von Bidder wrote:
> This may be obvious, but not to me... is there any difference compared
> to using iptables DNAT?
At the time I was using rinetd/netcat to do this kind of work, I didn't know
enough about iptables and the SNAT/DNAT pair w
On Monday 14 June 2004 09:57, Adrian 'Dagurashibanipal' von Bidder wrote:
> This may be obvious, but not to me... is there any difference compared
> to using iptables DNAT?
I believe that you'd have some problems if you used DNAT. Think of what
happens to a packet coming into your old colo and
On Monday 14 June 2004 14.59, Gavin Hamill wrote:
> Yep, rinetd is a simple userspace proxy. I used it for a while, but
> it had a few unpleasant 'features' I didn't like (we were using
> dynamic DNS with it, so I expect you wouldn't encounter them)
>
> Once our 'remote points' were static IPs, I s
On Monday 14 June 2004 14:57, Adrian 'Dagurashibanipal' von Bidder wrote:
> This may be obvious, but not to me... is there any difference compared
> to using iptables DNAT?
At the time I was using rinetd/netcat to do this kind of work, I didn't know
enough about iptables and the SNAT/DNAT pair w
On Monday 14 June 2004 09:57, Adrian 'Dagurashibanipal' von Bidder wrote:
> This may be obvious, but not to me... is there any difference compared
> to using iptables DNAT?
I believe that you'd have some problems if you used DNAT. Think of what
happens to a packet coming into your old colo and
On Monday 14 June 2004 11:16, Andreas John wrote:
> Hello!
> apt-cache show rinetd
> Package: rinetd
Yep, rinetd is a simple userspace proxy. I used it for a while, but it had a
few unpleasant 'features' I didn't like (we were using dynamic DNS with it,
so I expect you wouldn't encounter them)
On Monday 14 June 2004 14.59, Gavin Hamill wrote:
> Yep, rinetd is a simple userspace proxy. I used it for a while, but
> it had a few unpleasant 'features' I didn't like (we were using
> dynamic DNS with it, so I expect you wouldn't encounter them)
>
> Once our 'remote points' were static IPs, I s
I've added comments inline...
Rhesa Rozendaal wrote:
We are going to physically move our boxes, but for the dns the process
will amount to the same thing.
So here is what we'll do:
- Lower the ttl on all zones three days before the move
Lower the TTL on all zones OR INDIVIDUAL A RECORDS at least
Hello!
The "DNS Trick" should do it.
Instead of "internal" E-Mail Forwarding of ricochet E-Mails I think
about some kind of port-based forwarding. By random I ran accross
"rinetd" package.
apt-cache show rinetd
Package: rinetd
Description: Internet TCP redirection server
rinetd redirects T
I still have an uneasy feeling about dns caches out there that may keep
serving the old ip addresses to their users _without_ ever consulting
our dns servers. But I guess I could use a http proxy on the remaining
dns box to forward http traffic for a while, which would take care of
that part. T
On Monday 14 June 2004 11:16, Andreas John wrote:
> Hello!
> apt-cache show rinetd
> Package: rinetd
Yep, rinetd is a simple userspace proxy. I used it for a while, but it had a
few unpleasant 'features' I didn't like (we were using dynamic DNS with it,
so I expect you wouldn't encounter them)
Jason, Brad, thanks for the reassurance.
Rhesa Rozendaal wrote:
> In the past I witnessed such a move, and there were a lot of problems
> with the DNS. As it turned out, many DNS servers out there kept caching
> the old ip addresses for over 3 days, causing a lot of connection issues
This is mos
I've added comments inline...
Rhesa Rozendaal wrote:
We are going to physically move our boxes, but for the dns the process
will amount to the same thing.
So here is what we'll do:
- Lower the ttl on all zones three days before the move
Lower the TTL on all zones OR INDIVIDUAL A RECORDS at least
Hello!
The "DNS Trick" should do it.
Instead of "internal" E-Mail Forwarding of ricochet E-Mails I think
about some kind of port-based forwarding. By random I ran accross
"rinetd" package.
apt-cache show rinetd
Package: rinetd
Description: Internet TCP redirection server
rinetd redirects T
Rhesa Rozendaal wrote:
> In the past I witnessed such a move, and there were a lot of problems
> with the DNS. As it turned out, many DNS servers out there kept caching
> the old ip addresses for over 3 days, causing a lot of connection issues
This is most often due to the old authoritive servers c
there
is at least 1 DNS server running and active.
Then do the switch.
This way should help you minimize downtime.
Jas
- Original Message -
From: "Rhesa Rozendaal" <[EMAIL PROTECTED]>
To:
Sent: Monday, 14 June, 2004 5:36 PM
Subject: how to relocate servers transparent
Hello all,
I'm looking for some practical advice on moving servers from one
colocation to another.
In a couple of weeks, we need to move our servers to a different
colocation, which means all the ip addresses will change.
The servers are running regular stuff: web, mail, ftp, and two dns servers
I still have an uneasy feeling about dns caches out there that may keep
serving the old ip addresses to their users _without_ ever consulting
our dns servers. But I guess I could use a http proxy on the remaining
dns box to forward http traffic for a while, which would take care of
that part. T
Jason, Brad, thanks for the reassurance.
Rhesa Rozendaal wrote:
> In the past I witnessed such a move, and there were a lot of problems
> with the DNS. As it turned out, many DNS servers out there kept caching
> the old ip addresses for over 3 days, causing a lot of connection issues
This is mos
Rhesa Rozendaal wrote:
> In the past I witnessed such a move, and there were a lot of problems
> with the DNS. As it turned out, many DNS servers out there kept caching
> the old ip addresses for over 3 days, causing a lot of connection issues
This is most often due to the old authoritive servers c
there
is at least 1 DNS server running and active.
Then do the switch.
This way should help you minimize downtime.
Jas
- Original Message -
From: "Rhesa Rozendaal" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, 14 June, 2004 5:36 PM
Subject: h
Hello all,
I'm looking for some practical advice on moving servers from one
colocation to another.
In a couple of weeks, we need to move our servers to a different
colocation, which means all the ip addresses will change.
The servers are running regular stuff: web, mail, ftp, and two dns servers
34 matches
Mail list logo
