bind9 configuration for sharing a zone with ICANN TLD

[micah]

I've got a domain name that is currently registered with an ICANN-cabal approved registrar, that I am acting as the primary and secondary nameserver for. I registered the same name in the namecoin universe and I configured the .bit nameservers to point to my already existing nameservers so I could just serve up the same zone information for the .bit domain as I am with the original ICANN domain.

However, this didn't work out of the box, because my nameservers did not know about the .bit zone and needed to be configured to recognize and respond to it. This is how I did this.

First you need to update your namecoin name to map the nameservers to your nameservers. Lets say my original domain name was "foo.net" and I registered "foo.bit"

Code: Select all

../namecoind name_update d/foo '{"map":{"":{"ns":["YOUR.NAME.SERVER1","YOUR.NAMESERVER2"]}}}'

Then you must configure your bind's named.conf (or named.conf.local if you are using Debian or a Debian derived distro) to recognize the domain:

Code: Select all

zone "foo.bit" in {
  type master;
  file "/etc/bind/primary/db.foo";
};

You should point the file directive to the zone file that "yourname.net" also points to.

Then you need to make sure that "db.yourname" is using RFC 1035 global SOA directive synthesis. In otherwords, if your SOA record says:

Code: Select all

"foo.net   IN   SOA ...." 

then you want to change it to:

Code: Select all

"@    IN   SOA ..."

(dont forget to bump the serial number, and restart bind!)

The @ will be substituted with an $ORIGIN synthesis based on the value of the zone name in the named.conf file.

Now foo.net subdomains and records will be resolved as they always were, and foo.bit will do the exact same thing. No need to manage two different files with the exact same content!

[CoinMan]

Cool, thanks for this Micah!

I've got a domain name that is currently registered with an ICANN-cabal approved registrar, that I am acting as the primary and secondary nameserver for. I registered the same name in the namecoin universe and I configured the .bit nameservers to point to my already existing nameservers so I could just serve up the same zone information for the .bit domain as I am with the original ICANN domain.

However, this didn't work out of the box, because my nameservers did not know about the .bit zone and needed to be configured to recognize and respond to it. This is how I did this.

First you need to update your namecoin name to map the nameservers to your nameservers. Lets say my original domain name was "foo.net" and I registered "foo.bit"

Code: Select all

../namecoind name_update d/foo '{"map":{"":{"ns":["YOUR.NAME.SERVER1","YOUR.NAMESERVER2"]}}}'

Then you must configure your bind's named.conf (or named.conf.local if you are using Debian or a Debian derived distro) to recognize the domain:

Code: Select all

zone "foo.bit" in {
  type master;
  file "/etc/bind/primary/db.foo";
};

You should point the file directive to the zone file that "yourname.net" also points to.

Then you need to make sure that "db.yourname" is using RFC 1035 global SOA directive synthesis. In otherwords, if your SOA record says:

Code: Select all

"foo.net   IN   SOA ...." 

then you want to change it to:

Code: Select all

"@    IN   SOA ..."

(dont forget to bump the serial number, and restart bind!)

The @ will be substituted with an $ORIGIN synthesis based on the value of the zone name in the named.conf file.

Now foo.net subdomains and records will be resolved as they always were, and foo.bit will do the exact same thing. No need to manage two different files with the exact same content!

[watchpocket]

I've got a domain name that is currently registered with an ICANN-cabal approved registrar, that I am acting as the primary and secondary nameserver for. I registered the same name in the namecoin universe and I configured the .bit nameservers to point to my already existing nameservers so I could just serve up the same zone information for the .bit domain as I am with the original ICANN domain.

I have a similar situation and did the same thing. The difference is that I myself do not run the nameservers. They're run on an ISP where I have a shell account and a basic web-hosting service that comes with the shell account.

I'm guessing that there's no way to get those nameservers (which I obviously have no direct access to) to be aware of the .bit zone short of persuading the admins at the ISP to make changes similar to what you've done to bind's named.conf.

But I'm curious to know if anyone thinks there is some other way to do this, or any other way to get my .bit name to point to my already established .net name. [Edit: NOT to the .net name, but to the .net SITE.] It's unlikely that my ISP would be willing to make the necessary changes.

(Using an "HTTP 301 redirect" from a .bit to a .net would, if I'm not mistaken, display the destination URL -- the dot-net -- in the location bar. That's not what I want.)

One other question: let's say I either get my ISP to make the necessary changes, or find a way to do this myself. Will a potential censor be able to interfere with such a setup (pointing a .bit to a .net) if it doesn't know where the .net is hosted?

