beta testing of new, in-house DNS resolvers | DNSchain

[cryptostorm_team]

{direct link: cryptostorm.ch/dnschain}


Ok, they're still undergoing load-testing and it's possible they'll be a bit crash-y meanwhile, but we've got two publicly-available DNS resolvers ready for some load testing:

• 74.121.182.147 (hostname-mapped to dnschain1.cryptostorm.net)
  167.88.9.30 (hostname-mapped to dnschain2.cryptostorm.net)

These resolvers are backed up by our deployment of the DNSchain system, as implemented by OKTurtles (github repository here). Yes, it's sort of silly to provide subdomain-based TLD lookups to these IP addresses (dnschain1.cryptostorm.net; dnschain2.cryptostorm.net), since to use those as resolvers you'd first be doing a traditional resolver lookup, then using that IP address to do a DNSchain-based lookup... but we mapped them even so, just in case there's some use to such mappings we haven't figured out ourselves, just yet.

DNSchain is a powerful approach to solving a good chunk of the deep structural problems that currently bedevil the Domain Name System (DNS), & everyone who uses it to connect human-readable domain names with internet protocol (IP) addresses. There's several layers to DNSchain, and our fully leveraging of these layers is a work-in-process. For now, we're implementing these publicly-available resolvers even as we continue to backfill the additional functions of DNSchain within our own network architecture.

For those curious, here's a quick intro whitepaper to how DNSchain is implemented:

dnschain_okturtles_overview.pdf

(330.5 KiB) Downloaded 1666 times

These resolvers are intended, once testing is complete, to serve two core purposes:

• 1. Provide first-priority lookup service in our "pushed" DNS resolver settings for members connected to cryptostorm. As we discuss in this thread, DNS resolution is an important element in our overall network security model; adding our in-house resolvers to the resolver pool members use during cryptostorm network sessions is an important step forward towards increased resilience, security, and reliability in this function.
  
  2. Offer publicly-available resolver access, for anyone who wants to have a DNSchain-based resolver to use in their own setup. The choice to make our resolvers publicly available is one we found easy to make, to be honest - it's a reflection of how we approach most all of our technological tasks, at cryptostorm.

As we continue to flesh out the additional elements of the DNSchain security model in our production framework - adding public key validation to cryptostorm-session lookups, offering .bit domains to compliment traditional TLDs, and so on - we'll post those details here. Meanwhile, feel free to share ideas, feedback, results of your testing, and suggestions here in this thread.

Thanks in advance for your help in testing and improving these resolver resources!

cryptostorm_team

[Pattern_Juggled]

Since the question comes up quite a bit - both because it's related and also because of the somewhat-confusing nomenclature issues - figured I'd drop a note in this thread confirming that, yes, we're very much working towards a deploy of DNScurve's approach to security enhancement of DNS queries.

As we are modelling the two tools, DNScurve & DNSchain are complimentary pieces in the larger architecture of on-cryptostorm domain resolution resources. This may be naive, or prove to be an impractically simplistic framing of a solution framework, but currently it's how we're seeing them: DNSchain is the "backend" that runs in our node network to provide resolver services, and DNScurve is the glue that secures in-transit queries between cryptostorm-connected members and the DNS resolver services they need in order to make use of internet resources.

We don't intend to use DNScrypt - a well-regarded bit of client-side tech that, sadly, OpenDNS is no longer actively maintaining and which has fallen somewhat into dusty somnolence as a result - but since it's really a specific implementation (or fork) of DNScurve itself, one could say we're doing a parallel instantiation of a similar approach to securing query traffic.

I'll be posting more on the architectural model we've developed internally, relating to DNScurve, as time goes by. For now, our answer in one word is: yes.

Cheers,

• ~ pj

[Pattern_Juggled]

Also, this: curveDNS

shaping_dns_security_with_curves.pdf

(2.52 MiB) Downloaded 1747 times

Cheers,

• ~ pj

[Pattern_Juggled]

Courtesy Fermi, via twitter:

[DesuStrike]

THANK YOU!

I was waiting for this like from the day I switched to cryptostorm. DNS censorship is a lengthly discussed issue in my country but even though we managed to prevent it being broadly deployed so far there already is a (recently leaked) government maintained secret blacklist for "youth protection" that some ISPs enforce. But the idea of DNS censorship is one of those political zombies that for some reason never die but always come back crawling at us no matter how often we squash them. It's just a matter of time until we lose this fight and then we can't get rid of it anymore.

