Topic: [announce] Namecoin - a distributed naming system based on Bitcoin - page 96. (Read 594420 times)

I don't know much about DNS so avoided modifying or using any existing DNS code. What I have been able to do is get 'dnsmasq' to serve namecoind names using a standard dnsmasq build. eg. try:

This seems to work well. What I did was write a small program that does a name_scan and prints out the valid mappings in the same format as /etc/hosts. I then run dnsmasq with the option for obtaining names from this file. I have a script that runs every 5 minutes that rewrites this file and sends a SIGHUP to dnsmasq. The program to generate the hostfile is namecoin-hosts.c. It needs libjansson and libcurl. It can be built with:

The entries I changed in my dnsmasq.conf were:

I have a simple shell script that does the updating:

@memvola and others that have namecoins held up by a firstupdate on a name that'
s already taken.  I pushed a new version to github.  It has a new command that will clear these transactions.

The symptoms include having transactions that won't confirm.

@doublec thanks for the modified polipo.  What do you think about a modified resolver library that allows "sideloading"?  How about this in /etc/resolv.conf:


and


Oh and I should have used double quotes in my examples like you have it.

I hacked a bit on the polipo HTTP proxy code and added simple namecoin support for DNS lookups. The modified code is in this git repository: https://github.com/doublec/namecoin-polipo. It needs libjansson for JSON parsing and libcurl for talking to the namecoind JSON-RPC server.

Once compiled, you can run it passing it the details about the namecoind server:


This will start the proxy, and it'll connect to the namecoind JSON-RPC server with the given details. It runs 'name_scan' to get the list of names. Any program using this proxy will have all .bit domains resolved by namecoind. Currently it only supports mapping to IP addresses. So namecoind values like the following work: {"map":{"":"192.0.32.10"}}. As an example 'bluishcoder.bit' hopefully resolves to the IP address of my server with my weblog using this version of polipo. It rescans namecoind when a request is made for a domain lookup and the last scan was more than 10 minutes ago. 

To use it with Firefox (or other browsers) go into the network settings and set the 'http proxy' to localhost, port 8123.

I decided to do this to avoid needing to run the ncproxy script since I don't need socks support. Comments, suggestions, patches are welcome.

An option for using socks enabled programs is to use ncproxy combined with SSH. SSH to localhost using the '-D' option to set up a socks proxy. 


This sets up ncproxy to forward to the SSH proxy. You can configure firefox to use this socks proxy by going into 'Preferences/Advanced/Network/Settings' and adding '127.0.0.1' and '9055' in the Socks proxy area. You should also go into 'about:config' in Firefox, search for net.proxy.socks_remote_dns and double click on it to set it to true. This will cause DNS requests to go through ncproxy and then the SSH socks proxy.

You can also slip polipo in there if you want a web cache. Run:

Configure firefox to use the HTTP proxy on port 9055 instead of a socks proxy.

These approaches seem to work in that name lookups occur. Unfortunately there appear to  be no namecoin entries with the JSON format to actually see if ncproxy is doing the job.

I'll second this.

kind of a noob question:
is there a way to see blocks that are maturing (less than 100 confirmations)? I've mined several blocks ("accepted" in poclm), but it's not showing up in my balance, nor is it showing up in my transactions list.

Until a DNS proxy that uses namecoin comes along, one approach to using namecoin for host name lookups could be to provide the option to scan the names every time a block is mined and update/rewrite the users /etc/hosts (or windows equivalent). This might be a quick way of starting to use the namecoin chain for lookups. Even a simple script that does this every 10 minutes or so, getting the names from namecoind via RPC would do a reasonable job.

(Sorry, I deleted my first reply.)

I already suggested this as one of the options, i.e. names act as TLDs. DNS servers need to recurse first and then check the names in the blockchain, though only for ICANN and maybe OpenNIC TLDs. That way, ICANN's "google.com" takes precedence over our "com" and "google.com" but maybe not "sillyname9999.com".

But this idea is prone to other messy situations. Separating namecoin names is always a good idea. For instance, if an alternative to namecoin comes along, they can live together side by side.

