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.
On 27/10/2006 12:39 p.m., Simon Lyall wrote:
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
On Fri, 27 Oct 2006, Gerard Creamer wrote:
On 27/10/2006 12:39 p.m., Simon Lyall wrote:
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.
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 On Fri, 2006-10-27 at 12:39 +1300, Simon Lyall wrote:
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 Lyall wrote:
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!
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
DNS wrote:
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.
Jeremy Brooking wrote:
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 jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/
On 10/27/06, 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.
On Fri, 27 Oct 2006, Sam Sargeant wrote:
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.
On Fri, 2006-10-27 at 19:44 +1300, Simon Lyall wrote:
On Fri, 27 Oct 2006, Sam Sargeant wrote:
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
On 27/10/2006, at 8:28 PM, Jamie Baddeley wrote:
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 -/-
On 27-Oct-2006, at 01:17, Sam Sargeant wrote:
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
On Fri, 27 Oct 2006, Joe Abley wrote:
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.
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 Simon Lyall wrote:
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?
-- 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
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. On Fri, 27 Oct 2006, Don Gould wrote:
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
Simon Lyall wrote:
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?
-- 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 NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Mark Foster wrote:
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
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. On 28/10/2006, at 5:40 PM, Don Gould wrote:
Mark Foster wrote:
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 NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
!DSPAM:22,454339bd50547802310528!
Nathan Ward wrote:
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.
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.
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 :)
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
On 29/10/2006 1:08 p.m., Don Gould wrote:
Nathan Ward wrote:
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
On 27 Oct 2006, at 00:39, Simon Lyall wrote:
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
participants (14)
-
Andy Davidson -
DNS -
Don Gould -
Gerard Creamer -
jamie baddeley -
Jamie Baddeley
-
Jasper Bryant-Greene -
Jeremy Brooking -
Joe Abley -
Mark Foster -
Nathan Ward -
Peter Mott -
Sam Sargeant -
Simon Lyall