Discussion:
Moving DNS providers - best practice.
(too old to reply)
Simon Lyall
2006-10-26 23:39:07 UTC
Permalink
After a few recent instances I am getting sick of companies who transfer
their DNS/Servers from one provider to another and then wonder why the old
data is still cached by 3rd parties for 24 hours (or whatever).

How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?

Similar to this:

http://www.onr.com/services/data_center/colocation/transfer_tips.html

Thoguhts?
--
Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.
Gerard Creamer
2006-10-27 00:28:51 UTC
Permalink
Post by Simon Lyall
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
For what it's worth, I think it's a good idea. Wouldn't this be the
sort of info InternetNZ or the DNC would publish on their site? Then
everyone could link to it without having to worry about updates etc.

On a related matter - what is the course of action when an old domain
provider continues to claim that they are primary for a domain, even
when the name moved eons ago? The provider appears to be in denial over
the issue, and it wouldn't be such a big deal if they weren't also a
fairly large ISP (so are giving the wrong IP addresses to their own
connectivity customers).

Any ideas?

Regards,
Gerard
Mark Foster
2006-10-27 02:23:14 UTC
Permalink
Post by Gerard Creamer
Post by Simon Lyall
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
For what it's worth, I think it's a good idea. Wouldn't this be the
sort of info InternetNZ or the DNC would publish on their site? Then
everyone could link to it without having to worry about updates etc.
On a related matter - what is the course of action when an old domain
provider continues to claim that they are primary for a domain, even
when the name moved eons ago? The provider appears to be in denial over
the issue, and it wouldn't be such a big deal if they weren't also a
fairly large ISP (so are giving the wrong IP addresses to their own
connectivity customers).
Ask them do a whois on the domain, and then point out that if they are
carrying Authoritive NS records for a domain which the rootservers are
pointing elsewhere - whois tells you this - they are breaking the DNS.

If they won't address this, well, apart from encouraging all and sundry to
boycott the organisation in question, it could questionably be considered
a Denial of Service...

In _most_ cases its usually a case of 'oh, by the way, spotted you're
still hosting this zone, whois disagrees' and the typical response is 'oh,
whoops, ok we'll fix that'. I havn't seen many providers refuse to purge
legacy zones.

Disclaimer: A backup of the zone files is a good idea, in case they need
to be put back for whatever reason... Also notifying the client that its
happened is smart....

DNS registries that automatically notify the SOA contact / Technical
Contact / Domain Owner of changes to authoritive NS when actioned in the
registry, are quite useful here... at least then the providers concerned
all get a headsup that changes are afoot.

IMHO.
Mark.
jamie baddeley
2006-10-27 00:50:15 UTC
Permalink
sounds like a very good idea. I'm very much in favour of various NZNOG
folks collaborating to create BCPs for the benefit of the industry as a
whole.

A kind of locally significant version of these:
http://www.apps.ietf.org/rfc/bcplist.html

jamie
Post by Simon Lyall
After a few recent instances I am getting sick of companies who transfer
their DNS/Servers from one provider to another and then wonder why the old
data is still cached by 3rd parties for 24 hours (or whatever).
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
http://www.onr.com/services/data_center/colocation/transfer_tips.html
Thoguhts?
Jeremy Brooking
2006-10-27 00:53:02 UTC
Permalink
Post by Simon Lyall
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
I think this is a brilliant idea. Would be nice if providers taking on
new clients would use a resource like this too, as often customers dont
realise they also need to inform their old provider they are moving
(Common sense, but gets forgotten a lot).

Ensure to include "Changing DNS providers at 5pm friday afternoon, just
prior to a long weekend, is probably not in the best interests of your
company"

If done, this would be a resource we would would use for sure!
DNS
2006-10-27 01:58:34 UTC
Permalink
Post by Simon Lyall
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
I think this is an excellent idea. A "best practice" document published
on the DNC site is a good start. Another idea would be to have some sort
of subscription service/mailing list that would notify subscribers of
delegation changes in the SRS.

Dave Baker

.nz Registry Services
Jeremy Brooking
2006-10-27 03:00:51 UTC
Permalink
Post by DNS
I think this is an excellent idea. A "best practice" document published
on the DNC site is a good start. Another idea would be to have some sort
of subscription service/mailing list that would notify subscribers of
delegation changes in the SRS.
Expanding on that idea...

