4 ms·

If you can't trust a team to set a calendar reminder / create a ticket to renew a domain once a year ... what exactly can you trust them with? The only excuse

If you can't trust a team to set a calendar reminder / create a ticket to renew a domain once a year ... what exactly can you trust them with? The only excuse I would understand is turn-over. Otherwise, I would say that the organization in question has to get more comfortable with firing their employees.

AnthonyMouse 3y ago
In general domains are set to auto-renew. The problem isn't remembering to do it. It's generally one of two things. First, the payment method on file with the registrar became invalid. Often because of turnover as you say -- the old IT manager's company credit card got turned off and the payment failed emails went to their email address, also turned off. Sometimes for other reasons, e.g. the credit card company changed the card number because of a data breach and then the non-payment notification got caught in a spam filter. Second, there's somebody whose job it is to check which of the company's 5000 domain names are still being used. They find one with no public DNS records, or old ones that point to nothing. They call up the web server team and the email team and ask what it is, they've never heard of it because it's not them using it. So they cancel the domain -- and the company doesn't even notice at first because the internal systems carry on using the name as ever, until somebody else registers it and starts using it.
- iscoelho 3y ago
  I understand why this is a common issue, but I also believe that this is indicative of organizational dysfunction. It takes a few seconds to document what a domain is used for / what department is using it. If you have 5,000 domains, you're already doing this. As well, at that scale you're likely using an enterprise domain registrar, so there is absolutely zero possibility of a domain expiring. (If you're not ... phew) Many other industries with zero tolerance for failure are able to successfully implement multi-layered approaches for anticipating and eliminating issues. Yet, IT manages to find excuses to explain why a $10 domain can't be reliably renewed. That's wild. That's embarrassing.
  - AnthonyMouse 3y ago
    > It takes a few seconds to document what a domain is used for / what department is using it. Sure, and then you have a piece of documentation that says the domain is being used by "IT" for "account services" and the person reading this thinks it's the web server administrators using it for customer accounts and they say they're not using it. > As well, at that scale you're likely using an enterprise domain registrar, so there is absolutely zero possibility of a domain expiring. The company where the domain expires for non-payment and the company with 5000 domains don't have to be the same company, or the same division of the same company. > Many other industries with zero tolerance for failure are able to successfully implement multi-layered approaches for anticipating and eliminating issues. Yet, IT finds excuses to explain why a $10 domain can't be reliably renewed. That's wild. That's embarrassing. The traditional approach to this is to operate with redundancy. Domain registrations are a single point of failure consequent of having a single global hierarchical namespace. One way to mitigate this is to relax the global uniqueness requirement in instances where it isn't necessary, like internal use domains, so you can't "lose" the domain since nobody has exclusive control over it. To do that you'd need to carve out a piece of the hierarchy for that use so it doesn't conflict with other names that have to be globally unique. Which is the current proposal.
    - iscoelho 3y ago
      As demonstrated by a majority of Fortune 100 companies (including google.com & microsoft.com), the industry accepted solution to this is an enterprise domain registrar, for example MarkMonitor or CSC. A disproportionate amount of the internet depends on those 2 domains, and even so, there is zero redundancy for the situation you are describing. It's just that simple though: there doesn't need to be. This is a solved problem that does not occur in competently run organizations. Domains do not need to be a failure point, and if they are, you should put more focus on resolving the deeper issues within your organization.

AnthonyMouse 3y ago

In general domains are set to auto-renew. The problem isn't remembering to do it. It's generally one of two things. First, the payment method on file with the registrar became invalid. Often because of turnover as you say -- the old IT manager's company credit card got turned off and the payment failed emails went to their email address, also turned off. Sometimes for other reasons, e.g. the credit card company changed the card number because of a data breach and then the non-payment notification got caught in a spam filter. Second, there's somebody whose job it is to check which of the company's 5000 domain names are still being used. They find one with no public DNS records, or old ones that point to nothing. They call up the web server team and the email team and ask what it is, they've never heard of it because it's not them using it. So they cancel the domain -- and the company doesn't even notice at first because the internal systems carry on using the name as ever, until somebody else registers it and starts using it.

iscoelho 3y ago
I understand why this is a common issue, but I also believe that this is indicative of organizational dysfunction. It takes a few seconds to document what a domain is used for / what department is using it. If you have 5,000 domains, you're already doing this. As well, at that scale you're likely using an enterprise domain registrar, so there is absolutely zero possibility of a domain expiring. (If you're not ... phew) Many other industries with zero tolerance for failure are able to successfully implement multi-layered approaches for anticipating and eliminating issues. Yet, IT manages to find excuses to explain why a $10 domain can't be reliably renewed. That's wild. That's embarrassing.
- AnthonyMouse 3y ago
  > It takes a few seconds to document what a domain is used for / what department is using it. Sure, and then you have a piece of documentation that says the domain is being used by "IT" for "account services" and the person reading this thinks it's the web server administrators using it for customer accounts and they say they're not using it. > As well, at that scale you're likely using an enterprise domain registrar, so there is absolutely zero possibility of a domain expiring. The company where the domain expires for non-payment and the company with 5000 domains don't have to be the same company, or the same division of the same company. > Many other industries with zero tolerance for failure are able to successfully implement multi-layered approaches for anticipating and eliminating issues. Yet, IT finds excuses to explain why a $10 domain can't be reliably renewed. That's wild. That's embarrassing. The traditional approach to this is to operate with redundancy. Domain registrations are a single point of failure consequent of having a single global hierarchical namespace. One way to mitigate this is to relax the global uniqueness requirement in instances where it isn't necessary, like internal use domains, so you can't "lose" the domain since nobody has exclusive control over it. To do that you'd need to carve out a piece of the hierarchy for that use so it doesn't conflict with other names that have to be globally unique. Which is the current proposal.
  - iscoelho 3y ago
    As demonstrated by a majority of Fortune 100 companies (including google.com & microsoft.com), the industry accepted solution to this is an enterprise domain registrar, for example MarkMonitor or CSC. A disproportionate amount of the internet depends on those 2 domains, and even so, there is zero redundancy for the situation you are describing. It's just that simple though: there doesn't need to be. This is a solved problem that does not occur in competently run organizations. Domains do not need to be a failure point, and if they are, you should put more focus on resolving the deeper issues within your organization.