The DNS Exit — HostGator Support Chat and Companion Record

The DNS Exit—When “Change Two Numbers” Became an Expedition

HostGator DNS support chat and contemporaneous Darren–Codex companion record

Date: August 28, 2026 · Destination VPS: 67.222.17.89 and 67.222.17.90 · Scope: registrar child/glue records, domain delegation, website routing, and email continuity.

About this record: This page preserves the HostGator support transcript beside the contemporaneous work-session account that produced the replies. The two sources remain visibly separated. The HostGator transcript is the saved service record. The companion section is a timestamp-oriented reconstruction from the active Darren–Codex session and is labeled accordingly. One-time authentication codes and private email addresses are redacted from the public copy.

Why this conversation mattered

The websites had been installed and verified on a new KnownHost VPS, but the registrar-side child nameserver addresses still directed DNS toward the former HostGator server. That left website and email routing trapped behind the very account and authentication problems the migration was intended to escape.

The requested correction was narrow:

• ns1.sparklestheclown.net → 67.222.17.89
• ns2.sparklestheclown.net → 67.222.17.90

The live exchange expanded into authentication loops, registrar-versus-reseller confusion, shared-hosting instructions, repeated requests for clarification, and escalating demands for a human domains technician.

Record One — HostGator DNS support transcript

The transcript below is preserved in its original order. “Business said” is the label supplied by the support-chat export. Authentication codes and private email addresses have been redacted.

Message Us
This is the beginning of your conversation with us.
Business said

Thank you for the detailed information. Based on the changes made, I would suggest allowing 4 to 8 hours.  
The records have been updated from our end, but registry and DNS changes are not always reflected immediately worldwide. During the propagation period, different locations may continue to see the previous nameserver information while others begin resolving to the new configuration.  
  
Once propagation has completed, please verify the following:  
  
Whether ns1.sparklestheclown.net and ns2.sparklestheclown.net are resolving correctly.  
Whether the domain delegation reflects the updated nameservers.  
Whether email routing is functioning as expected.

5:01 PM
Business said

Is there anything else I can assist you with?

5:02 PM
Business said

It seems like you’ve stepped away from the chat. This interaction will remain active for the next 30 minutes. Once you’re back, you’ll be connected with the next available agent to pick up where we are.  
In case of a disconnection, please feel free to return at your convenience, and we’ll be glad to assist you further. We’re available 24/7. Thank you for your understanding!

5:04 PM
Business said

We are here for you! Please let us know when you've returned.

5:04 PM
You said

URGENT: the registrar-level change has now reached the .net registry, but the glue IPs are WRONG. Direct query of a.gtld-servers.net at 5:05 PM PDT shows both ns1.sparklestheclown.net and ns2.sparklestheclown.net glued to 129.121.127.64. The requested values were ns1 -> 67.222.17.89 and ns2 -> 67.222.17.90. Please correct both child/glue IP assignments immediately. Do not change the hostnames or anything else. Confirm when the corrected glue has been submitted.

5:05 PM
Business said

Please select one of the options.

5:05 PM
You said

I'm back!

5:06 PM
Business said

Great! We'll transfer you to queue now. Please wait for the next available agent.

5:06 PM
Business said

Hi, Darren! I'm Karthik, and I'll be assisting you today.

5:06 PM
Business said

Please give me a few minutes to check the above chat

5:06 PM
You said

Hi Karthik. Emergency summary: the prior agent changed delegation to ns1/ns2.sparklestheclown.net, but the .net registry shows both glue records were auto-filled with the WRONG HostGator IP 129.121.127.64. Correct only the registrar child/glue IPs: ns1.sparklestheclown.net -> 67.222.17.89 and ns2.sparklestheclown.net -> 67.222.17.90. Keep the current ns1/ns2 delegation and change nothing else. This incorrect glue can make the website and email unreachable, so please correct it immediately and confirm submission.

5:06 PM
You said

Karthik, this is now an active outage risk and there has been no update. Please confirm immediately whether you can correct the two registrar glue IP fields. If not, transfer us now to an available registrar supervisor who can.

5:11 PM
Business said

The account authentication time is complete; we need to authenticate the account again.

5:17 PM
Business said