Thoughts appreciated.

[doublec]

I'm curious why you'd want to point your namecoin domain name to the existing DNS? Why not code the IP address into the namecoin domain value? This way you're protected from someone manipulating the DNS entry.

[watchpocket]

I'm curious why you'd want to point your namecoin domain name to the existing DNS?

Because, I now realize, I was confusing my hosting ISP's DNS numbers with my website's IP address. I thought the NS numbers *were* my site's IP addresses. Wrong.

I'll do whatever works. All I know is that right now no one can see my site by going to my dot-bit domain.

I've got a dot-net site already up. I'd like that site to be seen by anyone entering myname.bit into their browser.

I don't run the server for the dot-net site and I can't make server config changes.

Why not code the IP address into the namecoin domain value? This way you're protected from someone manipulating the DNS entry.

(a) I didn't know I could do that; (b) not sure I know how to do it; and (c) now that I think about it, I may in fact have done that. Is this command along the lines of what your talking about? It's what I did.

Code: Select all

namecoind name_firstupdate d/myname <rand> <tx> '{"map": {"": {"ns": ["198.7.0.1", "198.7.0.2"]} } }'

If not, then how, specifiically, does one "code the IP address into the domain value" and, more importantly, will it accomplish the goal?

Someone on IRC said what I needed was "forward DNS" by a third party, and referenced dnsmadeeasy.com but the how of that isn't too straightforward. Also, using a third party for another piece of the puzzle is more expense.

If the dot-bit project is to be at all popularized, this would seem to be an issue needing attention. Lots of folks wanting a dot-bit name will already have sites up, many of them, like mine, hosted remotely.

[khal]

Syntax with ns, compatible with future spec :

Code: Select all

'{"dns":["198.7.0.1", "198.7.0.2"], "map":{"": {"ns": ["198.7.0.1", "198.7.0.2"]}}}'

(your name_firstupdate was valid so)
This one requires you to configure bind (corrently not working : "host watchpocket.bit 198.7.0.1" failed with "REFUSED") + apache (virtualhost).


Syntax with direct ip, compatible with future spec :

Code: Select all

'{"ip": ["166.84.62.124","166.84.62.252"], "map":{"": "166.84.62.124"}}'

This one requires you to configure apache only.
Multiple ip allowed for new spec (using the ip record), not for the old.

[watchpocket]

Code: Select all

'{"ip": ["166.84.62.124","166.84.62.252"], "map":{"": "166.84.62.124"}}'

Ok, so I did this:

Code: Select all

namecoind name_update d/watchpocket <rand> '{"ip": ["166.84.62.124","166.84.62.252"], "map":{"": "166.84.62.124"}}'

Now host shows:

Code: Select all

host watchpocket.bit 166.84.62.252 
Using domain server:
Name: 178.32.31.41
Address: 178.32.31.41#53
Aliases: 

Host watchpocket.bit not found: 3(NXDOMAIN)

And whois has

Code: Select all

"Value: {invalid)"

so I'm not sure if I did that right.

Also, this is a problem:

This one requires you to configure apache only.

Again, I have no access to apache server config files.

As far as know, about as close as I could get to that would be putting commands into an .htaccess file in my public_html subdirectory on the ISP that hosts the dot-net site.

What alternative or solution would there be, short of asking ISP admins to modify apache?

[watchpocket]

Still in search of a solution to the above. . . .

[khal]

I didn't see it before, but name_update doesn't need the rand number...

Code: Select all

namecoind name_update d/watchpocket '{"ip": ["166.84.62.124","166.84.62.252"], "map":{"": "166.84.62.124"}}'

After things are updated, your web server will display : Access Denied (i put the ip in /etc/hosts to simulate a working dns and i got this error). You'll need to configure this right on your server :p

[watchpocket]

You'll need to configure this right on your server :p

So you're saying that if I don't have access to the server on which my site is hosted, I (and anyone else in the same situation) can't have a dot-bit site?

I do have an already-existing dot-net site, hosted on a server on an ISP. I'd like my .bit site to be, or point to, that same content that is the dot-net site.

But I have no access to that server, and I can't make config changes there.

So this means the only way to have a .bit site is to run your own server? I wish I'd known that before I went to the trouble and expense of registering a name. (I suppose I could look into 3rd-party "forward DNS", but I have no idea how, or if, it'll work. Clueful tips appreciated.)

Just to mention again something I said earlier, If the dot-bit project is to be at all popularized, this would seem to be an issue needing attention. Lots of folks wanting a dot-bit name will already have sites up, many of them, like mine, hosted remotely.