Wit's end with registering domains: can't reach them

[hbbtstar]

Thanks for the spot! I will look into it, I didn't even think about that.

Beyond that, however, something odd that I'm wondering is why ping isn't working. Why would Apache's configuration matter for pinging purposes? In all of the things I've tried, I've never once been able to get a successful ping response- or even have ping acknowledge that any DNS entry exists at all for the specified domain name. It's very strange, and I'm having trouble wrapping my head around it (obviously, hah).

Also, something else that I've noticed that I should share: I'm unable to resolve any of the domains registered after ghostwriterintl.bit in the blockchain using the dot-bit nameserver or my own namecointobind nameserver. They all come back with no A records registered using nslookup and I can't ping any of them. Older domains like bitse.bit and dot-bit.bit, however, resolve just fine. Could this be related to what I'm experiencing?

[biolizard89]

I just registered some domains with similar syntax to test; once they get into the blockchain I'll report back on whether this is a bug.

[hbbtstar]

biolizard, any updates on this? Still no luck on my end.

[biolizard89]

biolizard, any updates on this? Still no luck on my end.

Sorry for the delay, I got distracted -- thanks for reminding me. So I can confirm that with nmcontrol's RPC interface, domains that use "alias" or "translate" don't resolve to an IP address. I think this is a bug with nmcontrol. I don't have a namecointobind installation to test with, but you can try the following domains and see if they give you an IP (they should resolve to Google's IP, although I wouldn't expect Google's server to reply with a valid web page):

temp-alias.bit
temp-translate.bit
temp-alias-translate.bit

You can also try adding a www. to the beginning to see if that makes a difference.

FWIW, I have a domain which was renewed a few days ago (although it was registered years ago), and it does give me a valid IP with nmcontrol. You can try resolving it if you want to test: vl.bit (it should resolve to 10.0.0.1 at the moment, so it won't load a web page).

Let me know what your testing yields.

[hbbtstar]

nmcontrol also resolves vl to 10.0.0.1 for me- but it resolves other ones that don't work in DNS, as well. To give an example, here's what shows up for me using either my own DNS server with namecointobind implemented or using khal's DNS server fails to resolve that. Here's the dig output:

Code: Select all

; <<>> DiG 9.9.2-P1 <<>> @178.32.31.41 vl.bit
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9429
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;vl.bit.                                IN      A

;; AUTHORITY SECTION:
bit.                    3600    IN      SOA     ns.dot-bit.bit. hostmaster.ns.dot-bit.bit. 79372503 21600 3600 604800 3600

;; Query time: 109 msec
;; SERVER: 178.32.31.41#53(178.32.31.41)
;; WHEN: Thu Nov 21 20:30:28 2013
;; MSG SIZE  rcvd: 93

You'll notice there's no answer section for vl.bit. Here's the same command with bitse.bit:

Code: Select all

; <<>> DiG 9.9.2-P1 <<>> @178.32.31.41 bitse.bit
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56489
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 12

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bitse.bit.                     IN      A

;; ANSWER SECTION:
bitse.bit.              86400   IN      A       96.35.127.219

;; AUTHORITY SECTION:
bit.                    86400   IN      NS      ns2.opennic.glue.
bit.                    86400   IN      NS      ns.dot-bit.bit.
bit.                    86400   IN      NS      ns8.opennic.glue.
bit.                    86400   IN      NS      ns6.opennic.glue.
bit.                    86400   IN      NS      ns5.opennic.glue.
bit.                    86400   IN      NS      ns4.opennic.glue.
bit.                    86400   IN      NS      ns7.opennic.glue.

;; ADDITIONAL SECTION:
ns2.opennic.glue.       7566    IN      A       216.87.84.210
ns2.opennic.glue.       7566    IN      AAAA    2001:470:8388:10:0:100:53:10
ns4.opennic.glue.       4236    IN      A       178.63.145.230
ns4.opennic.glue.       4236    IN      AAAA    2a01:4f8:101:3062::5:2
ns5.opennic.glue.       8683    IN      A       173.208.225.19
ns6.opennic.glue.       4236    IN      A       207.192.71.13
ns6.opennic.glue.       4236    IN      AAAA    2002:cfc0:470d::1
ns7.opennic.glue.       5074    IN      A       199.231.210.120
ns7.opennic.glue.       5074    IN      AAAA    2001:470:1f10:c6::11
ns8.opennic.glue.       4236    IN      A       178.63.116.152
ns8.opennic.glue.       4237    IN      AAAA    2a01:4f8:141:4281::999

;; Query time: 109 msec
;; SERVER: 178.32.31.41#53(178.32.31.41)
;; WHEN: Thu Nov 21 20:31:20 2013
;; MSG SIZE  rcvd: 435

plenty of A record for bitse. None for vl. nmcontrol shows the right output though:

Code: Select all

{"name": "d/vl", "expires_in": 34710, "expires_at": 1385055469, "txid": "ecf88bbed29647a1fcbfebf8b3a31a24af87e44ac04a6f7b41aac2bf87b8eb1f", "value": "{\"map\": {\"\": \"10.0.0.1\"}}", "address": "NFSq6vHTYCPvhsHCCJHFjgHvfbKB9XsEJg"}

And here it is for bitse:

Code: Select all

{"name": "d/bitse", "expires_in": 8792, "expires_at": 1385055594, "txid": "04cb7969fc6aa60db1b7315fa5b337dbef81eb714fa06be8c4e8aad98c4ea35d", "value": "{\"info\":{\"description\":\"bitSE .bit Search Engine\",\"registrar\":\"uberbills.com\",\"email\":\"webmaster@uberbills.com\"},\"map\": {\"\": \"96.35.127.219\"}} ", "address": "N3fVA7M6g1nfKz6PWUT7jtXhWazMSyqznk"}

[biolizard89]

Well, if nmcontrol works, I guess this is a bug in namecointobind. I'm not familiar with its codebase, so I probably wouldn't be able to help with fixing it... but feel free to post in the namecointobind thread and see if someone can figure out what's going on.