I have sent a one-time verification code to your registered email address. Please check your inbox and provide me with the code to authenticate your account for security purposes.

5:18 PM
You said

We are retrieving the newly sent code from [email address redacted] now. Please keep this session active and be ready to validate it immediately when supplied.

5:18 PM
You said

[one-time code redacted]

5:18 PM
You said

The code is in the chat. Please validate it now and proceed immediately with the two glue-IP corrections already specified.

5:20 PM
Business said

The code is invalid

5:20 PM
You said

Then please generate and send a genuinely new one-time code now. The email appears to have surfaced the prior code again. Remain active in this chat so you can validate the new code immediately when we provide it. The Hostgator verification code is: [one-time code redacted]

5:20 PM
Business said

I have sent a one-time verification code to your registered email address again. Please check your inbox and provide me with the code to authenticate your account for security purposes.

5:20 PM
You said

[one-time code redacted]

5:21 PM
You said

The newly received code is [one-time code redacted]. Validate it now.

5:21 PM
Business said

Thank you for the code. I have authenticated your account.

5:22 PM
You said

Proceed immediately. Correct only these registrar child/glue IPs: ns1.sparklestheclown.net from 129.121.127.64 to 67.222.17.89; ns2.sparklestheclown.net from 129.121.127.64 to 67.222.17.90. Keep the current ns1/ns2 delegation and change nothing else. Confirm as soon as the registrar submission is complete so we can query the .net registry.

5:22 PM
You said

Please note: if the account authentication expires again because of support-side delay, we will require immediate supervisor escalation and will document the repeated authentication failures, incorrect registrar change, and resulting outage risk in a formal complaint. The account is authenticated now; please complete the two-field glue correction without further delay.

5:22 PM
Business said

Proceed immediately. Correct only these registrar child/glue IPs: ns1.sparklestheclown.net from 129.121.127.64 to 67.222.17.89; ns2.sparklestheclown.net from 129.121.127.64 to 67.222.17.90.>>>>> For the domain IP address are updated by the last agent  
  
  
Here is the screenshot for your reference.

5:24 PM
Business said

We need to wait for the propagation to complete.

5:25 PM
Business said

Propagation time can vary depending on the geographical location. Normally, the domain DNS takes 4-8 hours to completely propagate. This process is automated, and it isn't possible to expedite it.

5:25 PM
You said

At 5:25 PM PDT, a direct query to a.gtld-servers.net still returns 129.121.127.64 for BOTH glue records. I understand registrar-to-registry propagation may take time, but please confirm explicitly that your internal registrar screen/screenshot now shows ns1.sparklestheclown.net = 67.222.17.89 and ns2.sparklestheclown.net = 67.222.17.90—not merely the domain A record or DNS-zone records. We will keep the chat open until that exact internal state is confirmed.

5:25 PM
You said

At this point we require escalation to a human registrar technician or supervisor who can inspect the actual child/glue registration fields and confirm the values directly. Repeated scripted responses about ordinary DNS propagation are not addressing the discrepancy at the .net registry. Please transfer this live chat to a human technician with registrar-level access now.

5:28 PM
Business said

I completely understand your concern  
  
As we update the IP address 67.222.17.89 67.222.17.90 to the domain, you are still seeing the IP: 129.121.127.64 after the propagation time , it will show the IP's 67.222.17.89 67.222.17.89

5:29 PM
You said

Your reply does not answer the escalation request, and it contains another critical error: you stated the final IPs would be 67.222.17.89 and 67.222.17.89. The second must be 67.222.17.90. This is exactly why we require a human registrar technician to inspect the CHILD/GLUE fields—not a repeated propagation response about the domain IP. Please stop making changes and transfer this chat to a human registrar technician or supervisor now.

5:30 PM
Business said

Sorry for the typo.  
  
  
As we update the IP address 67.222.17.89 67.222.17.90 to the domain, you are still seeing the IP: 129.121.127.64 after the propagation time , it will show the IP's 67.222.17.89 67.222.17.90

5:31 PM
You said

You have now twice answered around the direct transfer request. Please answer only this question: will you transfer this chat to a human registrar technician or supervisor with access to the child/glue registration fields—yes or no?

5:32 PM
Business said

