Tag Archives: risk management

A Tale Of Two Domain Extensions

icann_new_top_level_domains_tld_gtld_sign2_by_felixart05-d6iedi6

Graphic by Felixart05

icann_new_top_level_domains_tld_gtld_sign2_by_felixart05-d6iedi6 We’ve gotten far past the early internet days when registering a domain name usually meant choosing between .COM, .ORG, and .NET. The number of top level domains (TLD) has exploded, and you can now grab names ending in .BAND, .BEER, .BARGAINS, .BEST, .BLOG, .BOO, .BUZZ, and .WTF (really!), to name just a few. The full list of new additions is here.

Two new TLDs are of particular interest to nonprofits.  Next week, you’ll have the option of registering a .NGO domain (Non Govermental Organization).  Should you? I’d say that it depends on the scope of your nonprofit.  Is it international?  Do you work outside of the US? Non-Governmental Organization isn’t a meaningful distinction here in the states (where I work at what is casually called a quasi-governmental nonprofit), but it’s much more common everywhere else.  If your org is focused on a local U.S. community, it probably makes no sense to pay for a domain name that your constituents might not even understand, much less expect. Otherwise, it seems really prudent to be accessible using the standard terminology in the countries that you work with. Just register it and point it to the same site as your .ORG.

Update: actually, there might be a few reasons to invest in .NGO, even if you don’t have an international presence. The article “Four Reasons Why Your Nonprofit Should Register .NGO and .ONG” was pretty enlightening. One key point is that, unlike with .ORG, .NGO/ONG registration requires proof of your nonprofit status, which will increase the trust level of potential donors. Another is that a large, potentially considered “definitive”, directory of nonprofits will be based on .NGO/ONG registration.  Thanks to Chris Tuttle for this heads up!

The other up and coming TLD is the new .SUCKS extension. While .WTF is pretty funny, .SUCKS is a bit of a threat. Many of us register the .COM equivalent of our .ORG domain name to protect our brands from impostors or critics (if you don’t, and it’s available, you should). So who wants to see a .SUCKS variant of their domain name out there?  None of us.  So, should you grab this one as a stopgap too? I say, no way.

First, there’s already a complaint filed with ICANN against Vox Populi, the company offering .SUCKS registrations, rightly claiming that their policy of famous people and brands and offering them a $2500 (annually!) first shot at registering the .SUCKS variant of their name prior to chopping down the price to $10 for anyone else is equivalent to extortion.

But my case is that, extortion attempts aside, even $10 a year is too much to pay, because owning the .SUCKS equivalent of your brand won’t protect you from anything. Anyone can register a “yourorgsucks” domain with a .COM or .NET or .WTF extension. and nobody is going to think that a techcafeteria.sucks domain lobbing grammar critiques of my blog is something that I created or endorse…

…because misteaks.

So .NGO is go if you go beyond the borders, but .sucks sucks. Just say no!

RFPs GOOD. Fixed Bids BAD.

It occurs to me that my signature rant these days is not clearly posted on my own blog. Let’s fix that!

As I’ve mentioned before. Requests for Proposals (RFP’s) are controversial in the nonprofit sector. Vendors hate them. dollar-163473_640Nonprofits struggle with developing them. I’ve been on a multi-year mission to educate and encourage the community to rethink RFPs, as opposed to throwing them out. In particular, nonprofits need to break away from fixed bid requests when hiring web developers, programmers, and people who implement CRMs. Here’s why:

Done correctly, RFP’s are an excellent practice. A good RFP informs potential vendors about the organization, their current condition, and their project goals. A questionnaire can focus on vetting the expertise of the consultant, examples of prior work, stability of the company, etc. All good things to know before investing serious time in the relationship. The RFP can also request billing rates and the like, but, in my experience, the cheaper rates don’t always correlate with ultimate project cost. Some higher hourly consultants do the work in half the time of some moderately priced ones.

