HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
okTurtles
dnschain
CoffeeScript2014–2016
okTurtles / dnschain

dnschain

A blockchain-based DNS + HTTP server that fixes HTTPS security, and more!

11Distinct people
48Mentions
1Explicit recommenders
1.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A blockchain-based DNS + HTTP server that fixes HTTPS security, and more!

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I think http://www.blockaid.me/ has been doing this, too, and I believe there were others. Some other approaches I've seen are based on Namecoin somehow. DNSChain for example…

higherpurpose used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year48 dated mentions

Observed mentions: 2014-03-31 19:23:56 UTC to 2016-11-17 21:39:30 UTC.

05101520252014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 24 mentions; 1 submissions, 23 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 18 mentions; 0 submissions, 18 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2016

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC24123
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC18018
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC624

What Hacker News says

18 sources
The issue at hand matters far less than the issue that the issue at hand is part of, which is the CA system itself. With the CA system, you have a two tier threat model where the mighty and powerful can have all seeing eyes and the consumer is told that all their https communication is secure and private. Certificate Transparency and other proposals may help fix this, but the first thing to do is to acknowledge that there is a problem, and so far the major players have yet to acknowledge the fundamental problems of the current CA system. LetsEncrypt makes it worse by promoting the wider adoption of this flawed system. Certainly won't help keep us secure against the Chinese or anyone with big resource. Update: Stating that there is no solution without any knowledge of the existing solutions is itself part of the problem. Let's start with t
Read the rest
In Distrust Let's Encrypt Subordinate Certificate
The issue at hand matters far less than the issue that the issue at hand is part of, which is the CA system itself. With the CA system, you have a two tier threat model where the mighty and powerful can have all seeing eyes and the consumer is told that all their https communication is secure and private. Certificate Transparency and other proposals may help fix this, but the first thing to do is to acknowledge that there is a problem, and so far the major players have yet to acknowledge the fundamental problems of the current CA system. LetsEncrypt makes it worse by promoting the wider adoption of this flawed system. Certainly won't help keep us secure against the Chinese or anyone with big resource. Update: Stating that there is no solution without any knowledge of the existing solutions is itself part of the problem. Let's start with t
Read the rest
In Distrust Let's Encrypt Subordinate Certificate
> I don't think DNSChain is a feasible project. If you want to prevent MITM attacks, it's one of the only options available to you (probably the only realistic option): https://github.com/okTurtles/dnschain/blob/master/docs/Compa... > However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1] DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.
In Maintaining Digital Certificate Security
When you run out of legitimate arguments resort to personal attacks, got it. The number of people on Earth who've spent the time studying Certificate Transparency in depth could probably be counted on two hands. You and I are two of them. That leaves ~8 other people (who are probably not reading these threads) to comment. I'm grateful to everyone who's taken the time to support DNSChain, Namecoin, and related projects by writing about them, podcasting, tweeting, blogging, contributing code, etc. https://github.com/okTurtles/dnschain#community This certainly requires community support.
In Google warns of unauthorized TLS certificates trusted by almost all OSes
> Certificate Transparency is a solution CT would not have prevented these attacks. Google would be exactly where they are right now: knowing who issued cert, and that's it. Short form: https://github.com/okTurtles/dnschain/blob/master/docs/Compa... Long form: https://blog.okturtles.com/2014/09/the-trouble-with-certific... (EDIT: How about an honest discussion instead of a downvote? If you disagree, you are welcome to explain why.)
In Google warns of unauthorized TLS certificates trusted by almost all OSes
> It's the golden unsolved, perhaps unsolvable problem in crypto. I think this problem was solved fairly well by Namecoin back in 2011. Software like DNSChain [1] then makes it possible to securely access blockchains like Namecoin without having to run a full node on your phone or other device. If you can't run your own DNSChain server (or don't have a friend's you can use), you can query two or more independent servers and make sure the responses match. Dionysis Zyndros recently came up with a mechanism whereby you can even query a single DNSChain server (that you might not trust), and still be assured of correct replies if you received an accurate key once (we'll be publishing info on this technique soon over at blog.okturtles.com; it's somewhat similar to what you're talking about with ratcheting keys). We maintain a comparison of vari
Read the rest
In Maintaining Digital Certificate Security
> The only (current) real remedy is the nuclear option Blockchain-based solutions like Namecoin & DNSChain would have prevented this attack without forcing people to rely on untrusted third-parties (if Google stored their domain info in a blockchain). We compare various mechanisms here: https://github.com/okTurtles/dnschain/blob/master/docs/Compa... EDIT: Not sure why this comment is getting downvoted. Maybe some folks don't want this problem to be fixed? :-\
In Maintaining Digital Certificate Security
> I wonder if certificate transparency could be mandated for intermediate certificates sooner than a full DV rollout could. It should be mentioned that Certificate Transparency would not have prevented this attack (nor any other such attack). Google has nothing to gain from CT beyond where they are right now: knowing who issued the cert. Details: https://blog.okturtles.com/2014/09/the-trouble-with-certific... TLDR: https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
In Maintaining Digital Certificate Security
> The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database. That can make it less likely that your certs will be used in revocation attacks. It does absolutely nothing to protect your visitors from other compromised certificates. The "best" known way (to my knowledge) is to use a blockchain, which doesn't have the revocation problem. Here is a comparison of a blockchain-based approach I'm working on with some other folks called DNSChain to other approaches people have suggested: https://github.com/okTurtles/dnschain/blob/mast
Read the rest
In How I got a valid SSL certificate for my ISP's main domain
> I guess this is the part that is still unclear to me: How is this different from a curated list of pinned certs coupled with a ca cert store that holds only my own ca cert? That sounds like it would have similar/identical properties to HPKP, which we cover here: https://github.com/okTurtles/dnschain/blob/master/docs/Compa... > How can/why should I trust a dnschain server to validate google.com? Because there is ample evidence in the blockchain that others have been tricked by/trusted a particular key/cert for google.com? As mentioned in the article (and in a footnote therein), .com's cannot be MITM-proofed in a practical manner, unless they imported into a blockchain. If you do not trust a DNSChain server, do not use it. Use only the server(s) you trust, and then you can trust the data in the blockchain. The data in the blockchain, mean
Read the rest
while, is secure from MITM attacks as explained in more detail here: https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i...
In DNSChain 0.5 released, brings full HTTPS support, Openname Resolver API and more
> I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server? A traditional DNS server does not give you access to blockchain-based domains. Blockchain TLDs (like .bit) can be MITM-proofed. DNSChain also lets you communicate with blockchains over a MITM-proof HTTPS connection: https://github.com/okTurtles/dnschain/blob/master/docs/What-... > not that such metadata isn't rather obvious anyway by observing traffic between ips. Tor is your best option if you want complete anonymity. DNSChain does have a planned feature called Unblock, which is effectively a DNS-based proxy that hides metadata as it travels between client and DNSChain, but if you want the best anonymity you should still use Tor. DNSChain is a secure PKI solution (alternative to X.509), the primary purpose of which i
Read the rest
s to securely and simply distribute public keys, as that's what provides protection from MITM attacks. > How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?). CACert is a CA. You can certainly design your software to only trust certificates from one CA, but that is only useful in special-purpose situations, it's not going to work for general purpose browsing. In X.509, everyone on the Internet is forced to trust the weakest link, and security decreases for everyone with the more CAs there are. The opposite is true with DNSChain-based PKI, where the more independent servers that are queried, the more certain you can be of the authenticity of the response. If you completely trust a particular DNSChain server, then it's the only server you need to query.
In DNSChain 0.5 released, brings full HTTPS support, Openname Resolver API and more

Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.