What about some form of submission service where you can flag specific
domains for notification of SRS changes.

This would allow an ISP/Admin to mark the domains they are authoritive
for, and recieve notification when SRS information for that domain changes.


If this makes no sense or sounds retarded, forgive me, this has been a
beer induced reply.
Jasper Bryant-Greene
2006-10-27 03:32:03 UTC
Permalink
Post by Jeremy Brooking
What about some form of submission service where you can flag specific
domains for notification of SRS changes.
This would allow an ISP/Admin to mark the domains they are authoritive
for, and recieve notification when SRS information for that domain changes.
+1 on that from me. It will not only reduce the load on whatever system
sends the notifications, but also reduce the amount of irrelevant data
that recipients of the notifications have to sift through. Better all round.
--
Jasper Bryant-Greene
Director
Album Limited

***@albumltd.co.nz
+64 21 708 334 / 0800 425 286
http://www.albumltd.co.nz/
Sam Sargeant
2006-10-27 05:17:46 UTC
Permalink
Post by Jeremy Brooking
What about some form of submission service where you can flag specific
domains for notification of SRS changes.
If you're only interested in delegation changes, why not query the .nz
nameservers and report any changes yourself? There's no need for a
centralised system when it should be the operators responsibility to
make sure they aren't serving stale authoritative data.

I'd like to see a tool where a variety of local nameservers were
queried for a given domain, so any disagreements are immediately
obvious. Does such a tool exist already, or does anyone have a list of
common authoritative nameservers for NZ?

Sam.
Simon Lyall
2006-10-27 06:44:53 UTC
Permalink
Post by Sam Sargeant
I'd like to see a tool where a variety of local nameservers were
queried for a given domain, so any disagreements are immediately
obvious. Does such a tool exist already, or does anyone have a list of
common authoritative nameservers for NZ?
What is on the authoritive nameservers shouldn't matter because nobody
should be asking them for authoritive data about a domain unless it is
delgated to them.

Same with recursive nameservers, they just get their data from down the
chain and expire it according to the expires times in the zone record.

It's when you mix the two that you get potential problems. Unfortunetely
this is still pretty common for smaller sites (can't afford multiple
servers [1] ) or for larger/older sites that have been configured like
that from the start.

[1] - Yeah I know you can split them logically.
--
Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.
Jamie Baddeley
2006-10-27 07:28:58 UTC
Permalink
Post by Simon Lyall
Post by Sam Sargeant
I'd like to see a tool where a variety of local nameservers were
queried for a given domain, so any disagreements are immediately
obvious. Does such a tool exist already, or does anyone have a list of
common authoritative nameservers for NZ?
What is on the authoritive nameservers shouldn't matter because nobody
should be asking them for authoritive data about a domain unless it is
delgated to them.
Same with recursive nameservers, they just get their data from down the
chain and expire it according to the expires times in the zone record.
It's when you mix the two that you get potential problems. Unfortunetely
this is still pretty common for smaller sites (can't afford multiple
servers [1] ) or for larger/older sites that have been configured like
that from the start.
Architectural issues aside, shouldn't Sam's suggestion of identifying
the contentious points be an effective "peer pressure" way of achieving
the right result?

Sometimes being aware of an issue is half the battle?

jamie
Peter Mott
2006-10-27 07:41:20 UTC
Permalink
Post by Jamie Baddeley
Architectural issues aside, shouldn't Sam's suggestion of identifying
the contentious points be an effective "peer pressure" way of
achieving
the right result
Since when has peer pressure ever had any impact on the modus
operandi of a telco ISP?


regards

Peter Mott
-/-
Jamie Baddeley
2006-10-27 07:50:51 UTC
Permalink
Post by Peter Mott
a telco ISP?
Contradiction in terms perhaps?

:-)

jamie
Joe Abley
2006-10-27 13:59:39 UTC
Permalink
Post by Sam Sargeant
I'd like to see a tool where a variety of local nameservers were
queried for a given domain, so any disagreements are immediately
obvious. Does such a tool exist already, or does anyone have a list of
common authoritative nameservers for NZ?
If you have access to the *.NZ zones (I seem to remember there's a
mechanism for getting access to them so long as you are prepared to
declare that you will Do No Evil) then pulling it out of cron and
diffing against the previous copy ought to reveal delegation changes.
Sending queries to the old servers to see whether they still respond
authoritatively is then fairly trivial to script.