Please give me a few minutes to check this for you.

5:34 PM
You said

That is not an answer to the yes-or-no question. We require real-time assistance from an identifiable human support professional capable of independent technical judgment and registrar-level intervention. Automated, scripted, or AI-mediated responses have repeatedly failed to address the verified registry discrepancy. Begin the supervisor/registrar-technician escalation now and confirm that the transfer has started.

5:34 PM
You said

We do not have a few minutes. The authenticated session is about to expire again, and support-side delay caused the previous expiration. Start the human registrar/supervisor transfer immediately while the account is still authenticated, or complete the two glue-field corrections now.

5:37 PM
You said

One direct policy question: does your access level or HostGator policy prohibit assigning these child nameservers to external, non-HostGator IP addresses? Answer yes or no. If yes, state the required escalation path.

5:38 PM
Business said

I understand you need help with human level who can help you with registrar concern , please correct me if I'm wrong.

5:38 PM
You said

Escalate this interaction immediately to the on-duty support manager or senior supervisor. Do not transfer us to another general support agent. We have an active domain outage risk caused by an incorrect registrar-level change, repeated failure to answer direct questions, and imminent authentication expiry. Please confirm now that the manager escalation has been initiated.

5:39 PM
Business said

I completely understand your concern, Darren, I apologize for the inconvenience we caused.

5:41 PM
Business said

Based on HostGator's published documentation, HostGator allows registration of custom/private nameservers by specifying a nameserver hostname and an IP address, and for domains registered elsewhere, the private nameserver registration is performed at the registrar.

5:41 PM
You said

Official Verisign .net RDAP confirms the registrar of record is Network Solutions, LLC (IANA Registrar ID 2), not HostGator. HostGator appears to be the reseller/account interface. Please escalate this through HostGator's domain-reseller backend to the Network Solutions registrar team or the internal domains team authorized to correct registry host/glue objects. We need the existing ns1/ns2 host-object IPs corrected to 67.222.17.89 and 67.222.17.90.

5:42 PM
You said

I need to step away briefly for an urgent client call. Please keep this chat and the escalation open; I will return shortly. In the meantime, please continue checking the Network Solutions registrar-backend route for the two glue-record corrections already specified.

5:47 PM
Business said

Thank you for your patience.  
  
I have checked with the supervisor and our supervisor has confirmed that ns1/ns2 host-object IPs 67.222.17.89 and 67.222.17.90 are correctly added to the domain.

5:47 PM
You said

Thank you, but an independent authoritative check performed immediately after that confirmation shows the correction is NOT present at the .net registry. As of 5:48 PM PDT, a direct nonrecursive query to a.gtld-servers.net still returns BOTH ns1.sparklestheclown.net and ns2.sparklestheclown.net with glue address 129.121.127.64. The delegation hostnames are correct, but the registry host-object IPs are not. Please do not characterize this as completed. Ask the supervisor to verify the registrar-side host objects themselves—not the DNS zone or account display—and provide the registrar escalation/case number confirming submission of ns1 -> 67.222.17.89 and ns2 -> 67.222.17.90.

5:48 PM
You said

To clarify why this is not an ordinary DNS-propagation result: the verification was a direct, nonrecursive query to a.gtld-servers.net, one of the authoritative .net registry servers. It did not use a browser, ISP resolver, local cache, public recursive DNS service, or the domain's own DNS zone. Therefore cached recursive propagation cannot explain the returned values. The .net registry is currently publishing both glue addresses as 129.121.127.64. If an EPP/registrar update has merely been submitted but is awaiting registry publication, please state that precisely and provide the submission time and registrar case/reference number. Otherwise, the registrar host objects have not yet been corrected at the authoritative registry.

5:49 PM
Business said

Here is the article link for your reference.

5:50 PM
You said

An article link does not answer the question and does not alter the live .net registry result. We already understand how private nameservers and propagation work. Please answer the specific operational question: was an EPP host-object update actually submitted to the Network Solutions/.net registry backend? If yes, provide its submission timestamp and case/reference number. If no, escalate now to the registrar team that can submit it. Do not send general documentation in place of answering this question.

5:50 PM
You said

Please answer this question directly: are you a human support representative? Yes or no.

