Problems for .SC Domain Owners

[mbailey]

About a week after i bought 2 .sc domains from idotz.net for $50 each, i realized that both domains weren't being resolved sparadically throughout various parts of the internet.

So, i started investigating the issue, with the initial impression that this problem was stemming from my own dns servers.

Well, after about a half hour of checking things on my own server, i came to the conclusion that nothign was wrong there.

So, then i started looking into outside issues that may be causing the problem, and when i found the actual problem i was pretty shocked.

Here's how it breaks down


The .SC ccTLD has 3 nameservers listed in it's IANA records:

• tld1.ultradns.net
• tld2.ultradns.net
• ns1.nic.sc

But, if we run the same query at each of those nameservers, they each list only those of ultradns.net, with absolutely no mention of ns1.nic.sc .

So, i did some more digging, and i found that ns1.nic.sc returns an NXDOMAIN error on both of my .sc domains (webhost.sc and irc.sc), and the .sc domain of my friend (geeks.sc). But, those 2 ultradns.net dns servers report just fine.

Aparently, ns1.nic.sc should have been removed from the IANA records, but somewhere along the line someone forgot to remove it from the IANA records.

So now, us .sc domain owners are facing a particularly major problem. Any time a user tries to access one of our domains, there is a 1 in 3 chance that the domain will be reported as non-existant, and they won't be able to access the website.

On January 30th i filed a support ticket with the people i registered my .sc domains with - idotz.net asking what is going to be done.

On february 1st, they replied back saying that they forwarded the ticket to Afilias - the .SC and .INFO Registry.

Later that day, they replied back saying that Afilias and ultradns are looking into the issue. .

On February 2nd, i replied back saying that i'll be waiting for a response, and also inquiring if anything may be done to reimburse us customers who have been affected by this issue.

On February 5th, there still hadn't been a response, and i asked if there was an update on this issue.


There hasn't been a response from idotz.net to this day.

Tonight, ns1.nic.sc is still responding with NXDOMAIN on each of those .sc domains i have been registered with idotz.net.

 

[MissFlora]

I have some .sc with idotz.net too. Do update us with what is to be done about the problem, thanks.

Flora.

 

[mole]

Good grief!

They don't call them idotz for nothing.

 

[-db-]

...there is a 1 in 3 chance that the domain will be reported as non-existant, and they won't be able to access the website.

Hmmm...

But if that were the case, we should see a lot of people having trouble reaching whois.sc considering the popularity of the site, right?

 

[mbailey]

But if that were the case, we should see a lot of people having trouble reaching whois.sc considering the popularity of the site, right?

I don't know why, but that domain resolves fine at ns1.nic.sc .

-bash-2.05b$ dig whois.sc @ns1.nic.sc

; <<>> DiG 9.2.4rc6 <<>> whois.sc @ns1.nic.sc
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17890
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;whois.sc.                      IN      A

;; ANSWER SECTION:
whois.sc.               300     IN      CNAME   web.nameintel.com.
web.nameintel.com.      265     IN      A       64.246.161.26

;; AUTHORITY SECTION:
nameintel.com.          84690   IN      NS      ns1.dnscloud.com.
nameintel.com.          84690   IN      NS      ns2.dnscloud.com.

;; ADDITIONAL SECTION:
ns1.dnscloud.com.       170978  IN      A       69.28.247.250
ns2.dnscloud.com.       170978  IN      A       64.246.165.245

;; Query time: 1541 msec
;; SERVER: 202.72.100.47#53(ns1.nic.sc)
;; WHEN: Wed Feb  9 23:16:10 2005
;; MSG SIZE  rcvd: 158

Maybe this issue is just facing people who have registered .sc domains before ns1.nic.sc quit functioning.

 

[-db-]

Indeed.

An interesting dilemma....

One that needs attention immediately.

 

[equity78]

Does this matter if you have changed nameservers to like a parking page like SEDO? this is not an area I understand so I appreciate the info. Thank you

 

[mbailey]

Does this matter if you have changed nameservers to like a parking page like SEDO? this is not an area I understand so I appreciate the info. Thank you

well it's like this.

When a domain is queried, it will first query the root servers - regardless of how your dns is configured

From the root servers, it will see what nameservers are used for the .sc ccTLD, that will return tld1.ultradns.net tld2.ultradns.net and ns1.nic.sc, regardless of how you configure your dns.

But, the kicker is that it picks the dns server it will use randomly. tld1.ultradns.net tld2.ultradns.net will return a dns result directing the user to your specified dns servers. ns1.nic.sc will return an NXDOMAIN (non-existant domain) error, and the client won't be able to access the website.



The best thing to do here is post your .sc domain, and i'll check to see if it works at ns1.nic.sc.

So far, the following domains that i know of are failing at ns1.nic.sc