This could be done for all zones as a public service, or you could
check just those zones which have been re-delegated to your own
nameservers if you want a summary of problems your own customers are
about to have.

Checking your own nameservers is straightforward to automate. For
example, you could run the following out of cron every night, and fix
up any errors that appear in your mail the following morning. If
everybody did this (ho ho) there would be no need for any centralised
checking.

[monster:~]% ./stalezone.sh named.conf a.ns.hopcount.ca
16.21.202.in-addr.arpa may not be delegated to a.ns.hopcount.ca
5.1.1.1.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa may not be delegated to
a.ns.hopcount.ca
5.1.1.1.0.0.f.1.0.7.4.0.1.0.0.2.ip6.int may not be delegated to
a.ns.hopcount.ca
7.f.f.f.f.f.f.1.8.3.4.0.1.0.0.2.ip6.arpa may not be delegated to
a.ns.hopcount.ca
7.f.f.f.f.f.f.1.8.3.4.0.1.0.0.2.ip6.int may not be delegated to
a.ns.hopcount.ca
automagic.ca may not be delegated to a.ns.hopcount.ca
broadlinknz.net may not be delegated to a.ns.hopcount.ca
crypto.net may not be delegated to a.ns.hopcount.ca
desalis.gen.nz may not be delegated to a.ns.hopcount.ca
elyt.com may not be delegated to a.ns.hopcount.ca
entropy.co.nz may not be delegated to a.ns.hopcount.ca
f00f.org may not be delegated to a.ns.hopcount.ca
fx.net.nz may not be delegated to a.ns.hopcount.ca
fxeng.net.nz may not be delegated to a.ns.hopcount.ca
jackieandsimon.org may not be delegated to a.ns.hopcount.ca
linux.org.nz may not be delegated to a.ns.hopcount.ca
moronium.org may not be delegated to a.ns.hopcount.ca
nlri.ca may not be delegated to a.ns.hopcount.ca
nzix.net may not be delegated to a.ns.hopcount.ca
prng.net may not be delegated to a.ns.hopcount.ca
procurio.net may not be delegated to a.ns.hopcount.ca
search.net.nz may not be delegated to a.ns.hopcount.ca
stupidest.org may not be delegated to a.ns.hopcount.ca
unwired.net.fj may not be delegated to a.ns.hopcount.ca
wedgwood.info may not be delegated to a.ns.hopcount.ca
[monster:~]%

So, I guess I should actually be following my own advice. There will
be a brief delay while I do some housekeeping :-)


Joe

#!/bin/sh
#
# stalezone.sh

fail() {
echo $1 >&1
exit 1
}

test $# -eq 2 || fail "Syntax: $(basename $0) conf_file
name_of_nameserver"

conf=$1
test -f "${conf}" || fail "Cannot read ${conf}"

ns=$2
host ${ns} >/dev/null 2>&1 || fail "No such nameserver ${ns}"

awk '/^zone / { print $2; }' "${conf}" | tr -d \" | \
while read zone; do
test -z "$(dig +trace ${zone} NS 2>/dev/null | grep -i ${ns})" && \
echo "${zone} may not be delegated to ${ns}"
done
Simon Lyall
2006-10-28 05:09:21 UTC
Permalink
Post by Joe Abley
If you have access to the *.NZ zones (I seem to remember there's a
mechanism for getting access to them so long as you are prepared to
declare that you will Do No Evil) then pulling it out of cron and
diffing against the previous copy ought to reveal delegation changes.
Sending queries to the old servers to see whether they still respond
authoritatively is then fairly trivial to script.
Hmm sounds like something that might be useful. There is a similar project
that I was already looking at doing. I'll see if I can get something done
in time for NZNOG 07.
--
Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.
Peter Mott
2006-10-27 02:52:58 UTC
Permalink
Post by Mark Foster
Ask them do a whois on the domain, and then point out that if they are
carrying Authoritive NS records for a domain which the rootservers are
pointing elsewhere - whois tells you this - they are breaking the DNS.
One could also encourage folks to use different name servers for
caching and not allow recursion on their authoritative servers. That
way if they claim to be authoritative and they are no longer, nobody
cares.