EDIT: Plus, I nominate ".c" as the standard TLD. I think it's more catchy than .b and .n and would look better on a billboard than .bit. It strangely resembles .com and .co but is neither, and probably won't be adopted by ICANN anytime soon. "c" also has a professional look, probably because .com and © and some other IT related stuff.

heh, fixed

it will fail miserably when someone registers "com", "net", etc.

fail
http://webchat.freenode.net/?channels=witcoin&uio=d4

#namecoin on Freenode

Looks like my node is also suffering from a third kind of problem that I haven't noticed before... I have in my name_list, some names I've been able to update and some that I've firstupdate'd without problem but now belong to other people (this is the old issue).

The new thing I noticed is, while these erroneous entries stay in the list, some of the names I've successfully updated disappeared between restarts (there were some crashes too). Now, the names carry my values, but I can't update them anymore:

So, what does it mean? Is there a way I can get back the names? I was really planning to start using one of them right away.

EDIT: I restored a backup from 5 days ago. I could see the names there. I know I shouldn't have, but things were already screwed up, so in the spirit of testing, I tried updating one of the names from there. Successfully updated the name. But the fantastic thing is, when I got back to to my current version of .namecoin directory, I got the name back!? It's not only in name_scan but actually in my name_list. I don't know how this might have happened (so the coin was there but was locked/hidden somehow?). Anyway, I think I'll now try to transfer the money I lost through missed names and see what happens...

EDIT2: I restored all names and saw them in my name_list for a while. After some blocks, I thought it would be safe and tried a restart, and some names vanished again (including one that was there before I tried this "restore from backup" endeavor). Didn't have time to get to transferring the money, so that's not the cause. I think it's the same bug or db corruption. At least I now know that they're not lost because of a namecoind crash.

When namecoind has been restarted you might need to also enter the long string that is returned from name_new.  For example:



Try the suggestion above of using the long random string as well as the short.  You will need around 45 Namecoins to do the name_firstupdate however.

+1

So Trends would be http://trends.google ?

namecoind also now crashed (windows binary).. I have all the hex codes saved from my "name_new" attempts. Whenever I now try to use "name_firstupdate" I receive "could not find a coin with this name".

The namecoins are gone from my balance.. Have I lost my namecoins?

Perfect! Do you have a donation address so that we can show our appreciation?

For the final specification, the criteria I have is:

• IP-only services need only supply master server addresses, just as they would do with a name registry.
• Services which don't control a nameserver can supply DNS records, with MX and whatnot. Local proxy needs only consider CNAME, A, AAAA and maybe namecoin specific records (hidden services, etc.).
• IP/Non-IP hybrid services can optionally use the same name to be resolved according to context (i.e. if I'm going through I2P, name resolves to the I2P address).
• Specification allows the delegating system (DNS bridge, proxy, etc.) to take the above two items into consideration. For instance, if name resolves to a tor hidden service, it shouldn't go ask the master server for IP.

Last item is a little awkward (first recurse, then forward), but I need to sleep over this first. Before vinced's post, I was thinking more like having different Json objects for forwarding (IN), zone (IN) and each non-IP service.

@dmp1ce Thanks for building binaries!

I was wrong, it is possible to do DNS delegation behind Tor.  I will have a new version of ncproxy shortly.

I am thinking of the following JSON format for a simple delegation:

{'map': { '': { 'ns': ['10.0.0.1'] } }

@khal There is no need to have the domain name in the value, as the name is already separated out in the protocol.  Also, I think it is best to have DNS delegation to IP addresses for now, to keep things simple.  Does this sound OK?

@xf2_org I will update the address format soon.  Good catch.

@anarchy Using no TLD would not work well with Chrome, since it will do a Google search instead.  It will also break for corporate people that use single word hosts internally.

@memvola I will look into your issue shortly.

!Vince

I have an issue trying to make a name visible..

I have already used "namecoind name_new d/mydom"... waited 12 blocks, am now trying to -

"namecoind name_firstupdate d/mydom xxxxxxxxxx test"

I get -

error: {"code":-4,"message":"Error: Transaction creation failed  "}

Any idea what the issue is?


The hex code is correct.. because if I try a different hex code it mentions "previous tx used  a different value".

Thanks.