The problem is that many nonprofits want to get that fixed bid and then hire the lowest bidder. But, for a web design or CRM project, the odds that the nonprofit knows how many hours the project is going to take are practically nil and, what’s more, they absolutely shouldn’t know. With a good consultant, you’re going to learn a lot in the process about what you should be doing. With a wild guess-based fixed bid, you are likely to suffer from one of two problems:

  • The project will be seriously underbid (very likely) and the vendor relationship will get worse and worse as they keep expending more hours without being compensated;
  • Or the vendor will finish up in half or two thirds of the hours and there you’ll be, donating to their charity.

You can vet the fiscal competence of a consultant.  Check their references and ask good questions like:

  • “Did the project come in at or under budget?”
  • “Was the vendor able to scale the project to your budget?”
  • “Can you tell me about a time that you had a billing disagreement with them, and how well it was resolved?”

Also, check their reputation in the nonprofit sector, because we have lots of mailing lists and forums where you can do that.

I hire consultants based on their expertise, reputation, and compatibility with my organization’s goals and work style. I stress that vendor interviews should be with the staff that I will most likely be working with. I’ll often break a project into two phases, one for discovery and then another for implementation. With the great consultants that I work with, this does not result in over-budget implementation bids. Instead, it helps us define what we can do and stay within budget. Because this is all about taking away the guess work.

So, RFPs are good things, as long as they are making realistic requests of the vendors. The crisis with them in our sector is based simply on the fact that most of our RFPs ask questions that can not, and should not, be answered, such as “how much will you charge me to do this undetermined amount of work?”

How I Spent My 2015 Technology Initiative Grants Conference

I’m back from our (Legal Services Corporation) 15th annual technology conference, which ran from January 14th through the 16th  in San Antonio, Texas.  It was a good one this year, with a great location, good food, great people – nearly 300 of them, which is quite a record for us. There were plenty of amazing sessions, kicked off by a fascinating keynote on international access to justice web app partnerships. Slides and videos will be up soon on LSC’s website. But I did want to share the slides from my sessions, which all seemed to go very well.  I did three:

Are You Agile

I kicked off the first morning doing a session on agile project management with Gwen Daniels of Illinois Legal Aid Online. My slides provided a basic overview of project management concepts, then Gwen did a live demo of how ILAO uses Jira and a SCRUM methodology to develop websites and applications. Having studied agile more than actually practicing it, I learned a lot from her.  The combined slides will be up on LSC’s site. I pulled my intro from this broader presentation that I did at the Nonprofit Technology Conference in 2013:

Shop Smart: How A Formal Procurement Process Can Safeguard Your Investments

On Thursday, I summarized everything I know about software and vendor selection, writing proposals, and negotiating contracts into this dense presentation on how to purchase major software systems.

Security Basics

And on Friday, usual suspect Steve Heye and I led a session on security, factoring all of the things that we think orgs should know in an era of frequent, major breaches and distributed data.