I seem to remember having a discussion about this very thing with a
large provider about 6 years ago and they were not interested in any
form of co-operation that would prevent client internet experience
being broken when a change of delegation took place. They didn't
have the capacity to understand the problem let alone a resolve to
solve it. I wonder if anything has changed :-)


regards

Peter Mott
-/-
Gerard Creamer
2006-10-27 03:15:38 UTC
Permalink
Post by Peter Mott
Post by Mark Foster
Ask them do a whois on the domain, and then point out that if they are
carrying Authoritive NS records for a domain which the rootservers are
pointing elsewhere - whois tells you this - they are breaking the DNS.
One could also encourage folks to use different name servers for
caching and not allow recursion on their authoritative servers. That
way if they claim to be authoritative and they are no longer, nobody
cares.
I believe this is now considered best practice :^)
Post by Peter Mott
I seem to remember having a discussion about this very thing with a
large provider about 6 years ago and they were not interested in any
form of co-operation that would prevent client internet experience
being broken when a change of delegation took place. They didn't
have the capacity to understand the problem let alone a resolve to
solve it.
That sounds exactly like the discussion we had with them...

Thanks for the feedback, much appreciated - I'll ask them again then.

Regards,
Gerard
Mark Foster
2006-10-27 03:15:06 UTC
Permalink
Post by Mark Foster
Ask them do a whois on the domain, and then point out that if they are
carrying Authoritive NS records for a domain which the rootservers are
pointing elsewhere - whois tells you this - they are breaking the DNS.
One could also encourage folks to use different name servers for caching and
not allow recursion on their authoritative servers. That way if they claim
to be authoritative and they are no longer, nobody cares.
I seem to remember having a discussion about this very thing with a large
provider about 6 years ago and they were not interested in any form of
co-operation that would prevent client internet experience being broken when
a change of delegation took place. They didn't have the capacity to
understand the problem let alone a resolve to solve it. I wonder if anything
has changed :-)
Actually a possible 'reason' for this just occurred to me.

If you're buying a DNS hosting service from an ISP, does the ISP have the right
to cancel said hosting service without authority from the customer?

This, I believe, has been a cited reason _not_ to remove legacy DNS (despite
what the registry says) for at least one provider i've heard of before now. It
makes the issue one of customer-provider liason - and one of
monetary/commercial significance - instead of dns/operational significance.

I favour the latter. But there may be a valid point here...

Mark.
Don Gould
2006-10-27 10:08:32 UTC
Permalink
I think this is a fantastic idea...

...though I hate to rain on your parade...

I've found the ISPs seem to ignore the ttl which makes reducing it
pointless.

I just tell clients that it WILL be down for up to 48 hours and anything
less is the good karma you've earned in the universe.

It would be helpful if ISPs like Xtra and Telstra (and others) didn't
set up their DNS servers to ignore shorter ttl.

I've also found that domains will go live from overseas before they come
live here in NZ when in the .co.nz space.

Anyone who can improve things gets my vote for PM! :) Most appreciated :)
</rant>

Cheers Don
Post by Simon Lyall
After a few recent instances I am getting sick of companies who transfer
their DNS/Servers from one provider to another and then wonder why the old
data is still cached by 3rd parties for 24 hours (or whatever).
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
http://www.onr.com/services/data_center/colocation/transfer_tips.html
Thoguhts?
--
Don Gould
www.thinkdesignprint.co.nz - www.tcn.bowenvale.co.nz -
www.bowenvale.co.nz - www.hearingbooks.co.nz - www.buxtonsquare.co.nz -
SkypeMe: ThinkDesignPrint - Good ideas: www.solarking.co.nz
Mark Foster
2006-10-28 01:08:57 UTC
Permalink
So Don,

You're saying that Xtra and Telstra (and others) deliberately go out of
their way to engineer their DNS servers to _ignore_ the TTL variable and
instead make up their own?

Interested to hear how you come to that conclusion?

'48 hours' is fine if you're explaining to a newb and you know for certain
that the TTL involved is less than that.