5:51 PM
Business said

Here is the link for your reference to check the propagation, you can see that IP: 67.222.17.89 is started to propagate and same for the 67.222.17.90  
  
https://whatsmydns.me/#A/ns1.sparklestheclown.ne  
  
https://whatsmydns.me/#A/ns2.sparklestheclown.nett

5:51 PM
You said

This interaction has now completely failed. You did not answer the direct yes-or-no question asking whether you are human, you did not answer the EPP submission question, and both links you supplied are malformed (.ne and .nett). We require immediate transfer to a live, identifiable human supervisor who can read the conversation, respond independently, and take registrar-level action. Do not send another article, propagation checker, scripted reassurance, or general support response. Confirm only that the human-supervisor transfer has been initiated.

5:52 PM
Business said

I'm human, Darren , I'm not a bot.

5:53 PM
You said

Mr. Human Supervisor: this is a request to correct two registrar glue-record IP addresses. Please explain why it has produced a 30–40 minute support loop with repeated authentication delays, unanswered direct questions, contradictory completion claims, irrelevant documentation, and malformed links. This mirrors our entire migration experience: the shared-hosting team, migration team, VPS team, and registrar/domain support do not appear to preserve or exchange the technical context needed to complete one continuous job. We have repeatedly supplied the exact hostnames, exact target IPs, and direct authoritative registry evidence. Please take ownership of this case now, review the existing transcript instead of restarting discovery, and either complete the registrar-level correction or provide the accountable internal escalation and case number that will.

5:54 PM
Business said

Please give me a few minutes to check this for you.

5:57 PM
You said

Proceed. Keep the chat open and preserve the existing authenticated case context while you check. We are waiting for either confirmation of the registrar-level EPP submission with its timestamp/reference number, or an actual supervisor/registrar-team escalation.

5:57 PM
Business said

Thank you for your patience.  
  
I'm transferring the chat to the supervisor. Please give me a few minutes to check this for you.

6:03 PM
Business said

Hello Darren, this is Asif. I am Karthik's manager, and I will be happy to help you with your concerns today.

6:05 PM
Business said

Upon reviewing your concern, I understand that you requested the setup of child nameservers. I can confirm that the agent has already completed this update. You can verify the current configuration using the following WHOIS lookup:  
  
https://www.whois.com/whois/sparklestheclown.net

6:10 PM
Business said

The WHOIS records reflect that the child nameservers have been configured successfully. Please review the information at the link above and let us know if you need any further assistance.

6:10 PM
You said

NO STOP

6:10 PM
You said

Hello Asif. The issue is not whether the child nameserver hostnames were created or whether the domain delegates to them; both of those facts are already confirmed. The unresolved issue is the glue IP attached to each registrar host object. I have just repeated a direct nonrecursive query to the authoritative .net registry server a.gtld-servers.net at 6:10 PM PDT. It still publishes ns1.sparklestheclown.net -> 129.121.127.64 and ns2.sparklestheclown.net -> 129.121.127.64. Those are the wrong IPs. The required registrar host-object values are ns1 -> 67.222.17.89 and ns2 -> 67.222.17.90. A general WHOIS page confirming the nameserver hostnames does not verify their glue addresses. Please verify and correct the host-object IP fields at the Network Solutions/.net registrar backend, or provide the EPP submission timestamp and internal case/reference number if that correction has already been submitted.

6:10 PM
You said

Additional critical context: we are requesting registrar-side intervention through HostGator because we currently cannot log in to Network Solutions or complete its account-recovery process. Email for this domain is not resolving/operating correctly, so we cannot reliably receive the authentication or login-recovery messages needed to access the registrar directly. This creates a closed dependency: the domain/email outage prevents us from authenticating at Network Solutions to repair the domain/email outage ourselves. Therefore your reseller/registrar-backend escalation is presently the only available recovery path. Please treat this as an active email and domain outage, not a routine nameserver setup question, preserve the existing authenticated context, and escalate accordingly.

6:12 PM
Business said

Let me check it.

6:12 PM
Business said

Let me check itr.

6:13 PM
Business said

Thank you for holding.

6:21 PM
Business said