So an uncensored DNS that provides the three fundamental basics of security deployed by a highly trusted source is very welcome!

One question though: Is it possible to add a third IP to your DNS pool?

(Maybe this is the wrong place for discussion...)
Most routers use ISP provided DNS servers by default if you don't specify your own selection. So I always add my own choice of DNS to my dd-wrt router to overwrite this default setting. The problem here: DD-WRT lets you specify three custom DNS. If you add only two and leave the third one blank the primary DNS of my ISP will be transparently used as the tertiary DNS by my router. Transparently because the third slot stays blank but if you do some extensive DNS leak testing the ISP DNS will pop up eventually. Only if I specify three custom DNS I was able to get rid of my ISP.

I don't know why this happens and maybe this is a DD-WRT specific bug. Also this observation was made over a year ago when I was really a noob and I might goofed up somewhere. I'd be happy if others also using DD-WRT and custom DNS could tell me their experiences with this. thx

[parityboy]

@team

Many thanks for bringing this into service. I assume that ultimately, these resolvers will be pushed by your OpenVPN server instances. However, the obvious question is: will these resolvers be exclusive to CryptoStorm connections or will they be available to all? I ask because very obviously, HAF entries need to be resolved before the VPN connection is made.

EDIT:

I didn't read the OP fully, they are publicly available. *slaps forehead* Anyway, I've switched over to them.

[DesuStrike]

DNS Spoofability Test: https://www.grc.com/dns/dns.htm

Will test it as soon as I added the Servers to my setup but maybe some people will run their own test.

EDIT:
I forgot to make screenshots but to make a long story short: The DNS servers are indeed very beta at the moment.
-> The performance is very volatile but mostly slow.
-> The GRC spoofing test result was "MODERATE". Query Transaction ID Distribution was EXCELLENT but Query Source Port Distribution was very biased with a clear cut off at a certain port number and also stuck bits.
-> DNS-Leaktest went totally insane for some reason showing 20 Google servers as being my DNS resolvers. This is obviously false but I wonder what caused that.

I also noticed that both DNS servers are located in the USA. Dunno if that could be problematic or not.

[marzametal]

Once this is up and running, would there be a need for Windows users to use DNSCrypt?
https://www.opendns.com/about/innovations/dnscrypt/
http://techrights.org/wp-content/upload ... _Guide.pdf

[marzametal]

DNS Spoofability Test: https://www.grc.com/dns/dns.htm

Will test it as soon as I added the Servers to my setup but maybe some people will run their own test.

EDIT:
I forgot to make screenshots but to make a long story short: The DNS servers are indeed very beta at the moment.
-> The performance is very volatile but mostly slow.
-> The GRC spoofing test result was "MODERATE". Query Transaction ID Distribution was EXCELLENT but Query Source Port Distribution was very biased with a clear cut off at a certain port number and also stuck bits.
-> DNS-Leaktest went totally insane for some reason showing 20 Google servers as being my DNS resolvers. This is obviously false but I wonder what caused that.

I also noticed that both DNS servers are located in the USA. Dunno if that could be problematic or not.

I can confirm some of the edit...
1 - I couldn't get the GRC DNS Spoof Test to run... kept on coming up with "No nameservers were found".
2 - IPLeak went nuts too, but only showed 10 Google servers as being my DNS resolvers...
3 - DNSLeak showed 3 Google servers as being my DNS resolvers...

[Guest]