I once came across a customer whos previous host, in a fit of vengance,
upped their TTL to 4 weeks just before the domain was transferred...

It is very easy for someone to look up the legacy record, find the TTL
variable and give the customer a realistic expectation that their domain
will have reduction in service over the transition period (duration of
TTL) which will gradually resolve itself as ISPs clear their caches and
pull new data.

Its also not hard for customer service reps to provide advice to customers
- like 'when you know you're going to be making a change, have the record
in question (or the entire zone) have a reduced TTL - say, 15 minutes -
configured. (This will usually require translation, but again, explaining
to people that its a step that'll minimise their downtime, is usually
sufficient, whether or not technical reasoning is provided.)

I further seem to recall suggesting to people who were moving their
domains away, to get back in touch with their old host after a couple
of days to ensure that any legacy zones _had_ been purged (and not overlooked). Puts
the onus back on the customer. 5 minutes on the phone could save a
hellovalot of heartache later, when you discover that your email is
'missing, presumed bounced'.

Mark.
Post by Don Gould
I think this is a fantastic idea...
...though I hate to rain on your parade...
I've found the ISPs seem to ignore the ttl which makes reducing it
pointless.
I just tell clients that it WILL be down for up to 48 hours and anything
less is the good karma you've earned in the universe.
It would be helpful if ISPs like Xtra and Telstra (and others) didn't
set up their DNS servers to ignore shorter ttl.
I've also found that domains will go live from overseas before they come
live here in NZ when in the .co.nz space.
Anyone who can improve things gets my vote for PM! :) Most appreciated :)
</rant>
Cheers Don
Post by Simon Lyall
After a few recent instances I am getting sick of companies who transfer
their DNS/Servers from one provider to another and then wonder why the old
data is still cached by 3rd parties for 24 hours (or whatever).
How do people feel about a "best practice" document on this that we could
encourage people to follow ( perhaps the DNC could publish) for people
moving their domain between providers. Just the basics like, dropping the
TTLs, getting all the servers data in the right order etc?
http://www.onr.com/services/data_center/colocation/transfer_tips.html
Thoguhts?
--
Don Gould
www.thinkdesignprint.co.nz - www.tcn.bowenvale.co.nz -
www.bowenvale.co.nz - www.hearingbooks.co.nz - www.buxtonsquare.co.nz -
SkypeMe: ThinkDesignPrint - Good ideas: www.solarking.co.nz
_______________________________________________
NZNOG mailing list
http://list.waikato.ac.nz/mailman/listinfo/nznog
Don Gould
2006-10-28 04:40:06 UTC
Permalink
Post by Mark Foster
So Don,
You're saying that Xtra and Telstra (and others) deliberately go out of
their way to engineer their DNS servers to _ignore_ the TTL variable and
instead make up their own?
Yes, I'm saying that some providers seem to override/ignore the ttl and
do for a default value.

Cheers Don
--
Don Gould
www.thinkdesignprint.co.nz - www.tcn.bowenvale.co.nz -
www.bowenvale.co.nz - www.hearingbooks.co.nz - www.buxtonsquare.co.nz -
SkypeMe: ThinkDesignPrint - Good ideas: www.solarking.co.nz
Nathan Ward
2006-10-28 20:59:40 UTC
Permalink
Do you have proof of that yourself, or are you claiming it because
you heard someone else say it?
I've /never/ had problems with any of my domains with these servers.

I understand (again, one of those rumor things, so sue me) that alien
and terminator (sure, not the current resolvers that are pushed to
Xtra customers, but they were current when I first heard this claim)
run bind (8?). I'm not aware of any way to set a minimum or global
explicit TTL in bind when it's doing the recursive thing.
I'm not sure what TelstraClear run, but I'm guessing bind, too.

