4 ms·

Namecheap is not a losing registrar, HE is not a gaining registrar, and the transaction you describe with Namecheap requesting that they update your registratio

Namecheap is not a losing registrar, HE is not a gaining registrar, and the transaction you describe with Namecheap requesting that they update your registration's nameservers to HE's is not a domain transfer. You're conflating registration with nameserver assignment.

amiga386 2y ago
I'm not trying to conflate it, but I'm trying to imagine why you would ever switch your domain's NS entries away from your current registrar's nameservers, and the only reason I can think of is that you'd want a registrar transfer -- which should and I think does have more ownership checks around it. However, other posters have given a more plausible example: you have server hosting with someone who isn't also a registrar, so for simplified management, you get your registrar to point your domain's nameserver at the server hosting company's nameservers, delegating it all to them... now you just need one customer portal to update all your hosting and DNS entries... and then you leave the hosting company (maybe the bill's too much), and you also forget to clean up the NS records, pointing them back to the real registrar's nameservers, so they're still pointing at this server hosting company you're no longer a customer of. The hosting company isn't a registrar and is under no obligation to follow ICANN policies, so they can give the domain to some other customer of theirs without doing any verification. (I'm not sure they can do domain ownership validation, if they're not a registrar themselves)
- nickburns 2y ago
  I personally keep my domain registrations and zone files separate as a matter of security policy. I place as much importance on vetting reputable DNS providers as I do registrars. Nameserver assignment remains with the ICANN-accredited registrar. (I would also never maintain a registration nor a zone file with a web/cloud hosting service.)
- vel0city 2y ago
  I've often run my registrars separate from my nameservers. Maybe I'm self hosting my nameservers. Maybe the nameservers are tied to the rest of my hosting (for ease of dynamic hosting) but want the ability to rapidly migrate if the hosting provider goes down. If the registrar is my nameserver host, good luck changing the SOA and NS records when SHTF at your host.
- davchana 2y ago
  > why you would ever switch your domain's NS entries away from your current registrar's nameservers, I want my domains at dynadot or namecheap or hexonet, but want CloudFlare to manage all DNS. CF doesn't support al ccTLDs.
- davchana 2y ago
  > so they can give the domain to some other customer of theirs without doing any verification Hosting company can not "give" the domain to anybody. If domain is still pointing to Hosting with NS records, anybody could make an account at Hosting, and add that domain. Now that scammer controls whats visible at Domain, but he is not yet the owner of domain. Owner is who control and can change NS records. Scammer can change all other records, but not NS. NS is at original domain registrar. Original owner can very easily change the NS and cut the scammer out of everything (& should). Gitlab used to be like this. You add a domain to Gitlab. You add an A record to your domain registrar or NS Manager. Now your domain shows your Gitlab Page. After few months, you don't want the pages anymore. You delete the project from Gitlab. You ignore to delete the A Record. Scammer adds that domain to his Gitlab, and shows his content at your domain. Now Gitlab asks you to add a verification TXT record when adding any domain. Scammer's veri record is different. He can't prove that he owns the domain.
  - amiga386 2y ago
    > Hosting company can not "give" the domain to anybody. > Gitlab used to be like this That's what I'm saying. Hosters can "give" a domain (i.e. control of that domain's records on their nameserver only) to someone else, because they're not registrars and aren't _required_ by some painful business contract with ICANN to have to take change of ownership seriously. They should require a domain validation challenge to add a new domain, like your Gitlab example, but it doesn't seem like anyone can make them. So therefore the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control!
    - nickburns 2y ago
      > the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control! That's exactly right. That is how this "attack" happens. Bad actor exploits registrant's abandoned yet still authoritative third-party nameservers assignment. Discussion elsewhere in this thread[1] of how some of that responsibility/risk could be spread/shifted onto the DNS provider. [1] https://news.ycombinator.com/item?id=41126976 https://news.ycombinator.com/item?id=41126976

amiga386 2y ago

I'm not trying to conflate it, but I'm trying to imagine why you would ever switch your domain's NS entries away from your current registrar's nameservers, and the only reason I can think of is that you'd want a registrar transfer -- which should and I think does have more ownership checks around it. However, other posters have given a more plausible example: you have server hosting with someone who isn't also a registrar, so for simplified management, you get your registrar to point your domain's nameserver at the server hosting company's nameservers, delegating it all to them... now you just need one customer portal to update all your hosting and DNS entries... and then you leave the hosting company (maybe the bill's too much), and you also forget to clean up the NS records, pointing them back to the real registrar's nameservers, so they're still pointing at this server hosting company you're no longer a customer of. The hosting company isn't a registrar and is under no obligation to follow ICANN policies, so they can give the domain to some other customer of theirs without doing any verification. (I'm not sure they can do domain ownership validation, if they're not a registrar themselves)

nickburns 2y ago
I personally keep my domain registrations and zone files separate as a matter of security policy. I place as much importance on vetting reputable DNS providers as I do registrars. Nameserver assignment remains with the ICANN-accredited registrar. (I would also never maintain a registration nor a zone file with a web/cloud hosting service.)
vel0city 2y ago
I've often run my registrars separate from my nameservers. Maybe I'm self hosting my nameservers. Maybe the nameservers are tied to the rest of my hosting (for ease of dynamic hosting) but want the ability to rapidly migrate if the hosting provider goes down. If the registrar is my nameserver host, good luck changing the SOA and NS records when SHTF at your host.
davchana 2y ago
> why you would ever switch your domain's NS entries away from your current registrar's nameservers, I want my domains at dynadot or namecheap or hexonet, but want CloudFlare to manage all DNS. CF doesn't support al ccTLDs.
davchana 2y ago
> so they can give the domain to some other customer of theirs without doing any verification Hosting company can not "give" the domain to anybody. If domain is still pointing to Hosting with NS records, anybody could make an account at Hosting, and add that domain. Now that scammer controls whats visible at Domain, but he is not yet the owner of domain. Owner is who control and can change NS records. Scammer can change all other records, but not NS. NS is at original domain registrar. Original owner can very easily change the NS and cut the scammer out of everything (& should). Gitlab used to be like this. You add a domain to Gitlab. You add an A record to your domain registrar or NS Manager. Now your domain shows your Gitlab Page. After few months, you don't want the pages anymore. You delete the project from Gitlab. You ignore to delete the A Record. Scammer adds that domain to his Gitlab, and shows his content at your domain. Now Gitlab asks you to add a verification TXT record when adding any domain. Scammer's veri record is different. He can't prove that he owns the domain.
- amiga386 2y ago
  > Hosting company can not "give" the domain to anybody. > Gitlab used to be like this That's what I'm saying. Hosters can "give" a domain (i.e. control of that domain's records on their nameserver only) to someone else, because they're not registrars and aren't _required_ by some painful business contract with ICANN to have to take change of ownership seriously. They should require a domain validation challenge to add a new domain, like your Gitlab example, but it doesn't seem like anyone can make them. So therefore the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control!
  - nickburns 2y ago
    > the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control! That's exactly right. That is how this "attack" happens. Bad actor exploits registrant's abandoned yet still authoritative third-party nameservers assignment. Discussion elsewhere in this thread[1] of how some of that responsibility/risk could be spread/shifted onto the DNS provider. [1] https://news.ycombinator.com/item?id=41126976 https://news.ycombinator.com/item?id=41126976