From best I can tell, .us domain names are not exhibiting this. It is only .us.com domain name.
Unfortunately, I couldn't wait for this to get resolved, I used the WHM to park the domain name. (This was actually for an addon domain - but it was failing at the parking of the subdomain). So I don't really have an example to show you.
The best way I can tell you to duplicate this issue:
1) Register a .us.com domain name.
2) Set the nameservers for that .us.com domain name to your server's nameservers
3) Don't create an account, addon, domain alias, or anything that would create a DNS zone file for that domain name on your server's nameservers.
Another words, the .us.com domain name should be setup and ready to be added as an addon domain
Now - I tend to do a lot of dig +trace to follow the resolution path that a domain name takes.
If you do a dig +trace example.us.com of the example domain name that you registered, it will probably show something like:
$ dig +trace example.us.com
; <<>> DiG 9.16.1-Ubuntu <<>> +trace example.us.com +nodnssec
;; global options: +cmd
. 1635 IN NS m.root-servers.net.
. 1635 IN NS l.root-servers.net.
. 1635 IN NS k.root-servers.net.
. 1635 IN NS j.root-servers.net.
. 1635 IN NS i.root-servers.net.
. 1635 IN NS h.root-servers.net.
. 1635 IN NS g.root-servers.net.
. 1635 IN NS f.root-servers.net.
. 1635 IN NS e.root-servers.net.
. 1635 IN NS d.root-servers.net.
. 1635 IN NS c.root-servers.net.
. 1635 IN NS b.root-servers.net.
. 1635 IN NS a.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 881 bytes from 192.36.148.17#53(i.root-servers.net) in 59 ms
us.com. 172800 IN NS ns1.centralnic.net.
us.com. 172800 IN NS ns2.centralnic.net.
us.com. 172800 IN NS ns3.centralnic.net.
us.com. 172800 IN NS ns4.centralnic.net.
;; Received 140 bytes from 192.43.172.30#53(i.gtld-servers.net) in 63 ms
example.us.com. 3600 IN NS ns1.yournameserver.com.
example.us.com. 3600 IN NS ns2.yournameserver.com.
;; Received 102 bytes from 185.24.64.10#53(ns2.centralnic.net) in 43 ms
This would correctly show that example.us.com is set to use ns1.yournameserver.com and ns2.yournameserver.com
Now, doing some digging through the cPanel system - I created a script that uses cPanel's logic to determine what nameservers a domain name is using:
#!/usr/local/cpanel/3rdparty/bin/perl
$domain=$ARGV[0];
require Cpanel::DnsRoots;
my ( $result, undef, $names ) = Cpanel::DnsRoots::fetchnameservers($domain);
if ($result) {
my %NAMES = %$names;
my @nameservers = sort keys %NAMES;
foreach my $n (@nameservers) {
print($n . "\n");
}
}
Now when you run this script:
./run.pl example.us.com
It's going to come back with:
ns1.centralnic.net
ns2.centralnic.net
ns3.centralnic.net
ns4.centralnic.net
which is not correct.
It's possible that this script doesn't correctly use cPanel's logic - the creators of cPanel would be better able to determine this.
This can also be verified by trying to create an addon domain using example.us.com - it will get kicked out saying that the domain name is not using nameservers registered to this server.
The IPs that ns1.yournameserver.com and ns2.yournameserver.com resolve to are present in /etc/ips.remotedns
You can further verify this by adding one of the IPs of the centralnic.net nameservers to /etc/ips.remotedns (i.e. 185.24.64.10) and then try to create an addon domain and this will be successful.
Once the domain name is setup with a zone file on the nameservers, this perl script no longer shows this output. (Although, this script appears to be showing the NS records of the DNS Zone file and not necessarily the parent nameservers of the DNS zone - which I'm not sure is correct).
At least this is the behavior that I am seeing. I don't have a ton of .us.com to play with (in fact this is the first and only .us.com domain name I've had to deal with). My best guess is that cPanel is having a hard time acknowledging that .us.com as a TLD (or pseudo-TLD), but again that's a determination better suited for cPanel developers.
I don't know exactly what all is behind cPanel's fetchnameservers() function. For me, programmatically, I've always looped through the lines from dig +trace, the first section that begins with ^example.us.com would contain the lines of the nameservers that the domain name is using. That may not be the most eloquent solution... but it works.