I run dd-wrt as well.
Just a heads up, dd-wrt will NOT allow dns settings to be pushed by the vpn service provider if the dns servers are set manually. I'm not sure if it will if they are left blank... if it will, as an anti-leak work around, most modums can be logged into @ 192.168.254.254, or 192.168.1.1 user/pass = admin/admin (which should be changed while your there.), and somewhere in the modums menu you can set the defualt dns for it to push to the dd-wrt router. Also, though there's probably a way to resolve this through iptables (which I don't know how to do), my expirience was that dd-wrt will not resolve hostnames when cycling the vpn, so you must have the vpn server raw ip in your config, and if it changes you'll have to manually redo the configuration.

I just bought a aleph token- would greatly apreciate any attention admin here could give to the dd-wrt setup thread, it's a bit of an outdated mess.

[cryptostorm_support]

I run dd-wrt as well.
I just bought a aleph token- would greatly apreciate any attention admin here could give to the dd-wrt setup thread, it's a bit of an outdated mess.

To be perfectly honest, more than a couple tutorials suffer from the same affliction and we're working to fix that. We've already updated a couple, but I'll make sure the dd-wrt gets added to the queue.

[DesuStrike]

I run dd-wrt as well.
I just bought a aleph token- would greatly apreciate any attention admin here could give to the dd-wrt setup thread, it's a bit of an outdated mess.

To be perfectly honest, more than a couple tutorials suffer from the same affliction and we're working to fix that. We've already updated a couple, but I'll make sure the dd-wrt gets added to the queue.

Scratch that from the list CS_S! I volunteer to update the DD-WRT guide. I made it originally anyways...

EDIT: DONE! Please click here
I hope you enjoy.
Please consider that depending on your router performance you will get slower internet speeds than usual running cryptostorm on a router. Your router should at least have a 1.4 GHz dualcore processor to get 50 Megabits per second pushed through.

[taoeffect]

Very cool! I just created an account on these here forums on account of this news.

As one of the developers working on DNSChain, I'd like to also give you folks some heads up on some of the significant work that will be arriving in the next release of DNSChain:

• A web-based admin interface is coming. You can try it out now via the `admin` branch on GitHub.
• Throttling (aka "rate-limiting") will be coming as well and can be tested out now via the `dev` branch.
• We're making DNSChain super-modular for better blockchain support. Developers who want to add support for their blockchain will be able to do it by simply copying and updating this one file.
• The Unblock feature (DNS-based proxy for censorship circumvention) is almost ready to go live thanks to advanced TLS discrimination over port 443 which is now in `dev` and undergoing final review.

If ya'll need any technical assistance we're happy to help! You can create issues on GitHub or ask question on the forums or over on Gitter.

Keep up the awesome work Cryptostorm!
Greg

[taoeffect]

Oh, I forgot to add, we're also working with OneName on a spec for the API to the resolver that you may be interested in having a look at (and are welcome to offer feedback on).

[Guest]

"EDIT: DONE! Please click here"

Wow, fast- Thanks!

"Your router should at least have a 1.4 GHz dualcore processor to get 50 Megabits per second pushed through."
I sooo look forward to the day I have to upgrade my router to handle 50Mb/sec- if it ever comes.

[Guest]

dns leak tests come back as 23.226.227.93 and .94 -I've never seen those ips, they're not in my configs, or coming from my isp.

Sorry if this is a stupid question- have read allot, and have much more to read on this stuff- but do I need to do more then entering these servers into my dns config?

[DesuStrike]

I think this is a good place to mention that the last couple of days both Fermi and I experience strange lags when resolving DNS queries with the standard pushed DNS servers. I'll try to find the culprit and will test if it gets better when I remove it.

Just another reason for in house DNS resolvers!


EDIT: Yes indeed. I changed the DNS servers to a set of uncensored DNS provided by German internet rights groups and everything is running smooth again.

Here is what I use until CryptoStorm has their own DNS up and running for production:

85.214.20.141 (FoeBud)
194.150.168.168 (dns.as250.net; Berlin/Frankfurt)
213.73.91.35 (dnscache.berlin.ccc.de)

[bricky149]

I think this is a good place to mention that the last couple of days both Fermi and I experience strange lags when resolving DNS queries with the standard pushed DNS servers. I'll try to find the culprit and will test if it gets better when I remove it.

Just another reason for in house DNS resolvers!


EDIT: Yes indeed. I changed the DNS servers to a set of uncensored DNS provided by German internet rights groups and everything is running smooth again.

Here is what I use until CryptoStorm has their own DNS up and running for production:

85.214.20.141 (FoeBud)
194.150.168.168 (dns.as250.net; Berlin/Frankfurt)
213.73.91.35 (dnscache.berlin.ccc.de)

For me the lag happens occasionally but not enough for it to be a problem. I've also had a case today where a certain website decided it didn't exist anymore, only to work about a minute later.

[Fermi]

I get pushed four DNS entries:

213.73.91.35 (mean response duration : 115ms)
213.138.101.252 (doesn't respond to DNS queries according to DNS Benchmark)
80.237.196.2 (doesn't respond to DNS queries according to DNS Benchmark)
194.150.168.168 (mean response duration : 220ms)

In the DNS Benchmark overview I also included the DNSChain servers, being:
74.121.182.147 and 167.88.9.30

Conclusion, some of the pushed DNS servers appear to be dead. Informed df, df will fix this.

/Fermi

[Guest]

I've yet to expiriance any perciveable lag or loss from the test dns servers- in fact they seam faster and more stable then the openic servers I was using before. I havn't used the standard pushed dns enough to judge it's stability.

Also can confirm dd-wrt contiunes to ignore pushed dns when they are set manually (I noticed an allow dns push setting in the config- it doesn't work, at least when authoritve dns is set in main setup page- I think that's a defualt setting, at least on kong builds. havn't tested with this setting off).

I made a post in the dd-wrt setup thread pointing out a buffer setting which botched the setup for me, if you can add that to the instructions it might help some people- this may only be an issue on kong builds. (the dev is a bit behind on the non-beta version, maybe the next release will fix this)

still waiting to hear back wheather the 23.226.227.93-94 coming back from leak tests is expected behaivor- and hopfully an explaination as to why.


Thanks for all your good work. This new DNS system is exciting progress.

OT- but any idea why firefox's spell checker doesn't work on CS's post forum? I've set layout.spellcheckDefault to 2....

[Fermi]

Same findings here:
When using the two in-house addresses (74.121.182.147 and 167.88.9.30) and wrangling them through https://www.grc.com/dns/dns.htm (DNS Nameserver Spoofability Test), the following name servers are returned:
23.226.227.93
23.226.227.94

Results of the spoofability test are actually marked as excellent.

Forensics show that 23.226.227.93 is a free public DNS Chain server : 2.dnscrypt-cert.okturtles.com
Nothing found on 23.226.227.94, but as this IP is sitting close the the previous, we can presume this is also a free public DNS Chain server run by okturtles.com.

So my assumption is that DNS requests to 74.121.182.147 and 167.88.9.30 are forwarded to these two free public DNS Chain servers ... .

Correct assumption?

/Fermi

[taoeffect]

Same findings here:
When using the two in-house addresses (74.121.182.147 and 167.88.9.30) and wrangling them through https://www.grc.com/dns/dns.htm (DNS Nameserver Spoofability Test), the following name servers are returned:
23.226.227.93
23.226.227.94

Results of the spoofability test are actually marked as excellent.

Forensics show that 23.226.227.93 is a free public DNS Chain server : 2.dnscrypt-cert.okturtles.com
Nothing found on 23.226.227.94, but as this IP is sitting close the the previous, we can presume this is also a free public DNS Chain server run by okturtles.com.

So my assumption is that DNS requests to 74.121.182.147 and 167.88.9.30 are forwarded to these two free public DNS Chain servers ... .

Correct assumption?

/Fermi

Hmm, if that's the case, then that means cryptostorm isn't actually running its own servers?

Well, let us know if you are and I can add you to the list of public servers on the wiki! (Or you can just edit the page yourself and send a PR).

[df]

Trying to figure out where those IPs are coming from in our setup.

It's basically just dnsmasq + dnschain.

dnsmasq.conf is:

Code: Select all

listen-address=74.121.182.147
listen-address=167.88.9.30
server=/bit/127.0.0.1#5333
server=/dns/127.0.0.1#5333
server=/eth/127.0.0.1#5333
server=/p2p/127.0.0.1#5333

and .dnschain.conf is:

Code: Select all

[log]
level=info

[dns]
host = 127.0.0.1
port = 5333
# no quotes around IP
oldDNS.address = 8.8.8.8

# disable traditional DNS resolution (default is NATIVE_DNS)
#oldDNSMethod = NO_OLD_DNS
oldDNSMethod = NATIVE_DNS

[http]
host = 127.0.0.1
port=8088
tlsPort=4443

Not sure if it matters, but /etc/resolv.conf is set to use 213.73.91.35 (a ccc.de public DNS server).

EDIT:
Yea, I just checked on a win8.1 test box. I manually assigned the DNS server to 74.121.182.147 via netsh and nslookup.exe resolved okturtles.bit like it should. But when I went to grc.com and did the same test it shows me a 213.73.* IP as being leaked. As I mentioned, the server running dnschain/dnsmasq/namecoind/etc. uses the ccc.de public DNS server that's in the same b-class. Oh and btw, I did this test without being connected to the VPN.

[Fermi]

Hi,

There's a good explanation on how the spoofability test works: https://www.grc.com/dns/howthisworks.htm
I think we are dealing with the situation below:

Apparently the CS in-house resolvers are offloading the actual requests to:
23.226.227.93
23.226.227.94

?

/fermi

[df]

Thing is, there's nothing in the configs that would cause or suggest that. When I tested it at grc.com (and when Pattern_Juggled tested it) we both saw the leaked IP as something that's in the b-class of the ccc.de public DNS server that's set in /etc/resolv.conf on the server running dnschain/dnsmasq.

Are you sure you don't have something else that's changing your local DNS settings to use those IPs?
Maybe try grc.com after setting the DNS to the 2 DNSChain IPs on another device?

[DesuStrike]

Well, I am the one who set Fermi up to run the spoofability test because marzametal and I got those crazy results showing several IPs belonging to Google. Even though Fermi could not exactly reproduce our findings his results are strange as well.

So I'm starting to think we have several problems here resulting in different effects.
I have absolutely no idea what could be causing my results but I can say with absolute confidence that I don't have any software or hardware in my network that forwards, redirects or regularly calls on IPs owned by Google. I take extra care to make sure of that. So wherever this redirection occurs it can't be coming from my private network. It would also be strange if marzmetal just happens to have the same configuration error like me causing such a unique behavior.

[df]

The Google one makes sense though, the default DNS server was set to forward to 8.8.8.8 (Google's public DNS server) for normal DNS traffic.

It's since been changed to ccc.de's 213.73.91.35 though, so if you run the test again you should no longer see anything Google related in the results.

[Guest]

I just got redirected to imptestrm.com, which itself wanted to redirect to a doubleclick site to search for the unresolved site.

incidently (maybe, probably?) the site it failed to resolve is the site/blog of one of the co-founders of benaki.

[Guest]

whoa- same thing is happening with the standard dns servers. is this on my end somehow?

[Guest]

I apoligise- I jumped to conclusions here; it apears to be only related to that particular site. probably not dns-redirect- the way it was happening reminded me of the old opendns redirects.

[Fermi]

Did some further tests:
To have an indication that there's not some ghost configuration is influencing the test results, I did some tests with public DNS servers:

I did the same test with different DNS servers configured (W7, no VPN connection)

• 1)
  DNS servers (OpenDNS)
  208.67.222.222 (resolver1.opendns.com)
  208.67.220.220 (resolver2.opendns.com)
  
  results:
  208.69.35.19 (m9.ams.opendns.com)
  208.69.35.15 (m5.ams.opendns.com)
  
  2)
  DNS server (dnscache.berlin.ccc.de) [the one resolv.conf Cryptostorm]
  213.73.91.35
  
  results:
  213.73.91.41
  
  3)
  DNS servers (OpenNIC)
  107.150.40.234 (mail.zee.li)
  50.116.23.211 (renamon.bersl2.info)
  
  results:
  107.150.40.234 (mail.zee.li)
  96.126.112.223 (renamon.bersl2.info)
  
  4)
  DNS servers (Level3)
  209.244.0.3
  209.244.0.4
  
  results:
  8.0.26.* (90 IP's)
  8.0.24.* (115 IP's)
  192.221.153.* (77 IP's)
  192.221.154.* (115 IP's)
  192.221.152.* (77 IP's)
  
  5)
  DNS servers (Google)
  8.8.8.8
  8.8.4.4
  
  results:
  74.125.47.* (10 IP's)
  74.125.73.* (18 IP's)

It's clear that the results are changing with the chosen public DNS servers, so we can exclude influence from other exotic configurations.
We also see that ex. the Google servers are boldly redirecting the queries.

One step further, here are the combinations between one public server and an in-house CS DNS server:

• 6)
  DNS servers
  8.8.8.8 (Google)
  74.121.182.147 (1st CS In-house)
  
  results:
  74.125.73.* (18 IP's)
  74.125.47.* (10 IP's)
  213.73.91.41
  
  7)
  DNS servers
  107.150.40.234 (mail.zee.li)
  74.121.182.147 (1st CS In-house)
  
  results:
  107.150.40.234
  213.73.91.41
  
  8)
  DNS servers
  107.150.40.234 (mail.zee.li)
  167.88.9.30 (2nd CS In-house)
  
  results:
  107.150.40.234
  213.73.91.41
  
  9)
  DNS servers
  74.121.182.147 (1st CS In-house)
  167.88.9.30 (2nd CS In-house)
  
  results:
  213.73.91.41
  
  10)
  DNS servers
  213.73.91.41
  
  results:
  isn't recognized as a DNS server?

Strange thing here, we see:
213.73.91.41 appearing instead of 23.226.227.93 and 23.226.227.94 I (and guest) had earlier (no configuration change).

Connected to Cryptofree and forced tap if to use the in-house DNS servers:

• 11)
  DNS servers
  74.121.182.147 (1st CS In-house)
  167.88.9.30 (2nd CS In-house)
  
  results:
  213.73.91.41

Conclusion:

some degree of wierdness, as most public DNS servers seem to redirect during the spoofability test, one can also expect the in-house DNS servers will 'do/need' some redirection?
Normal expected behaviour?

Note:
Using 74.121.182.147 and 167.88.9.30 as DNS servers:
http://ipleak.net/ now shows as DNS servers:
213.73.91.41
yesterday it showed: 23.226.227.93 and 23.226.227.94

which is in line with the spoofability tests outcome.

[marzametal]

Damn, someone's playing funny buggers...

[marzametal]

Fenrir Windows

New entries noticed...

dns2.jpg (10.86 KiB) Viewed 97405 times

I tried this out for 3 other exit nodes... they all showed the Berlin 213.x.x.x DNS address.
Also, the DNS entries in the command prompt didn't look like these ones... they included these two 194.150.168.168, 213.73.91.35 plus two others...

[Pattern_Juggled]

I've gone ahead and opened a new thread to continue discussion of in-house DNS resolvers, given that this beta-phase thread has pretty well served its purpose and it's a bit unwieldy to have it continue to sprawl out as we move towards full production status with the resolvers.

I'm not closing this thread, which feels a bit heavy-handed... perhaps there's ongoing discussion about stuff that's still suitable here? But it would seem logically congruent for most discussion to migrate to the new thread... right?

Also apologies for my laggy presence in this thread, in terms of official(-ish) team contributions. Having picked up something of a nasty winter flu-type thing quite a few days ago, I've been able to contribute to work to move the resolver project forward - or contribute to documenting what we've been doing, in this thread - but not both. So I kept what contribution level I could on the project itself, and pretty much absented myself from this thread meanwhile - without explanation. Which isn't terribly professional. I blame the flu, and absolve myself of substantive responsibility thereby

Also, the tl;dr is that the initial beta resolvers discussed in this thread did great for their beta requirements... but we cycled them a week or two ago, as we needed to develop a next iteration (including dnscurve and some other features; see the new thread, linked above). I took the liberty of redirecting the dnschain1.cryptostorm.net/dnschain2.cryptostorm.net hostnames to the public OKturtles resolvers... which, frighteningly enough to some folks, show up in "DNS leak test" (and other) queries as geographically located in Georgia, USA. So that wasn't very confidence-inspiring, and spooked folks - it should have been documented here, but per above I blame the flu. And also apologise for that.

And also remind that they had big, flashing "beta" tags on them, so that's at least something in terms of limiting our team commitment to proper documentation along the way.

Anyway, I am sure folks noticed the musical-chairs in terms of IP addresses located behind the hostnames - and there's the (better late than never) explanation. These resolver hostnames (dnschain1, dnschain2) are - per a post in the new thread - likely to end up being publicly-available, dnschain'd/dnscurv'd resolvers eventually... take a peek in the thread for details on that, and for the nomenclature regarding our proper, production, in-house DNS resolvers.

Cheers,

~ pj

ps:

here's the four resolvers we've been pushing down to on-cstorm network sessions for the past couple weeks - which will, in short order, be part of our github config publication process so changes to them can be confirmed realtime via that process. Basically, we pruned a couple of "dead" resolvers from the prior settings that had been pushed, and added in two dnschain'd resolvers meanwhile to keep some semblance of .bit capability in the interim. Which was a bit messy and imperfect, admittedly, but got us bridged along until we've been able to do our own in-house framework which will very shortly be the resolvers pushed from all nodes. Blah blah... sorry for the windy post!

Old ones (as of 15 January):

213.73.91.35 {ccc.de}
213.138.101.252 {dead}
80.237.196.2 {dead}
194.150.168.168 {dns.as250.net}


Newly-propagated pushed resolver settings, in server.conf's network-wide...

# okturtles .bit-enabled + dnschain-mapped DNS resolver (atlanta, georgia)
push "dhcp-option DNS 192.184.93.146"

# okturtles .bit-enabled + dnschain-mapped DNS resolver (atlanta, georgia)
push "dhcp-option DNS 54.85.5.167"

# ccc.de DNS resolver (berlin, germany)
push "dhcp-option DNS 213.73.91.35"

# foebud DNS resolver - j.mp/cs_dns - recommended by ccc.de (germany)
push "dhcp-option DNS 85.214.20.141"