4 ms·

I'm in the registrar space (not affiliated with moniker at all). I will tell you what the real issue is. New gTLD's. (think .web,.app,.house,.car,etc) They have

I'm in the registrar space (not affiliated with moniker at all). I will tell you what the real issue is. New gTLD's. (think .web,.app,.house,.car,etc) They have forced everyone to at minimum update their provisioning and billing systems. Some had older and crustier systems than others so its not surprising to see this at all. Once you update, its hard to make sure you caught every single business rule and weird edge case from your old system and given many of the ccTLD's and gTLD's all have slightly different ways of handling things (.eu domains have no admin contact, .be domains must actually be renewed 30 days before they expire or you lose it) its quite the nightmare and if its a really old system, those tweaks are not evident. Testing is also quite difficult as the ot&e environments the registries provide are 1) not exactly like their live system 2) require you to create a domain in order to do anything else. So in order to test your new system with actual data, you need to create every single domain in your live system on test. Then issue the commands to put it in exactly the same state as live, however, you cannot mirror a domain perfectly as sometimes its state is set by the registry for legal issues (udrp,etc). It would be much simpler if they just copied live to their sandbox periodically. I'm not defending them, their launch could have definitely gone much better, but I've been in their shoes and I feel for the tech folks there who are probably spending a lot of late nights at the office and working weekends right now.

boobsbr 12y ago
> Once you update, its hard to make sure you caught every single business rule and weird edge case from your old system One of the reasons we're trying to migrate our rules to a rules engine. They're scattered across pages, Javascript, controllers, services and DAOs... No one knows all the business rules of the system, not even the BAs.
- robalfonso 12y ago
  Exactly, we obscure all the weird registry stuff behind an object it figures out what it needs to do that's different. Billing system is the same way. Though the real difficulty is that so much of it is configuration (in the registrar space). Piles and piles of xyz happens on day 30 for this tld, day 5 for this one,etc. Also of interest is that not all registries even support the standard set of commands for updating domains/contacts/nameservers which is quite obnoxious.
- sanderjd 12y ago
  It seems like the hardest (or maybe just most tedious) part of this sort of thing is keeping the rules on the front-end and the rules on the back-end consistent. Obviously the back-end needs to be the canonical source of truth, but it's nicer for the user if the front-end knows the rules too so that it can do the right thing prior to a full request cycle. I'd be interested to know if you've come up with a good solution to this, because I haven't found any that are very satisfying.
larrys 12y ago
".be domains must actually be renewed 30 days before they expire or you lose it" (In the space as well). I think I would point out here what you are (probably) referring to which may not be obvious to HN readers by "must actually be renewed". Domains in .com .net .org .info are auto renewed at the registry level. It's then up to the registrar to delete them if the customer doesn't want the name. With cnoi they have 45 days to do so a grace period that they typically extend to their customers. I'm assuming (since I'm not familiar with .be in particular) that in that cctld a registrar must proactively renew a name prior to expiration or lose the name. Edit: fixed gtld to cctld
- robalfonso 12y ago
  This is correct. I'm referring to the registrar-registry relationship and not customer-registrar relationship. In .com,.net,.org for example auto renew occurs at 12am the day of expiration. However, for some of the odd ones like .be if you haven't issued a renew command 30 days prior to expiration then its the same as issuing a delete on the day of expiration and have it immediately take effect (normally domains go into pendingDelete status for a limited amount of time before actually being deleted). Also to clarify .be is a ccTLD not a gTLD and so they have a different set of standards and rules as far as ICANN is concerned. I would love it if all domains would just auto renew by the registry and we'd send the delete command if customers didn't want them. Its what I want for christmas :)
  - larrys 12y ago
    "Its what I want for christmas :)" No you don't you want some 2 letter .com's for Christmas.
    - robalfonso 12y ago
      Well I just snagged a 3 letter co.com so that was nice, santa doesn't have the pockets for a 2 letter .com unfortunately

boobsbr 12y ago

> Once you update, its hard to make sure you caught every single business rule and weird edge case from your old system One of the reasons we're trying to migrate our rules to a rules engine. They're scattered across pages, Javascript, controllers, services and DAOs... No one knows all the business rules of the system, not even the BAs.

robalfonso 12y ago
Exactly, we obscure all the weird registry stuff behind an object it figures out what it needs to do that's different. Billing system is the same way. Though the real difficulty is that so much of it is configuration (in the registrar space). Piles and piles of xyz happens on day 30 for this tld, day 5 for this one,etc. Also of interest is that not all registries even support the standard set of commands for updating domains/contacts/nameservers which is quite obnoxious.
sanderjd 12y ago
It seems like the hardest (or maybe just most tedious) part of this sort of thing is keeping the rules on the front-end and the rules on the back-end consistent. Obviously the back-end needs to be the canonical source of truth, but it's nicer for the user if the front-end knows the rules too so that it can do the right thing prior to a full request cycle. I'd be interested to know if you've come up with a good solution to this, because I haven't found any that are very satisfying.

larrys 12y ago

".be domains must actually be renewed 30 days before they expire or you lose it" (In the space as well). I think I would point out here what you are (probably) referring to which may not be obvious to HN readers by "must actually be renewed". Domains in .com .net .org .info are auto renewed at the registry level. It's then up to the registrar to delete them if the customer doesn't want the name. With cnoi they have 45 days to do so a grace period that they typically extend to their customers. I'm assuming (since I'm not familiar with .be in particular) that in that cctld a registrar must proactively renew a name prior to expiration or lose the name. Edit: fixed gtld to cctld

robalfonso 12y ago
This is correct. I'm referring to the registrar-registry relationship and not customer-registrar relationship. In .com,.net,.org for example auto renew occurs at 12am the day of expiration. However, for some of the odd ones like .be if you haven't issued a renew command 30 days prior to expiration then its the same as issuing a delete on the day of expiration and have it immediately take effect (normally domains go into pendingDelete status for a limited amount of time before actually being deleted). Also to clarify .be is a ccTLD not a gTLD and so they have a different set of standards and rules as far as ICANN is concerned. I would love it if all domains would just auto renew by the registry and we'd send the delete command if customers didn't want them. Its what I want for christmas :)
- larrys 12y ago
  "Its what I want for christmas :)" No you don't you want some 2 letter .com's for Christmas.
  - robalfonso 12y ago
    Well I just snagged a 3 letter co.com so that was nice, santa doesn't have the pockets for a 2 letter .com unfortunately