Yeah its a good idea for a plugin, I already made some experiment earlier when i wanted to implement .bit support using http://www.opennicproject.org/
Need more experimenting, not sure if its possible using http://pydns.sourceforge.net/ & Tor network

Added pullrequest #111

The problem is it relies on dns servers, so the sites will not works offline. Cache required to make it work without internet connection example at dnschain plugin.
I don't really want to add more external dependencies, but pydns is a pure-python module, so distributing in the lib dir could work.

I think this will help a lot! And you can make the DNS support as a "fallback" in case other solutions are failing, to make it less centralised @HelloZeroNet and probably there is a solution to make it work offline as well.

The trouble with DNS is that it's not secure and is also quite centralized.

@HelloZeroNet Any progress here? Will classic DNS be supported?

Even if DNS isn't so decentralized, it would be good if it is supported.
You could use cache to avoid offline problems. And there are probably also solutions for other problems with it.

And for DNS servers, it should probably use OpenNIC by default (because it is "open and democratic alternative DNS root"), but it should be configurable by user.

IPFS also support similar thing.

You can add TXT record that points to IPFS file hash (dnslink=/ipns/<your-hash>). File is then accessible from ipfs-proxy.com/your-domain.com.

In addition, if you also create CNAME record that points to public IPFS proxy (217.182.195.23 for gateway.ipfs.io), file is also accessible directly from your-domain.com).

This would also be extremely useful for ZeroNet. Site owner would then only need to create TXT record with ZeroNet address and CNAME record that points to (trusted) ZeroNet public proxy or local ZeroNet instance and site would be accessible directly from classic domain.

Note that implementing TXT query only on the main domain is not a very good idea since that prevents using CNAME records.

IPFS introduces _dnslink prefix and queries TXT record like this:
get TXT of _dnslink.example.com
if that failed, get TXT of example.com

That way you can setup CNAME on example.com and additional TXT record on _dnslink.example.com.

@ValdikSS Yes, that is how I want to be implemented. With this, it should be also possible to handle subdomains (_dnslink.subdomain.example.com), right?

@filips123 Yes, should be no problems with subdomains.

@ValdikSS It appears that DNSLink, which is used by IPFS, is already some kind of standard. It also supports linking other types different from IPFS.

So, instead of reinventing the wheel with a custom type of DNS record, ZeroNet should just use DNSLink. ZeroNet records should use the same names and structure as IPFS's, just record's content should be dnslink=/zeronet/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D.

If you want to use third-party external resolvers by default in the first place (why by the way?), maybe it's better to use DoH then?

External DNS servers are used because they are for OpenNIC which is "open and democratic alternative DNS root". This could make DNS at least a bit more decentralized.

It is also possible to use system configuration. But in most cases, default system DNS servers will be from ISP or Google, which isn't so decentralized and also doesn't support special free OpenNIc domains. That's why it is not used by default.

Here in Russia many ISPs perform DNS transparent proxying to their own DNS resolvers for censorship reasons. Sending DNS request to any IP address, like one which does not run DNS recursor or even to unroutable IP address results in a DNS response.

I mean, it's not sane to use third-party unencrypted DNS resolver by default, IMO. It either should be system default resolver or DoH/DoT.

I'd say:

• Use system default resolver in No Tor/Tor Available mode by default
• Use DoH in Tor Always mode, always

What do you think?

Also to note, dnspython sometimes can't detect system default resolver and does not work properly. I'm not sure which platforms are affected (Windows I suppose), but in my blockcheck software I see reports of broken system resolver once in a while.

@ValdikSS Using system default resolver would remove the ability to use OpenNIC-specific features, like additional free TLDs, Emercoin TLDs...

I would more like that DoH/DoT resolvers will be always enabled, regardless of what Tor is, except if the user specifically doesn't want this. However, DNSPython currently doesn't support DoH and DoT (see rthalley/dnspython#358 for details).

DoH protocol is very simple, it can be used without any external library:

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=TXT'
{"Status": 0,"TC": false,"RD": true, "RA": true, "AD": true,"CD": false,"Question":[{"name": "example.com.", "type": 16}],"Answer":[{"name": "example.com.", "type": 16, "TTL": 4143, "data": "\"v=spf1 -all\""}]}

@HelloZeroNet Great! All DoH resolvers use same request and response format in JSON, right?

Because DNSPython also supports some other features (like cache, response handling...), I will try to create PR for it with DoH support. This means that DNSPython (when using DoH nameserver) could completely bypass current TCP/UDP socket requests and just use urllib or similar. This should also fix issue with Gevent and non-blocking sockets.

It would also be good to support DNS stamps. I found Python library for that, but I don't know what exactly all data in stamp mean and how to use it.

Also, because I will use urllib for making HTTP requests, I also need to know if it will be automatically monkey-patched in ZeroNet for Tor, or I will need to do this manually.

The API should be the same for every provider, the http lib is already patched, so you don't have to do anything just use urllib.request

I almost implemented DoH support for DNSPython. It uses basic urllib.request so there should hopefully be no problems with Gevent. I will try to test it tomorrow and then create PR for DNSPython next week. Then DNS plugin for ZeroNet would just need to wait until PR is merged or use my temporary branch for DoH support.

@HelloZeroNet @imachug @ValdikSS I created #2214.

I would highly recommend placing the TXT records at a designated subdomain (perhaps _zero), i.e. a TXT record at _zero.sub.example.org would correspond to a user-visible address of sub.example.org. This makes it more feasible to control permissions for ZeroNet separately from IP address records; it's what TLSA records do for this reason.

Also, Namecoin supports TXT records, so it would be theoretically possible to unify the Namecoin and DNS support in ZeroNet, which would have benefits. Namecoin's onion service support takes this approach (.onion domains are specified in a TXT record, so Namecoin and DNS use the same spec.)

My PR already supports _dnslink subdomain which is is the same thing as used in IPFS-based websites and other decentralized systems.