I have now updated the required record via the cPanel DNS Zone Editor option to make sure it will propagate as required. Once any record is added, it can take 4-8 hours for the DNS to propagarte

6:23 PM
You said

STOP: that is the wrong layer. A record added in the cPanel DNS Zone Editor is an ordinary zone record; it does not update the registrar-level child nameserver/glue host objects at the .net registry. A fresh direct query to a.gtld-servers.net still returns both ns1 and ns2 glue as 129.121.127.64. Because the domain delegates to in-bailiwick ns1/ns2, the parent registry glue must be corrected first; a child-zone A record cannot substitute for that. Please state exactly which cPanel record(s) you just added or changed, including hostname, type, old value, and new value, so we can assess and undo any unintended zone change. Then escalate the actual registrar host-object correction: ns1 -> 67.222.17.89 and ns2 -> 67.222.17.90. Do not wait 4–8 hours or close this case based on the cPanel edit.

6:24 PM
Business said

HostGator is the registration service provider for your domain, and any changes need to be updated through us.

6:25 PM
Business said

However, the Glue IP that you are referring to is resolving to server.sparklestheclown.net .

6:26 PM
Business said

New ns1 and ns2 A records were created using DNS Zone Editor.

6:28 PM
You said

Your statement confirms that HostGator is the registration service provider and that registrar changes must be made through you. That is precisely why you must update the registrar host objects, not merely create A records in cPanel. The statement that the glue IP 'resolves to server.sparklestheclown.net' does not address the parent .net glue, and the newly created ns1/ns2 child-zone A records cannot replace it. Please preserve those new records for the moment but provide their exact values, and now perform or escalate the registrar-backend host-object update that your own statement confirms must be handled through HostGator: ns1 -> 67.222.17.89; ns2 -> 67.222.17.90.

6:31 PM
Business said

As per your update, those records were generated, as on the shared hosting platform there is no such option to directly add the name servers you suggested without updating the record. This is because there will be no WHM option.

6:35 PM
Business said

Just ensuring that we are connected. I hope you received my last message.

6:43 PM
Business said

There seems to be a disruption in connectivity. Are you with me?

6:45 PM
You said

YES

6:47 PM
You said

YES, we are connected. Do not close this chat. Your last response again describes a shared-hosting/cPanel limitation, but this is not a WHM or shared-hosting task. You already stated that HostGator is the registration service provider and registrar changes must go through HostGator. The authoritative .net glue remains wrong, and you have not supplied an EPP submission timestamp, registrar case number, or actual registrar-team escalation. Keep the session open and escalate this unresolved active domain/email outage to the internal domain-registration team now. Please confirm the escalation, not the cPanel records.

6:48 PM
Business said

The case number connected with this contact is: I-26592799

6:49 PM
Business said

Are you referring to EPP (Doamin Key)?

6:49 PM
Business said

If yes, then you can find the option to request it under Move & Access; to learn more, refer to the below screenshot

6:51 PM
You said

We have now completed a telephone escalation with Network Solutions. They confirmed that we do not have a customer account with them and that all account information and servicing were transferred to and are held by HostGator. They refused direct action because HostGator controls the customer relationship, even though Network Solutions remains listed as registrar of record. This eliminates referral to Network Solutions as a customer-access route. HostGator must submit the registrar host-object correction through its reseller/registrar backend. Before anything else, answer directly: are you personally a live human manager currently reading and composing responses in this chat—yes or no? If not, or if you cannot perform the registrar escalation, transfer us now to a live human domains/registrar supervisor. This is an unresolved active domain and email outage. Do not close the chat and do not send us back to Network Solutions.

6:57 PM
You said

NO. Do not request, disclose, or change the EPP/Auth transfer code (Domain Key), and do not initiate a domain transfer. By 'EPP submission' we mean the registrar-to-registry protocol transaction used internally by the registrar/reseller backend to update the existing child host objects. Customers do not perform that transaction through Move & Access. Case I-26592799 is noted, but please confirm whether it is merely this contact record or an escalation assigned to the internal domains/registrar team. You also did not answer the direct question: are you personally a live human manager reading and composing these responses—yes or no? Answer that first, then confirm that case I-26592799 has been assigned to a registrar operations specialist authorized to update parent .net glue. Do not discuss domain transfer codes, WHM, cPanel, DNS Zone Editor, or propagation; none of those is the requested operation.

