Here’s a question every synagogue should be able to answer:
Where is your domain name registered?
If your website is oursynagogue.org, someone registered that domain name through a company called a domain registrar.
There’s an account.
There’s a username and password.
There’s probably a credit card associated with it.
There’s an email address that receives renewal notices and security notifications.
And somewhere in your synagogue, someone should know where all of that is.
You’d be surprised how often nobody does.
“I Think Someone on the Board Set That Up”
This is a situation I encounter regularly when beginning a synagogue website project.
The congregation has had its domain name for years — sometimes decades.
But nobody currently on staff knows where it’s registered.
Perhaps a former board member handled it.
Maybe a volunteer set everything up when the synagogue launched its first website.
The executive director who knew the login left six years ago.
Someone thinks the information might be in an old email account.
Or the domain is registered under the personal account of a congregant nobody has spoken to in years.
As long as the website keeps working, nobody has a reason to think about it.
Then it’s time to launch a new website.
And suddenly, that forgotten account becomes very important.
Your Domain Name Is One of Your Synagogue’s Most Important Digital Assets
Your domain name isn’t just your website address.
It’s part of your synagogue’s identity.
It may also be connected to your email addresses. If your staff uses addresses such as or , the domain plays a role there, too.
Losing control of the domain can potentially affect both your website and email.
At a minimum, every synagogue should know:
- Which company is the domain registrar
- The username or account used to manage the domain
- Which synagogue-controlled email address receives account notifications
- Who has authorized access to the account
- How two-factor authentication is handled
- When the domain renews
- How the renewal is paid
And ideally, this information should not live solely inside one person’s head.
Avoid Using Personal Accounts When Possible
A recurring problem with organizational technology is that something important gets attached to an individual’s personal account.
A volunteer registers the synagogue’s domain using a personal Gmail address.
Years later, that person is no longer on the board.
The domain still works, so nobody notices.
Until someone needs to make a change.
Whenever possible, critical digital assets should be controlled by the synagogue itself.
That doesn’t mean everyone needs the password.
In fact, they shouldn’t.
But the organization should have a documented process for accessing the account, and more than one appropriate person should know that process.
The same principle applies beyond domains.
Know who controls your:
- Website hosting
- DNS
- WordPress administrator accounts
- Google accounts
- Analytics
- Email platform
- ShulCloud account
- Social media accounts
- Online payment accounts
- Other important digital services
Staff members and volunteers will change.
The synagogue’s access to its own technology shouldn’t change with them.
The Domain, Website and Hosting Are Not the Same Thing
This is where things can get confusing.
People often talk about “the website” as though it’s one thing.
Technically, several different services may be involved.
The domain registrar
This is the company where your domain name is registered.
Think of it as the organization responsible for maintaining your ownership and registration of oursynagogue.org.
The web host
This is where the website itself lives.
If your site runs on WordPress, the files, database, images and other website data are stored on a server somewhere.
That’s your web host.
The website
This is the actual collection of pages, images, content and functionality people see when they visit your domain.
DNS
DNS is the system that connects everything together.
And that’s the part that becomes especially important when you launch a new website.
What Is DNS?
DNS stands for Domain Name System.
The easiest way to think about it is as the internet’s directory.
People understand:
oursynagogue.org
Computers ultimately need to know which server or service should handle a request for that domain.
DNS provides those instructions.
When someone types your synagogue’s domain into a browser, DNS helps direct that request to the appropriate place.
DNS can also contain instructions for other services associated with the domain, including email.
That’s why changing DNS settings needs to be done carefully.
You’re not necessarily changing only the website.
What Are Nameservers?
Nameservers tell the internet where to look for the DNS records for your domain.
That’s slightly different from the DNS records themselves.
Imagine that DNS is a set of instructions.
The nameservers tell everyone:
“The authoritative copy of those instructions is over here.”
A domain might use nameservers provided by the registrar, hosting company, Cloudflare or another DNS provider.
When you’re moving a website to a new hosting environment, there are generally two approaches.
You might keep the existing nameservers and change only the DNS records necessary to point the website to its new server.
Or you might change the nameservers so that an entirely different provider becomes responsible for the domain’s DNS.
Those aren’t quite the same thing.
And changing nameservers deserves particular care because the DNS zone may contain much more than the records for the website.
Be Especially Careful About Email
This is one of the most important things to understand when changing DNS.
Your synagogue’s DNS may contain records that tell the internet where to deliver your email.
If those records disappear or are configured incorrectly, the new website may work beautifully while synagogue email stops working.
That’s not a successful launch.
Before changing nameservers, make sure the existing DNS records have been identified and that any records required for email and other services are preserved.
This is one reason I don’t recommend treating DNS changes casually.
Changing where a domain points may look like a couple of simple fields in an account dashboard.
Those fields can affect important systems throughout the organization.
What Does It Mean to “Point” a Domain?
When a new synagogue website is ready to launch, I often describe the final step as pointing the domain to the new website.
The domain itself isn’t moving.
The new website has already been built somewhere else.
We’re simply changing the DNS instructions so that when someone requests oursynagogue.org, they’re directed to the new hosting environment instead of the old one.
Think of it like changing the forwarding instructions for an address.
The name stays the same.
Where it leads changes.
Why Doesn’t a DNS Change Happen Instantly?
This is where another unfamiliar term appears:
DNS propagation.
When you change a DNS record or nameserver, the entire internet doesn’t necessarily learn about the change at the exact same moment.
DNS information is cached in many places.
That means one person may see the new website while another person still sees the old one.
Someone on their phone may get the new site while their office computer continues reaching the old server.
Eventually, those cached records expire and the updated information is retrieved.
That’s what people generally mean when they talk about waiting for DNS changes to “propagate.”
How Long Does DNS Propagation Take?
There’s no single answer.
Some DNS changes may appear for you within minutes.
Others can take several hours.
And depending on the type of change, the previous DNS settings and how long information is being cached, it can sometimes take 24 to 48 hours for the change to be reflected consistently everywhere.
That doesn’t necessarily mean something is wrong.
It’s simply part of how DNS works.
This is also why I don’t like making important DNS changes five minutes before everyone leaves the office on Friday.
Give yourself time to test.
What Is TTL?
Another term you may encounter is TTL, which stands for Time to Live.
A DNS record’s TTL essentially tells other systems how long they’re allowed to cache that information before checking for an updated version.
For example, if a record has a relatively long TTL, other DNS resolvers may continue using the old information for longer after you make a change.
Before a planned website launch, a web professional may lower the TTL on relevant DNS records ahead of time.
That can help make the eventual transition happen more quickly.
But lowering the TTL five seconds before changing the record doesn’t magically erase copies that have already been cached under the previous setting.
Planning ahead matters.
Nameserver Changes Can Be More Involved
Changing an individual DNS record and changing nameservers aren’t identical operations.
If you’re simply changing the address that tells visitors where the website lives, you may only need to update an A record, AAAA record, or CNAME, depending on the setup.
Changing nameservers transfers responsibility for the domain’s DNS to a different DNS provider.
That means the complete set of necessary DNS records needs to exist in the new location.
Website.
Email.
Domain verification.
Email authentication.
Other services.
If something important is missing, that service may stop working once the new nameservers take effect.
So while changing nameservers may be appropriate in some situations, I don’t do it simply because there’s a new website.
Change only what actually needs to change.
Plan the Launch Before Launch Day
A smooth website launch starts before the new website is finished.
Early in the project, determine:
Where is the domain registered?
Who can log into the account?
Where is DNS currently managed?
Who hosts the existing website?
Who handles the synagogue’s email?
Are there other services connected through DNS?
If nobody knows the answers, start investigating early.
Don’t wait until the new website is finished and everyone is excited to launch.
Domain-account archaeology can take time.
Keep a Digital Account Inventory
I recommend that synagogues maintain a simple, secure inventory of their important digital services.
Not necessarily a spreadsheet containing every password in plain text.
Please don’t do that.
But maintain a record of:
Service: Domain registration
Provider: [Company name]
Account owner: Synagogue-controlled email
Authorized users: [appropriate staff]
Two-factor authentication: [how it is managed]
Renewal: [date/payment method]
Purpose: Controls registration of synagogue domain
Do the same for hosting, DNS, email and other essential systems.
Passwords themselves should be stored securely, ideally using an appropriate password-management system.
The goal is that a future executive director shouldn’t have to ask:
“Does anybody know where our domain is?”
Review Access When Staff and Leadership Change
Digital access should be part of your transition process whenever someone leaves a staff or volunteer role.
Remove accounts that are no longer needed.
Transfer responsibilities.
Update recovery information.
Make sure two-factor authentication isn’t sending codes to the cell phone of someone who retired three years ago.
And periodically confirm that the contact information associated with your domain is still valid.
These aren’t exciting website tasks.
But they’re much easier to deal with before there’s an emergency.
Your Website Can Be Rebuilt. Your Domain Is Harder to Replace.
If a website disappears tomorrow and you have good backups, it can be restored.
If necessary, a completely new website can be built.
Your domain name is different.
It’s the address people know.
It’s printed on materials.
It’s linked from other websites.
It may be connected to years of search-engine history.
And it may be the domain your organization uses for email.
Treat control of it accordingly.
Know where it’s registered.
Know who has access.
Know where DNS is managed.
Document the systems that depend on it.
And when it’s time to launch a new website, don’t let the