site problem

[genwork]

udomz.com is having issues again. It was working fine before.

 

but I can still access iden3.genrwork.com through the proxy

[wolstech]

Try clearing your browser cache.

If that does not resolve it, it's probably an issue upstream somewhere, likely either a stale cache at your ISP or a DNS configuration issue. Since you do not use our DNS, and you have genrwork's DNS hidden behind Cloudflare, we are unable to troubleshoot this further. If you would like us to troubleshoot this, please turn off the Cloudflare Proxy and any associated gateways/security pages like Cloudflare Turnstile on genrwork.com.

As for the domain udomz.com showing that domain setup page, it's because it is currently disabled due to not being pointed to our servers. Domains with DNS records that do not point to our IP addresses are automatically disabled to reduce server load.

[genwork]

It doesn't seem to be a browser issue, especially since the [genrwork] domain points to Heliohost's IP address, not Cloudflare's. And what I'm taking issue with is the domain [udomz.com], not [genrwork.com]

Edited yesterday at 02:14 PM by genwork
provide more clarity on the issue

[wolstech]

The udomz.com domain is not hosted with us at the moment. It is attached to your account but is disabled because it has DNS records that do not point to us. We see the below DNS records for udomz.com, which are incorrect. Either the NS records need to be changed to ns1.heliohost.org and ns2.heliohost.org, or the A record needs to be changed to the same .90 IP as the genrwork.helioho.st domain.

If you change the DNS to point to us, you will also need to go into the domain in Plesk, set its status to Active, and wait up to 2 hours for it to become functional.

If you do not want the udomz.com domain to be hosted here (or it's not your domain and was inadvertently added), let us know and we can remove it from your account instead.

Incorrect A record for udomz:

host: udomz.com
class: IN
ttl: 60
type: A
ip: 151.101.41.242

Third party NS records:

host: udomz.com
class: IN
ttl: 78276
type: NS
target: ns1.vercel-dns.com
host: udomz.com
class: IN
ttl: 78276
type: NS
target: ns2.vercel-dns.com

 

[genwork]

  

58 minutes ago, wolstech said:

you will also need to go into the domain in Plesk, set its status to Active, and wait up to 2 hours for it

maybe because of this. i will try it

Edited 23 hours ago by genwork
aware of a suggestion

[wolstech]

If you enable the domain but don’t change the DNS, be aware that the server will eventually disable it again, typically within 7 days.

Domains must return either one of our IPs as the A (or MX, if it’s mail-only) record, or have Cloudflare as name servers (using CF triggers our system to handle domains differently because of the proxy/security features), to avoid being disabled.

[genwork]

7 hours ago, wolstech said:

be aware that the server will eventually disable it again

But [iden3.genrwork.com] uses Cloudflare (both NS and A records) and was still working fine while [udomz.com] was having issues at the time

[wolstech]

Domains that use CF are explicitly excluded from the DNS checking because it would be impossible for the Cloudflare security features to work otherwise. It's the only provider that has such an exception. CF domains used to be validated using a file-based method that doesn't involve DNS, i'm not sure if this is still performed or not.

[genwork]

Does the CF refer to a DNS record or a request header? 

[wolstech]

CF is just short for Cloudflare and the system is looking for their name servers specifically. If a domain's name servers end in .ns.cloudflare.com the system ignores the domain's IP addresses entirely.

I think these domains used to be verified via file, but I'm not even sure we actually still do this because certain features like Turnstile would be incompatible with it (Krydos would be the admin who would know if we still validate CF domains). I know Lets Encrypt sometimes has issues renewing certs on domains that use Cloudflare for this reason. When people have issues renewing certificates, the first response we always give is "temporarily turn off Cloudflare's proxy and security options and try again" and it always fixes it.