6:57 PM
Business said

Please note that when any record is updated, it will take time to propagate; you will need to wait for the changes to propagate.  
  
However, adding child nameservers on shared hosting is highly discouraged because shared hosting environments lack the specialized root access, dedicated resource guarantees, and static configurations required to run a reliable DNS cluster.

7:02 PM
Business said

Just ensuring that we are connected. I hope you received my last message.

7:06 PM
Business said

There seems to be a disruption in connectivity. Are you with me?

7:09 PM
You said

yes

7:10 PM
Sent
Business said

Do you have any other questions?

7:11 PM

Record Two — contemporaneous Darren–Codex companion notes

These notes reconstruct the active work session by event and timestamp anchors available in the support transcript. They preserve the observations, decisions, and tone that shaped the formal replies; they are not presented as a second verbatim HostGator transcript.

Approximately 5:00–5:30 PM — The supposedly simple correction

Darren: The objective was to move the domains away from HostGator, not repair HostGator hosting. The two new server addresses had already been supplied.

Codex: The technical distinction was narrowed repeatedly: this was not a website-content edit, cPanel A-record exercise, or shared-hosting nameserver setup. It was a registrar-side child/glue-record correction.

Required values: ns1 → 67.222.17.89 and ns2 → 67.222.17.90.

Authentication loop — the outage blocks its own repair

Email service was already unreliable, yet account verification repeatedly depended on email. Multiple codes surfaced from different accounts, expired, or arrived late. The support record was asked to preserve the authenticated context rather than restart the customer at another desk.

Working diagnosis: The domain/email outage prevented reliable authentication to repair the domain/email outage. HostGator’s reseller backend therefore had to own the escalation.

The registrar identity problem

Public registry data named Network Solutions as registrar of record. HostGator support alternated between directing the customer elsewhere and stating that HostGator was the registration service provider through which changes must be made.

A telephone escalation to Network Solutions then confirmed that the customer relationship and account servicing were held by HostGator. The apparent contradiction was resolved as a registrar/reseller arrangement—not as a usable alternative login path.

The chatbot question

The support exchange repeatedly returned generic hosting guidance after receiving precise registrar instructions. Darren and Codex could not independently prove whether a particular name represented a human, automation, or a human working through scripts. The record therefore focuses on observable behavior: repeated context loss, canned responses, incomplete execution, and escalation requests that did not produce a clearly identifiable domains technician.

The question that would not stay answered

The session repeatedly asked for a direct confirmation: had the actual registrar host objects been submitted with the two requested external IP addresses? Replies frequently described A records, propagation, or shared-hosting limitations instead.

Darren’s operational translation: stop repairing the former host; HostGator is fired; complete the exit.

Codex’s formal translation: preserve the existing delegation, change only the two registrar child/glue IPs, provide submission confirmation, and do not redirect the case into another hosting workflow.

Post-chat telephone escalation

Darren later reached a telephone representative who apparently had authority to submit the changes. Only after an extended attempt to discuss repairs inside HostGator did the objective become unmistakable: the customer was ending HostGator hosting and required the DNS host-object change immediately. The representative requested the addresses again and stated that the change had been submitted.

Important limitation: the telephone call was not recorded. This paragraph preserves Darren’s contemporaneous account, not a verbatim call transcript.

Independent verification after the call

• KnownHost VPS confirmed online with both 67.222.17.89 and 67.222.17.90.
• Sparkles became publicly reachable on the new server.
• AnyKey and its mail route continued to resolve to the former 129.121.127.64 address at the time this record closed.
• Direct authoritative queries still returned the old AnyKey data, so the result remained inside the provider’s stated propagation window and required later re-verification.

Closing status on August 28

The websites and databases were installed on KnownHost, rollback copies were preserved, and the new server’s AnyKey DNS zone contained the intended web and mail destinations. The unresolved external dependency was registrar/delegation propagation.

Outcome at the August 28 close: server-side migration complete; Sparkles publicly cut over; AnyKey public DNS and mail cutover still pending independent confirmation. This dated status was superseded by the September 10 resolution below.