webhost.sc
irc.sc
geeks.sc

 

[equity78]

Hey DUDE thanks a lot for making that simple for a non techie like myself to understand.
Rep upgraded Thank you

I own hhh.sc,h2o.sc,777.sc

 

[mbailey]

Hey DUDE thanks a lot for making that simple for a non techie like myself to understand.
Rep upgraded Thank you

I own hhh.sc,h2o.sc,777.sc

You're welcome.

Each of those domains report as non-existant at ns1.nic.sc, reporting just fine at the 2 ultradns.net nameservers.

By the way, for those of you who have access to a linux or freebsd machine.. any machine with the dig application installed on it. You can go through the following steps to check if your domain resolves from ns1.nic.sc


open a terminal or ssh to the machine that has dig installed (most linux machines do)
type the following command

dig domain.sc @ns1.nic.sc

if your domain doesn't resolve, you'll see something like this near the top of the output:

; <<>> DiG 9.2.4rc6 <<>> whateverdomain.sc @ns1.nic.sc
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7843
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

one thing you should pay attention to is this line:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7843

specifically the

status: NXDOMAIN,

output.

You can also change the nameserver you are querying by editing the portion of the command that appears after @. Like..

dig domain.sc @tld1.ultradns.net .

I think i'll write a script in the next few minutes to allow users to check.

 

[Acroplex]

Hmmm...

But if that were the case, we should see a lot of people having trouble reaching whois.sc considering the popularity of the site, right?

And yes, I get that DNS error often.

 

[-db-]

Really? Damn.

Well, I've encountered a normal amount of site errors etc., but I never really noticed anything specifically about the DNS issue, or anything that happened very often. Keep in mind though, I may not use their site as much as you, or others. So, I might not have the sheer volume of visits to establish such a noticeable problem.

Definitely needs to be taken care of.

 

[suthra]

Thankx for that info.,
Can u pls check
www.whoi.sc ?

Thanks again

s.s

 

[mbailey]

Thankx for that info.,
Can u pls check
www.whoi.sc ?

NXDOMAIN at ns1.nic.sc, just fine at ultradns.net servers.

 

[mbailey]

More developments.

I recieved response from idotz.net Today at 11:58PM saying that this issue was cleared up long ago. With a dig result showing only tld1.ultradns.net and tld2.ultradns.net. So, i ran the query myself, and saw the same results:

; <<>> DiG 9.2.4rc6 <<>> sc. ANY
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37291
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sc. IN ANY

;; ANSWER SECTION:
sc. 86400 IN SOA NS01.AFILIAS.INFO. DOMAINTECH.AFILIAS.INFO. 2005021201 1800 900 604800 86400
sc. 86400 IN NS TLD1.ULTRADNS.NET.
sc. 86400 IN NS TLD2.ULTRADNS.NET.

;; AUTHORITY SECTION:
sc. 86400 IN NS TLD1.ULTRADNS.NET.
sc. 86400 IN NS TLD2.ULTRADNS.NET.

;; ADDITIONAL SECTION:
TLD1.ULTRADNS.NET. 88008 IN A 204.74.112.1
TLD2.ULTRADNS.NET. 88008 IN A 204.74.113.1

;; Query time: 35 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 12 03:03:15 2005
;; MSG SIZE rcvd: 194

but, if i run dig on my own domain - irc.sc..

-jailshell-2.05b$ dig irc.sc ANY +trace

; <<>> DiG 9.2.4rc6 <<>> irc.sc ANY +trace
;; global options: printcmd
. 473517 IN NS B.ROOT-SERVERS.NET.
. 473517 IN NS C.ROOT-SERVERS.NET.
. 473517 IN NS D.ROOT-SERVERS.NET.
. 473517 IN NS E.ROOT-SERVERS.NET.
. 473517 IN NS F.ROOT-SERVERS.NET.
. 473517 IN NS G.ROOT-SERVERS.NET.
. 473517 IN NS H.ROOT-SERVERS.NET.
. 473517 IN NS I.ROOT-SERVERS.NET.
. 473517 IN NS J.ROOT-SERVERS.NET.
. 473517 IN NS K.ROOT-SERVERS.NET.
. 473517 IN NS L.ROOT-SERVERS.NET.
. 473517 IN NS M.ROOT-SERVERS.NET.
. 473517 IN NS A.ROOT-SERVERS.NET.
;; Received 276 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

sc. 172800 IN NS TLD1.ULTRADNS.NET.
sc. 172800 IN NS TLD2.ULTRADNS.NET.
sc. 172800 IN NS NS1.NIC.sc.
;; Received 144 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 58 ms

irc.sc. 86400 IN NS ns2.sedoparking.com.
irc.sc. 86400 IN NS ns1.sedoparking.com.
;; Received 75 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 31 ms

