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
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 change
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
]
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 record
from my cache using TTL 82800
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
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 change
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
]
To: debian-isp@lists.debian.org
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 using TTL
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, so you
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, so you
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
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: how to relocate servers transparently
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
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 most
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.
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 TCP
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
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
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
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
it
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
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: debian-isp@lists.debian.org
Sent: Monday, 14 June, 2004 5:36 PM
Subject: how to relocate servers
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
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 most
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.
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 TCP
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
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
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: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
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
it
33 matches
Mail list logo