Sounds like a beat-up-on-the-big-guys rumor if you ask me.
Post by Don Gould
Post by Mark Foster
So Don,
You're saying that Xtra and Telstra (and others) deliberately go out of
their way to engineer their DNS servers to _ignore_ the TTL
variable and
instead make up their own?
Yes, I'm saying that some providers seem to override/ignore the ttl and
do for a default value.
Cheers Don
--
Don Gould
www.thinkdesignprint.co.nz - www.tcn.bowenvale.co.nz -
www.bowenvale.co.nz - www.hearingbooks.co.nz -
www.buxtonsquare.co.nz -
SkypeMe: ThinkDesignPrint - Good ideas: www.solarking.co.nz
_______________________________________________
NZNOG mailing list
http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,454339bd50547802310528!
Don Gould
2006-10-29 00:08:25 UTC
Permalink
Post by Nathan Ward
Do you have proof of that yourself,
Proof, no, I've never bothered to pursue the problem to provide proof
that I would consider up to a standard worth investigation.
Post by Nathan Ward
or are you claiming it because
you heard someone else say it?
No. I've had problem after problem my self with dns in NZ and Australia
with the bigger providers. As I said, I now normally just allow 48
hours for transition.

Yes. I have had other people make comments about issues as well.

Let me be fair, some times I have problems and some times things go
really smoothly.

Bottom line, people don't transfer domains often enough for me to make
any real issue, I was simply expressing a frustration.
Post by Nathan Ward
I've /never/ had problems with any of my domains with these servers.
Guess you have more good karma in the universe than I do :)
Post by Nathan Ward
I understand (again, one of those rumor things, so sue me) that alien
and terminator (sure, not the current resolvers that are pushed to
Xtra customers, but they were current when I first heard this claim)
run bind (8?). I'm not aware of any way to set a minimum or global
explicit TTL in bind when it's doing the recursive thing.
I'm not sure what TelstraClear run, but I'm guessing bind, too.
Sounds like a beat-up-on-the-big-guys rumor if you ask me.
No. My comments were based on my personal experiences with delegation
and dns issues and Telstra and Telcom connections.

Put it in perspective thou, I'm a very very small fish, I have a lot
less experience than most on this list.

These are my observations only.

Anyone who's thinking of writing a best practice document for NZ admins
might like to consider my comments, ask a few questions and address the
issues.

I suggest that a best practice document isn't required by most on this
list, it's required most by people like me who are clearly having
problems with getting things done right in NZ, especially with the big
providers.

Cheers Don
--
Don Gould
www.thinkdesignprint.co.nz - www.tcn.bowenvale.co.nz -
www.bowenvale.co.nz - www.hearingbooks.co.nz - www.buxtonsquare.co.nz -
SkypeMe: ThinkDesignPrint - Good ideas: www.solarking.co.nz
Gerard Creamer
2006-10-29 01:56:48 UTC
Permalink
Post by Don Gould
Post by Nathan Ward
I've /never/ had problems with any of my domains with these servers.
Guess you have more good karma in the universe than I do :)
Are we still just talking about delegation changes? Because I can think
of numerous DNS related 'tales or woe' from telcos, but they tend to
come back to general competence issues and corporate lack of clue.

I have always found it works quite well (but is irritatingly time
consuming) to get the telco, or whoever the other party is, to change
their zones to return the new addresses we want to have returned after
the move, then transfer the name to our name servers (with no changes in
the zone). Then the telco can take their sweet time with the removal of
the name. Although we recently go bitten (see last post) with a telco
who still thought they were primary several years after the name was moved.

We are fairly small too though, and not everyone will have the time or
patience (read 'budget') to be as risk adverse as we are. Having said
that I ran Joe Abley's 'stalezone.sh' and have a pile of work to do too :^/

Gerard
Andy Davidson
2006-12-11 12:15:42 UTC
Permalink
Post by Simon Lyall
After a few recent instances I am getting sick of companies who
transfer their DNS/Servers from one provider to another and then
wonder why the old data is still cached by 3rd parties for 24 hours
(or whatever).
On this _particular_ topic, dropping the TTL will not always result
in expected behaviour, a lot of ISPs in the UK will ignore TTLs which
are less than a day.

When I did a dc migration most recently, I tried to have public
facing boxes on the old and new address for a week or so. Sometimes
this is easy to do (e.g. mail, just set up a temp secondary MX on the
old address), sometimes this is trickier (e.g. web, but we put a
transparent proxy on the old address for a week.)

Lastly, if guys want to work collaboratively on such documentation,
then a wiki is a really good place to start.

cheers
andy

Continue reading on narkive:
Loading...