it still lists ns1.nic.sc .

 

[KwelX]

plz understand this isn't as serious as a dilema as mbailey is making it sound, although it does need to be fixed. what he is leaving out is that the ROOT servers are not queryed for each DNS request.

simply put the chances of returning an NXDOMAIN response are far las than 1 in 3.

it's far more complicated than that but i'll leave it there.

please keep us updated as to the responses from nic.sc as idotz has nothing to do with this issue. they may help apply pressure for nic.sc to fix it that's all.
or contact the .sc admin contact ->http://www.iana.org/root-whois/sc.htm directly

 

[mbailey]

plz understand this isn't as serious as a dilema as mbailey is making it sound, although it does need to be fixed. what he is leaving out is that the ROOT servers are not queryed for each DNS request.

Roto Servers aren't queried in EVERY request, but on every INITIAL request, where a cache hasn't been read.

simply put the chances of returning an NXDOMAIN response are far las than 1 in 3.

If that's the case, then why can't the w3c's own validator resolve this domain: http://validator.w3.org/check?uri=http://geeks.sc

it's far more complicated than that but i'll leave it there.

If you're going to go out on a limb and claim that i am wrong, i'd like to see some proof.

please keep us updated as to the responses from nic.sc as idotz has nothing to do with this issue. they may help apply pressure for nic.sc to fix it that's all.

I think idotz should have at least warned people who were interested in buying .sc names about this issue.

 

[KwelX]

So now, us .sc domain owners are facing a particularly major problem. Any time a user tries to access one of our domains, there is a 1 in 3 chance that the domain will be reported as non-existant, and they won't be able to access the website.

Again, simply untrue. You explained half of this in your next statement. ->INITIAL request, where a cache hasn't been read - Caching - Once the Correct response is cached it will resolve when the USERS DNS server is queryed.

If that's the case, then why can't the w3c's own validator resolve this domain: http://validator.w3.org/check?uri=http://geeks.sc

LOL..Are you kidding? type in http://validator.w3.org/check?uri=http://www.geeks.sc It resolves fine.

If you're going to go out on a limb and claim that i am wrong, i'd like to see some proof.

Proove that DNS is more complicated? http://www.dns.net/dnsrd/rfc/

To put it very simple to you. Since u only read in w3c. Make the w3c www.geeks.sc request then see what you get for the geeks.sc response. Still think it's a 1 in 3 chance? Or do you want me to start quoting RFC's for you that are WAY over your head.

I think idotz should have at least warned people who were interested in buying .sc names about this issue.

Idotz and other Registrars don't exist to police ccTLDs and TLDs. They are in the business to Sell names. Contact IANA or the .SC admin.

Proof. The same can be done @ w3c. Still want to say it's 1 in 3?


; <<>> DiG 2.1 <<>> @dns1.menandmice.is geeks.sc ANY
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0
;; QUESTIONS:
;; geeks.sc, type = ANY, class = IN

;; AUTHORITY RECORDS:
sc. 300 SOA NS01.AFILIAS.INFO. DOMAINTECH.AFILIAS.INFO. (
1101767930 serial
1800 refresh (30 mins)
900 retry (15 mins)
604800 expire (7 days)
86400 ) minimum (1 day)

;; Total query time: 768 msec
;; FROM: us.mirror.menandmice.com to SERVER: default -- 0.0.0.0
;; WHEN: Sat Feb 12 13:10:42 2005
;; MSG SIZE sent: 26 rcvd: 90
============================================

; <<>> DiG 2.1 <<>> @dns1.menandmice.is www.geeks.sc ANY
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 1, Auth: 2, Addit: 2
;; QUESTIONS:
;; www.geeks.sc, type = ANY, class = IN

;; ANSWERS:
www.geeks.sc. 86400 CNAME geeks.sc.

;; AUTHORITY RECORDS:
geeks.sc. 86400 NS ns1.emegaweb.net.
geeks.sc. 86400 NS ns2.emegaweb.net.

;; ADDITIONAL RECORDS:
ns1.emegaweb.net. 172800 A 69.93.152.251
ns2.emegaweb.net. 172800 A 69.93.152.252

;; Total query time: 164 msec
;; FROM: us.mirror.menandmice.com to SERVER: default -- 0.0.0.0
;; WHEN: Sat Feb 12 13:10:58 2005
;; MSG SIZE sent: 30 rcvd: 124

============================================


; <<>> DiG 2.1 <<>> @dns1.menandmice.is geeks.sc ANY
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 2, Addit: 2
;; QUESTIONS:
;; geeks.sc, type = ANY, class = IN

;; ANSWERS:
geeks.sc. 86378 NS ns2.emegaweb.net.
geeks.sc. 86378 NS ns1.emegaweb.net.