I’ll hit some of these same themes in March at the Nonprofit Technology Conference, where I’ll be speaking on contract negotiations (cloud and otherwise) and information policies (with Johan Hammerstrom of CommunityIT. See you there?

Career Reflections: My Biggest Data Fail

This article was published on the NTEN Blog in February of 2014.  It originally appeared in the eBook “Collected Voices: Data-informed Nonprofits“.

Peter Campbell of Legal Services Corporation shares his biggest data fail, and what he’d do differently now.

This case study was originally published along with a dozen others in our free e-book, Collected Voices: Data-Informed Nonprofits. You can download the e-book here.

Note: names and dates have been omitted to protect the innocent. 

Years ago, I was hired at an organization that had a major database that everyone hated. My research revealed a case study in itself: how not to roll out a data management system. Long story short, they had bought a system designed to support a different business model, and then paid integrators to customize it beyond recognition. The lofty goal was to have a system that would replace people talking to each other. And the project was championed by a department that would not have to do the data entry; the department identified to do all of the work clearly didn’t desire the system.

The system suffered from a number of problems. It was designed to be the kitchen sink, with case info, board updates, contact management, calendaring, web content management, and other functions. The backend was terrible: a SQL database with tables named after the tabs in the user interface. The application itself had miserable search functionality, no dupe checking, and little in the way of data quality control. Finally, there were no organizational standards for data entry. Some people regularly updated information; others only went near it when nagged before reporting deadlines. One person’s idea of an update was three to five paragraphs; another’s two words.

I set out to replace it with something better. I believed (and will always believe) that we needed to build a custom application, not buy a commercial one and tweak it. What we did was not the same thing that the commercial systems were designed to track. But I did think we’d do better building it with consultants on a high-level platform than doing it by ourselves from scratch, so I proposed that we build a solution on Salesforce. The system had over 150 users, so this would be relatively expensive.

Timing is everything: I made my pitch the same week that financial news indicated that we were diving into a recession. Budgets were cut. Spending was frozen.  And I was asked if I could build the system in Access, instead?  And this is when I…

…explained to my boss that we should table the project until we had the budget to support it.

Or so I wish. Instead, I dusted off my amateur programming skills and set out to build the system from scratch. I worked with a committee of people who knew the business needs, and I developed about 90% of a system that wasn’t attractive, but did what needed to be done reasonably well. The goals for the system were dramatically scaled back to simply what was required.

Then I requested time with the department managers to discuss data stewardship. I explained to the critical VP that my system, like the last one, would only be as good as the data put into it, so we needed to agree on the requirements for an update and the timeliness of the data entry. We needed buy-in that the system was needed, and that it would be properly maintained. Sadly, the VP didn’t believe that this was necessary, and refused to set aside time in any meeting to address it. Their take was that the new system would be better than the old one, so we should just start using it.

This was where I had failed. My next decision was probably a good one: I abandoned the project. While my system would have been easier to manage (due to the scaled back functionality, a simple, logical database structure and a UI that included auto-complete and dupe-checking), it was going to fail, too, because, as every techie knows, garbage in equals garbage out. I wanted my system to be a success.  We went on with the flawed original system, and eventually started talking about a new replacement project, and that might have happened, but I left the company.

Lessons learned:

  1. If I’m the IT Director, I can’t be the developer. There was a lot of fallout from my neglected duties.
  2. Get the organizational commitment to the project and data quality standards confirmed before you start development.
  3. Don’t compromise on a vision for expediency’s sake.  There are plenty of times when it’s okay to put in a quick fix for a problem, but major system development should be done right.  Timing is everything, and it wasn’t time to put in a data management system at this company.

How I Learned To Stop Worrying and Love The RFP

This article was originally posted on the NTEN Blog in January of 2014.

Requests for Proposals (RFPs) seem like they belong in the world of bureaucratic paperwork instead of a lean, tech-savvy nonprofit. There’s a lot that can be said for an RFP when both sides understand how useful a tool an RFP can be – even to tech-savvy nonprofits.

Here’s a safe bet: preparing and/or receiving Requests for Proposals (RFPs) is not exactly your favorite thing. Too many RFPs seem like the type of anachronistic, bureaucratic paperwork more worthy of the company in Office Space than a lean, tech-savvy nonprofit. So you may wonder why I would pitch a 90 minute session on the topic for this year’s Nonprofit Technology Conference. I’d like to make the case for you to attend my session: Requests for Proposals: Making RFPs Work for Nonprofits and Vendors.

The problems with RFPs are numerous, and many of you have tales from the trenches that could fill a few horror anthologies regarding them. I’ll be the first to agree that they often end up doing more harm than good for a project.  But I believe that this is due to a poor understanding of the purpose of the RFP, and a lack of expertise and creativity in designing them. What a successful RFP does is to help a client assess the suitability of a product or service to their needs long before they invest more serious resources into the project. That’s very useful.

The mission of the RFP is two-fold: a well written RFP will clearly describe the goals and needs of the organization/client and, at the same time, ask the proper questions that will allow the organization to vet the product or consultant’s ability to address those needs. Too often, we think that means that the RFP has to ask every question that will need to be asked and result in a detailed proposal with a project timeline and fixed price. But the situations where we know exactly, at the onset, what the new website, donor database, phone system or technology assessment will look like and should look like before the project has begun are pretty rare.

For a consultant, receiving an RFP for a web site project that specifies the number of pages, color scheme, section headings and font choices is a sign of serious trouble. Because they know, from experience, that those choices will change. Pitching a  fixed price for such a project can be dangerous, because as the web site is built, the client might find that they missed key components, or the choices that they made were wrong. It does neither party any good to agree to terms that are based on unrealistic projections, and project priorities often change, particularly with tech projects that include a significant amount of customization.

So you might be nodding your head right now and saying, “Yeah, Campbell, that’s why we all hate those RFPs. Why use ’em?” To which I say, “Why write them in such a way that they’re bound to fail?”

The secret to successful RFP development is in knowing which questions you can ask that will help you identify the proper vendor or product. You don’t ask how often you’ll be seeing each other next spring on the first date. Why ask a vendor how many hours they project it will take them to design each custom object in your as yet un-designed Salesforce installation? Some information will be more relevant — and easier to quantify — as the relationship progresses.

At the RFP session, we’ll dive into the types of questions that can make your RFP a useful tool for establishing a healthy relationship with a vendor. We’ll learn about the RFPs that consultants and software vendors love to respond to.  We’ll make the case for building a critical relationship in a proactive and organized fashion.  And maybe, just maybe, we’ll all leave the session with a newfound appreciation for the much-maligned Request for Proposal.

Don’t miss Peter’s session at the 14NTC on Friday, March 14, 3:30pm -5:00pm.

Peter Campbell is a nonprofit technology professional, currently serving as Chief Information Officer at Legal Services Corporation, an independent nonprofit that promotes equal access to justice and provides grants to legal aid programs throughout the United States. Peter blogs and speaks regularly about technology tools and strategies that support the nonprofit community.

Is It Time To Worry About Cybercrime?

This article was originally posted on the Idealware Blog in September of 2011.

For the past decade, the bulk of unlawful web-based activities have been profit-motivated: phishing, spam, “Nigerian” money scams, and hacking to get credit cards. This year has seen a rise in politically motivated crimes, most widely exemplified by the loosely-knit group of hackers known as “Anonymous“.  Anonymous hackers attack the websites of organizations, be they government, corporate or otherwise that they deem to be repressive or unethical.  In addition to defacing the sites, they’ve also routinely exposed confidential user information, such as login names, passwords and addresses.  If we are now entering the age where political cybercrime is commonplace, what does that mean for nonprofits?  How can we defend oursleves when we already struggle with basic security on tight budgets and limited resources?

Two high profile victims were Sony, the gigantic electronics and entertainment conglomerate, and BART, the Bay Area Rapid Transit commuter service.

  • Sony was initially a target for Anonymous after they took legal action against a computer geek named George Holtz, who figured out how to reprogram a Playstation game device in order to play blocked third-party games on it.  This violated the Sony license, but the hacking and gaming communities felt that the license restriction wasn’t very fair in the first place. They considered the action against Holtz unwarranted and severe.  Sony also, famously, installed a hacker’s rootkit, themselves, on a number of music CDs with interactive computer features, and were sued for that crime.,  Could it be that the hackers were particularly annoyed that this mega-corporation will stoop to their tactics, but sue them for similar actions?
  • BART was targeted for more visceral actions.  Their internal police force shot Oscar Grant, an unarmed youth, in the back a few years ago, and then, again, recently, fired on a homeless man holding a knife, killing him. These actions drew the attention of the community and resulted in protests, some violent.  But BART only drew the attention of Anonymous when they took the step of blocking cell phone service at their four downtown San Francisco stations in order to quell communication about a planned protest.  This action is under investigation by the FCC and has been decried by the ACLU; it was quite likely illegal. Then it was revealed that, at a press conference to discuss the protests, they seeded the audience with BART proponents coached in what to ask and say.

Anonymous hacked a dozen or more Sony Websites and three BART websites in protest/retaliation for what they consider to be corporate crime. Here’s how easy it was for them: one of the Sony servers containing hundreds of thousands of user account records was running on an old, unpatched version of Apache with no encryption. The initial attack was simply accomplished using a hack (SQL Injection) that is ridiculously easy to block (by updating to a current software version, in most cases). The Administrator password to get into the BART police site was “admin123”.  The “hacker” who broke into that site reported that she’d never hacked a web site in her life, she just did a bit of googling and got right in.

These were corporate web sites, run by companies that take in vast amounts of consumer dollars every day, and they couldn’t be bothered to do even the minimum amount of safeguarding of their customer’s data.  They might not be the criminals, but is it wild to suggest that they were criminally negligent? This isn’t a matter of them not having the money, resources or available expertise to protect our data.  It was a matter of them not taking the responsibility to protect it.

What can nonprofit organizations, that aren’t obsessed with bottom lines, do to avoid the problems that BART and Sony have faced?

  • First and foremost, we need to protect constituent data.  If your NPO doesn’t have the weherewithal to do that internally, than your online data should be hosted with companies that have strong commitments to security and privacy of customer data.
  • Second, should breaches occur (and they do), your primary goal should be timely, open communication with the victims of the data breach.  We’re getting past the point where our constituents are naive about all of this (Sony has done a great job of prepping them for us).  So your first response to exposed constituent data should be to tell the constituents exacty what was exposed.
  • One uncomfortable situation like this won’t kill your credibility, but a history of bad or callous relationships will amplify it.  This is one of the reasons why good social media policies are critical — the people who can support or sink you when something like a data breach occurs are on Twitter and Facebook, and they’ll feed the media stream with support or slander, depending on how well you relate to them.
  • We promote causes online, but we admit faults there, too.  We don’t engage customers by lying to them, hiding things that impact them, or dictating the terms of our relationships with them.
  • Our supporters are people, and they have their motivations for supporting us (or not) and their ideas about how they should be doing it.  Their motivations and reasoning might be quite different from what we assume. Accordingly, we should be basing our assumptions — and campaigns — on the best feedback that we can coax out of them.  Long-held industry assumptions are suspect simply because they’re long-held, in a world where technology, and how we interact with it, is constantly changing.

 

If we ever needed reverse primers in how to manage constituent relationships, the Sony and BART fiascos are prime ones.  They are victims of illegal and unethical behaviour.  But by viewing their customers and constituents as threats, with callous regard for the people who keep them in business in the first place, they’ve created a public relationship that did nothing to stem the attacks. Sony has put far more money and effort into attacking and dehumanizing their customers with lawsuits and invasive, annoying copyright protection schemes than they have in listening, or trying to understand the needs and desires of their constituents.  BART has tried to block their ears so tightly to shut out public criticism of their violent, shoot first police force that they’ve crossed constitutional lines of conduct. We — nonprofits — know better. It’s a two way relationship, not a dictatorial relationship with our supporters, that will serve as our most effective firewall.

Tech Tips From The Nonprofit Technology Conference

This article was first published on the Idealware Blog in May of 2010.

Last month, I reported on the first annual Tech Track, a series of sessions presented at the April, 2010 Nonprofit Technology Conference. In that post I listed the topics covered in the five session track. Today I want to discuss some of the answers that the group came up with.

Session 1: Working Without a Wire

This session covered wireless technologies, from cell phones to laptops. Some conclusions:

The state of wireless is still not 100%, but it’s better than it was last year and it’s still improving Major metropolitan areas are well covered; remote areas (like Wyoming) are not. There are alternatives, such as Satellite, but that still requires that your location be in unobstructed satellite range. All in all, we can’t assume that wireless access is a given, and the challenge is more about managing staff expectations than installing all of the wireless by ourselves. It will get there.
Wireless security options are improving. Virtual Private Networks (VPNs), remote access solutions (such as Citrix, VNC andTerminal Services) are being provided for more devices and platforms, and the major smartphone companies are supporting enterprise features like remote device wipes.
Policy-wise, more orgs are moving to a module where staff buy their own smartphones and the companies reimburse a portion of the bill to cover business use. Some companies set strict password policies for accessing office content; others don’t.

Session 2: Proper Plumbing

This session was pitched as covering virtualization and other server room technologies, but when we quizzed the participants, virtualization was at the top of their list, so that’s what we focused on.

We established that virtualizing servers is a recommended practice. If you have a consultant recommending it and you don’t trust their recommendation, find another consultant and have them virtualize your systems, because the recommendation is a good one, but it’s a problem that you don’t trust your consultant!
The benefits of virtualization are numerous — reduced budgets, reduced carbon footprints, instant testing environments, 24/7 availability (if you can upgrade a copy of a server and then switch it back live, an advanced virtualization function).
There’s no need to rush it — it’s easier on the budget and the staff, as well as the environment, to replace standalone servers with virtualized ones as the hardware fails.
On the planning side, bigger networks do better by moving all of their data to a Storage Area Network (SAN) before virtualizing. This allows for even more flexibility and reduced costs, as servers are strictly operating systems with software and data is stored on fast, redundant disk arrays that can be accessed by any server, virtual or otherwise.

Session 3: Earth to Cloud

The cloud computing session focused a lot on comparisons. While the general concern is that hosting data with a third party is risky, is it any more risky than hosting it on our own systems? Which approach is more expensive? Which affords the most freedom to work with our data and integrate systems? How do we manage disaster recovery and business continuity in each scenario?

Security – Everyone is hackable, and Google and Salesforce have a lot more expertise in securing data systems than we do. So, from a “is your data safe?” perspective, it’s at least a wash. But if you have sensitive client data that needs to be protected from subpoenas, as well as or more than hackers, than you might be safer hosting your own systems.
Cost – We had no final answers; it will vary from vendor to vendor. But the cost calculation needs to figure in more than dollars spent — staff time managing systems is another big expense of technology.
Integration and Data Management – Systems don’t have to be in the same room to be integrated; they have to have robustAPIs. And internal systems can be just as locked as external if your contract with the vendor doesn’t give you full access and control over your data. This, again, was a wash.
Risk Management – There’s a definite risk involved if your outsourced host goes out of business. But there are advantages to being hosted, as many providers offer multiply-redundant systems. Google, in particular, writes every save on a Google Doc or GMail to two separate server farms on two different continents.
It all boils down to assessing the maturity of the vendors and negotiating contracts carefully, to cover all of the risks. Don’t sign up with the guy who hosts his servers from his basement; and have a detailed continuity plan in place should the vendor close up shop.
 If you’re a small org (15 staff or less), it’s almost a no-brainer that it will be more cost-effective and safer to host your email and data in the cloud, as opposed to running our own complex CRMs and Exchange servers. If you’re a large org, it might be much more complex, as larger enterprise apps sometimes depend on that Exchange server being in place. But, all in all, Cloud computing is a viable option that might be a good fit for you — check it out, thoroughly.

I’ll finish this thread up with one more post on budgeting and change management in the next few weeks.

The Softer Side Of Security

This article was first published on the NTEN Blog in April of 2010.

As the technical staff at our nonprofits, we wrestle with all sorts of complex security concepts: firewalls, encryption, network address translation.

But here are three quick questions:

  • Would you spend $10,000 on a security system for your building, and then set the access code to “12345”?
  • Would you set the administrative account name and password to your network to the same thing that five other companies in your building use?
  • Would you allow an outside vendor to manage your network without sharing the passwords with you or anyone else at your organizations?

I’ve seen all three of these situations occur, the first two at commercial law firms, the latter at a large nonprofit [disclaimer: not the one I work for now!]. There are some infamous and true stories of clever hacking that played on the human side of security, such as the teenagers who took a couple of clipboards and interviewed people in the lobby of a large office building under the guise of a school project, in the process collecting birthdays; kids, spouses and pets names; street addresses — all things people commonly use as the base for their network passwords.

But all of the sophisticated systems in the world offer little more than a swiss cheese defense if we don’t have good organizational policies to address the human side of security. And even that’s a little tricky, as policies that are too complex for staff to easily comply with will be subverted in ways that open more security holes.

A sustainable password policy requires that passwords be:

  • Of a decent length (7-15 characters);
  • Comprised of a mix of letters, numbers, and/or additional characters, preferably with mixed case; and
  • Not be based on data that can easily be associated with the user, such as kids names or the TV show that they often discuss online.
  • They should also n ot be so obscure (as in “6T5re#bb77l”) that they can’t be easily memorized — that’s a recipe for password post-its!

In addition to maintaining a secure password policy (and enforcing it with network policy automation), staff should be resourced with tools to manage passwords.

There are numerous free or inexpensive applications and services that offer encrypted, password-protected storage for the collection of passwords. Looking for the ones that synchronize to a mobile app will add additional convenience.

From the management level, a best practice is for the lead in IT to print all passwords, seal them in an envelope, and give it to the CEO or HR executive at the organization, repeating (with secure destruction of the outdated list) as passwords change. Twice in my career as a CIO/IT Director, I’ve walked into situations where my predecessors left mad, and took all of the system password information with them, leaving me, initially, unable to manage the networks that I’d been hired to oversee. Don’t put your nonprofits work at risk by omitting this type of failsafe.

All of the port blocking, proxy servers and point to point tunneling on earth won’t protect you from the person who clicks on a malicious link in an email. Only education, communication, and support will address those security holes, and no security plan can be considered valid if it doesn’t incorporate policies along with the technical protection.

Dealing with Domains – Part 2

This post was originally published on the Idealware Blog in January of 2010.

Last week, we talked about domain registrar services and what to look for. In today’s followup, we’ll focus on how to transfer a domain and the accompanying security concerns, then talk a bit about registrars vis a vis hosting services.

Domain Transfers

Transferring domains is a somewhat complex process that has been designed to minimize the risk of domain hijacking. In order to insure that transfers are performed by the actual owner of the domain, a few important measures are in place:

  • Every domain has an authorization (a.k.a. EPP) code associated with it. Transfers can not occur without this code being submitted. If you don’t have this information, your current registrar does. Some registrars have automated functions that will deliver that information to the domain contact; others require that you ask for them via email to the registrar or their support ticket application. Registrars are required to provide you with these codes within five calendar days of your request. If they don’t, your best recourse is to determine who they get their domain authority from (there are only a handful of companies that resell registration services) and appeal to them for assistance.
  • Communication is strictly through the registered “whois” email address of the domain owner. You can determine what that is by doing a whois lookup on your domain.
    Tip: While most domains can be looked up at http://whois.net. However, whois.net has some trouble with .org domains, so the alternative http://www.pir.org/whois is a more reliable source for most non-profit domains.

    If the address that your domain is registered with is either non-functional or owned by someone other than you, then you need to update it, via your current registrar’s web interface, before you can successfully transfer the domain.

  • Domains can (and should) be locked to prohibit transfers before and after you switch registrars. Locking and unlocking your domains is usually done by you, from your registrar’s web site. If you don’t have options to do that when you log on to the web site, your registrar should do it for you upon request.

Transfer Procedures

To initiate the transfer, go to the web site of the registrar that you want to switch to and follow their instructions. They will have you submit a request and, upon receipt of your domain fees, issue an email to the email address associated with the domain containing a link to a form where you can confirm the request. That form will also ask for the authorization code. Subsequently – and this can take up to seven days – you’ll receive an email from your current registrar asking you to confirm the transfer request. Once that is submitted, the transfer should go through.

Detailed rules about how domains are transferred, as well as what the responsibilities of the registrars are in handling the transfers, are listed at http://www.icann.org/en/transfers/policy-en.htm.

Choosing Registrars

Registrars charge anywhere from $5.00 to $50 dollars for a year’s domain service. The two best known registrars are Network Solutions and GoDaddy. Many people go with Network Solutions because they’re the longest standing of the registrars (for many years, they were the only registrar). GoDaddy has become very popular by dramatically undercutting the cost. Note, though, that both of these registrars have been accused of questionable business practices:

  • Network Solutions has engaged in “Front Running“, a questionable practice of locking domains that a potential customer might search for in order to block competitors from making the sale. They will also use subdomains of your domain to advertise, a practice called subdomain hijacking. A decent registrar will not seek to make profits based on your intellectual property.
  • GoDaddy famously suspends accounts based on corporate requests. In 2007, they suspended seclists.org, a website that archives internet security mailing lists, per the request of MySpace, with no court order or valid complaint. MySpace was upset that content posted to one of the lists that Seclists archived was inappropriate. But, instead of contacting Seclists to deal with the content in question, GoDaddy closed the site and wouldn’t respond to desperate emails or phone calls regarding the sudden closure. Worse, after the fiasco was resolved, they were unrepentant, and reserve the right to shut down any site for any spurious reason. If your NPO does work that is in the least bit controversial, keep this in mind when considering GoDaddy.

Web Hosting and Registrars

Many registrars supplement their business by providing web hosting services as well. Some will even offered discounted or free domain registration with a hosting plan. While this simplifies things, it can also be a bit risky in the “eggs in one basket” sense. Having a separate registrar and control over your DNS service allows you to be more flexible with switching hosts, should your current host prove themselves unreliable or go out of business. And the web hosting industry is pretty volatile, with companies coming and going pretty quickly. I would suggest a best practice is to keep your host and registrar separate.

Dealing With Domains – Part 1

This post originally appeared on the Idealware Blog in January of 2010.

.biz .com .edu .org .net .gov .info .mil

Domain Name Management: not a very sexy topic. This will be a rare post for me that won’t mention popular search engines, the latest “superphone“, content management or rumored tablets. But I hope I can provide a good glossary on a geeky subject that anyone with a web site sporting their organization’s name has to deal with.

You have a web site and you have a domain, and as long as the web site is up and running, everything is fine. But what happens if your domain is hijacked? What if you need to make changes to your domain registration, or register a new one, and your registrar is simply disinterested? What if they go out of business? Your domain name is a valuable property, and you should keep it in pro-active and trustworthy hands.

How Domain Registration Works

Domain registrars provide the service of keeping your domain name mapped with current information so that it can be found on the web. Domain names are meaningful aliases for numeric IP addresses, and aren’t technically required in order to host a web site. But, the internet would be hard to navigate if we could only find things by their numeric addresses.

The primary thing that a registrar does is to keep your contact (whois) data maintained; point your domain to the appropriate name servers; and allow you to move your domain to another registrar if you choose to.

Domain Services

In addition to domain registration, most registrars offer additional services, such as:

DNS Management (address mapping) for subdomains (which allows you to host your main domain on one server, but, perhaps, an online store called “store.yourdomain.com” on another server),Aliasing of Addresses (so that both http://yourdomain.com and http://www.yourdomain.com go to the same place),Backup Mail Handling, so, should your primary mail server go down, messages sent to you will be stored until they come back around;Web Forwarding, so you can, say, register yourdomain.org, yourdomain,.com and yourdomain.net, but forward all visitors to the .com and .net sites to your website at yourdomain.org.

SSL (Secure Socket Layer) Certificates, to encrypt sensitive data, like online donation forms.

Things to Look For in a New Registrar

  1. Are they accredited? ICANN, the organization that oversees domain management , accredits registrars. If they aren’t on ICANN’s list, they aren’t trustworthy.
  2. Do they add a year to the existing expiration date, or charge you for a full year as of engagement? They should do the former.
  3. Do they offer automated access to all functions (via web forms), including locking/unlocking domains, retrieval of authorization (EPP) codes, and modification of all whois records? (Some registrars prefer to list themselves as the technical contact. It should be up to you whether they can have an official name on your domain, not them).
  4. Do they list a telephone number, and is it promptly answered during business hours?
  5. Do they respond promptly to emails and support requests? The ability to communicate with your registrar is rarely needed, but, when it is, it’s critical – you don’t want them out of the loop if your domain is subject to an attempted hijack.
  6. Do they offer the ability to manage DNS for mail servers and subdomains? While this is an added feature, it’s common enough to be worth expecting.
  7. Do they have any additional services (examples above)? While these supplemental services are far from critical, they are convenient. More to the point, a company that is engaging in a robust suite of services is more likely to be focused on their business. The truth is that anyone can be a domain registrar, if they make the proper investment, but whether it’s a going concern or a neglected piece of extra income for them is a question you’ll want to ask.

Next week: Safely transferring domains and a word on web hosting completes the topic.