;; AUTHORITY RECORDS:
geeks.sc. 86378 NS ns1.emegaweb.net.
geeks.sc. 86378 NS ns2.emegaweb.net.

;; ADDITIONAL RECORDS:
ns1.emegaweb.net. 172778 A 69.93.152.251
ns2.emegaweb.net. 172778 A 69.93.152.252

;; Total query time: 0 msec
;; FROM: us.mirror.menandmice.com to SERVER: default -- 0.0.0.0
;; WHEN: Sat Feb 12 13:11:20 2005
;; MSG SIZE sent: 26 rcvd: 134

 

[mbailey]

Again, simply untrue. You explained half of this in your next statement. ->INITIAL request, where a cache hasn't been read - Caching - Once the Correct response is cached it will resolve when the USERS DNS server is queryed.

If anything, a cached result is going to cause even more problems, because a problem arises that a result that says the domain is non-existant will be cached.

Proove that DNS is more complicated? http://www.dns.net/dnsrd/rfc/

To put it very simple to you. Since u only read in w3c. Make the w3c www.geeks.sc request then see what you get for the geeks.sc response. Still think it's a 1 in 3 chance? Or do you want me to start quoting RFC's for you that are WAY over your head.

A result is still cached that says the domain is non-existant.

Idotz and other Registrars don't exist to police ccTLDs and TLDs. They are in the business to Sell names. Contact IANA or the .SC admin.

How are people supposed to know that the tld isn't functioning well when there is a scare number of .sc domains out there, right now? If these people are selling .sc domains, it is their duty to warn potential customers of problems, even if they aren't an authority on the issue.


By the way..

-bash-2.05b$ dig www.geeks.sc +trace

; <<>> DiG 9.2.4rc6 <<>> www.geeks.sc +trace
;; global options:  printcmd
.                       358038  IN      NS      J.ROOT-SERVERS.NET.
.                       358038  IN      NS      K.ROOT-SERVERS.NET.
.                       358038  IN      NS      L.ROOT-SERVERS.NET.
.                       358038  IN      NS      M.ROOT-SERVERS.NET.
.                       358038  IN      NS      A.ROOT-SERVERS.NET.
.                       358038  IN      NS      B.ROOT-SERVERS.NET.
.                       358038  IN      NS      C.ROOT-SERVERS.NET.
.                       358038  IN      NS      D.ROOT-SERVERS.NET.
.                       358038  IN      NS      E.ROOT-SERVERS.NET.
.                       358038  IN      NS      F.ROOT-SERVERS.NET.
.                       358038  IN      NS      G.ROOT-SERVERS.NET.
.                       358038  IN      NS      H.ROOT-SERVERS.NET.
.                       358038  IN      NS      I.ROOT-SERVERS.NET.
;; Received 292 bytes from 64.5.44.113#53(64.5.44.113) in 63 ms

sc.                     172800  IN      NS      TLD1.ULTRADNS.NET.
sc.                     172800  IN      NS      TLD2.ULTRADNS.NET.
[size=55]sc.                     172800  IN      NS      NS1.NIC.sc.[/size]
;; Received 150 bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 158 ms

geeks.sc.               86400   IN      NS      ns2.emegaweb.net.
geeks.sc.               86400   IN      NS      ns1.emegaweb.net.
;; Received 78 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 18 ms

www.geeks.sc.           86400   IN      CNAME   geeks.sc.
geeks.sc.               86400   IN      A       69.93.152.250
geeks.sc.               86400   IN      NS      ns2.emegaweb.net.
geeks.sc.               86400   IN      NS      ns1.emegaweb.net.
;; Received 140 bytes from 69.93.152.252#53(ns2.emegaweb.net) in 61 ms

 

[KwelX]

A result is still cached that says the domain is non-existant.

Clear your BROWSER cache. http://validator.w3.org/check?uri=http://geeks.sc responds everytime with the correct response after the www.geeks.sc request is made.


-bash-2.05b$ dig www.geeks.sc +trace

Glad to know your not actually a SysAdmin with their own nameserver. Try using a real Server to get your DIG responses. Here are some free public tools, http://www.kloth.net/services/dig.php or http://network-tools.com/default.asp?

How are people supposed to know that the tld isn't functioning well when there is a scare number of .sc domains out there, right now? If these people are selling .sc domains, it is their duty to warn potential customers of problems, even if they aren't an authority on the issue.

The ccTLD isn't functioning? Really? Idotz has a duty to sell domains.

As an owner of a few .sc domains and an experienced admin this is a non-issue to me. Thanks for your concern and Thread mbailey however you may want to do more research before claiming that an entire domain extension isn't functing or that traffic to .sc domains is limited to 1 in 3 requests - Any time a user tries to access one of our domains, there is a 1 in 3 chance that the domain will be reported as non-existant, and they won't be able to access the website.