Cloud9 DNS

[Marin]

....and we are still not able to get OpenVPN to work while on IPv6 correct? Not sure if there had been any recent updates on this. I would imagine that there would be additional work to rework policy rules, etc.


Sent from my iPhone using Tapatalk

 

[Treadler]

Your ISP is doing the right thing. That looks like a performance problem on our side, adding 10ms of delay going through our peering router. (Note that the router itself is being particularly slow to respond to the traceroute, which is low-priority for it... if it were lightly-loaded, it would be responding quickly.) It's possible that this is something transitory, like a DDoS, or it's possible that the location is just very heavily loaded. I'll check into it. But your ISP is fine, they're handing off both Quad9 and Cloudflare on the same optimum path. This is our issue to resolve. I'll hand it off to ops now.

Many thanks for your kind attention, much appreciated!

 

[Bill Woodcock]

Quad9 has a faster idle timeout than cloudflare, so the Merlin default idle_timeout of 9000 ms is too long for Quad9 and results in conn_shuts, which isn't as graceful as Stubby closing the connection on the router end.

Sounds like a bunch of you are seeing the same issue there. I'll check with the ops guys and see what they say about it.

 

[Butterfly Bones]

....and we are still not able to get OpenVPN to work while on IPv6 correct? Not sure if there had been any recent updates on this. I would imagine that there would be additional work to rework policy rules, etc.


Sent from my iPhone using Tapatalk

I was searching how to do that as well. Turns out to be impossible.
https://www.snbforums.com/threads/asus-rt-ac86-u-no-ipv6-in-vpn-connection.56066/#post-480607

I spent hours trying to use IPV6 and VPN client, and all the IP leaks showed my VPN assigned IP. But geolocation always showed where I live and not the VPN exit point. I gave up on IPV6 for now and will stay with IPV4 until forced to change.

 

[Marin]

I was searching how to do that as well. Turns out to be impossible.
https://www.snbforums.com/threads/asus-rt-ac86-u-no-ipv6-in-vpn-connection.56066/#post-480607

I spent hours trying to use IPV6 and VPN client, and all the IP leaks showed my VPN assigned IP. But geolocation always showed where I live and not the VPN exit point. I gave up on IPV6 for now and will stay with IPV4 until forced to change.

That’s what I figured. Thank you!


Sent from my iPhone using Tapatalk

 

[dave14305]

Sounds like a bunch of you are seeing the same issue there. I'll check with the ops guys and see what they say about it.

I opened a support request on Friday asking about an ideal timeout value for idle DoT connections. Got a response today, but I don’t think we’re on the same page yet, so still pursuing it further.

 

[gattaca]

^^^ TY!

 

[Gar]

I thought I was seeing improved performance with IPv6 on Quad9 with DoT but now I'm getting lengthy lag in response. 9.9.9.9 is actually faster, not the other way around as I had expected. Also noticed I connect through Miami (from TX) and there are closer servers listed. Another work in progress.

 

[gattaca]

^^^ sounds like some of our ISPs, while they may "support" IPV6, are not really thoroughly optimizing it for their customers. That may be fair since my gut says, if I were a betting man, 98% of us "home guys" are using IPV4 IPs. I have absolutely no evidence to support that one!

 

[XIII]

I get so many timeouts (and even failing transactions/payments) with Quad9 that I have to revert to Cloudflare for now.

Hope to make a traceroute in the weekend or next week.

 

[bluepoint]

I thought I was seeing improved performance with IPv6 on Quad9 with DoT but now I'm getting lengthy lag in response. 9.9.9.9 is actually faster, not the other way around as I had expected. Also noticed I connect through Miami (from TX) and there are closer servers listed. Another work in progress.

Yesterday I tried Quad9 and same as you NYC is going through Miami.

 

[QuikSilver]

I get so many timeouts (and even failing transactions/payments) with Quad9 that I have to revert to Cloudflare for now.

Hope to make a traceroute in the weekend or next week.

When i do a tracerout I seem to get better performance from Cloudflare (ping time response) where as I get way more hops with google DNS (4 vs 10).

 

[Paliv]

I get so many timeouts (and even failing transactions/payments) with Quad9 that I have to revert to Cloudflare for now.

Hope to make a traceroute in the weekend or next week.

I came to the same conclusion. 1 in every 10 or so resolutions would end with an error, which was too much for my household to tolerate. Switched back to cloudflare for DoT.

 

[dave14305]

I really want Quad9 to work well with DoT and be a viable competitor to CloudFlare and Google, for reasons similar to why I use Firefox instead of Chrome or Edge. But in the end it needs to work reliably, like picking up the telephone receiver or turning on a lightswitch. Growing pains are forgivable, especially for a non-profit, but this is a very juicy opportunity for Quad9 to convert a whole bunch of DoT enthusiasts here.

 

[RMerlin]

I really want Quad9 to work well with DoT and be a viable competitor to CloudFlare and Google, for reasons similar to why I use Firefox instead of Chrome or Edge. But in the end it needs to work reliably, like picking up the telephone receiver or turning on a lightswitch. Growing pains are forgivable, especially for a non-profit, but this is a very juicy opportunity for Quad9 to convert a whole bunch of DoT enthusiasts here.

I know the Stubby devs wanted to figure out a better way to handle the timeouts than the current global value, but so far I don't think anything has concretized.

 

[PeterR]

Yesterday I tried Quad9 and same as you NYC is going through Miami.

You're lucky! A traceroute from here in Kuala Lumpur, Malaysia to dns.quad9.net goes via Japan to a host in California

 

[sfx2000]

@Bill Woodcock, @Ryan K (Cloudflare), @RMerlin, @john9527 (take care, only when you're able to reply, of course), @sfx2000, @ColinTaylor, @thelonelycoder, @Jack Yaz and all others who may be able to contribute, referring to post 64 above,

1) Is a caching resolver the same as the 'Wan: Use local caching DNS server as system resolver (default: No)' in the Tools/Other Settings page in the Advanced Tweaks and Hacks section of RMerlin powered routers?

2) What is QNAME minimization? How can this be implemented, if possible, on our routers today?

3) Link encryption. I think this is DoT? Am I close?

4) How important is it to 'compartmentalize DNS queries' and, do our routers do that for our devices now?

5) I think all of the above points to the goal of post 67 which states exactly as I hope I'm operating my network; "Minimize the amount you have to trust anyone else.".


These may be basic steps and concepts to some here. But I want to start on the bottom and thoroughly understand each step I am taking forward towards real online security.

Sorry to be late to respond - been pretty busy with things - because Startup, but that's a topic for other discussion

It's an interesting thread, and I've read thru it and a lot of good chat here.

1) Caching DNS - pretty much what DNSMasq can do out of the box, and it's helpful until the cache gets poisoned - this is what DNS over HTTPS and DNS over TLS tries to sort - and this is perhaps different that DNSSEC.

Anyways - I think the approaches are sound, and I've spoken before about DNSSEC and the IETF issues in the past - and consensus and healthy debate as to the advantages of TLS/HTTPS will eventually sort themselves out.

(as for me - I've deployed DNS over TLS using unbound as a local resolver for home use, just to see how it works, and I've tinker with the public providers to see how this works well with CDN/ADN providers, which EDNS and CDN is another discussion outside of this thread)

2) QNAME Minimization - best to read here to get a basic grasp...

https://www.isc.org/blogs/qname-minimization-and-privacy/

I'm using QNAME Minimization with unbound on pfSense, and here's their blurb on it...

Only send minimum required labels of the QNAME and set QTYPE to A when possible. Best effort approach; full QNAME and original QTYPE will be sent when upstream replies with a RCODE other than NOERROR, except when receiving NXDOMAIN from a DNSSEC signed zone. Default is off.
Refer to RFC 7816 for in-depth information on Query Name Minimization.
​

Challenge here is that things can break with upstream DNS...
So it's not an all or nothing - one can request the feature, and compliant DNS will support it...

3) Link Encryption - that's a pretty big question, and there one has to consider...

a) Are you looking to fully encrypt - which is not really practical, or
b) Want to ensure that the results are valid - and here's where DoH/DoT can help​

4) Not really sure what you mean or intend with the statement of "compartmentalize DNS queries" - so I'll reserve not to comment here

5) I agree - but with the caveat that Privacy and Security are two different things with DNS - some approaches try to solve one or the other, and since things are fairly active these days at the standards level, along with business interests, it's a bit complicated.​

Anyways - I'll prefer Security/Integrity over Privacy with DNS - I just want to ensure that the Lookup Results are valid, and this plays into my background in carrier scale networks along with device development.

For those providers that promise not to keep logs - that's a partial statement - and this is a tough problem for them - but thoughtful design can separate and anonymize the records/logs so that engineering decisions can be made for demand/capacity, along with balancing lookups to a loose geo area (consider CDN's for example) - and there, there's some hard decisions to be made as Govt agencies do have legal power in many countries to track behavior here.

I'm all for just getting efficient pipes working on the internet - and while privacy is important, just keeping security working is on ongoing challenge.

my 2 cents.

 

[sfx2000]

We also recommend against DNS-over-HTTPS, because while it's sufficient in theory, that wasn't what it was intended for in practice. HTTPS implementations are notoriously data-leaky, which means they're fingerprintable.

I wanted to single this one out specifically, as this is important - and not just for DNS.

There's folks that try, and often succeed, at running OVPN over the same ports, without realizing that it's a bad idea for the same reason you point out.

 

[sfx2000]

Anyways - I want to thank members here from the DNS providers for their contributions to the thread.

Goes to say, at least for me - if one is the smartest in the room, find another room - so there's folks here more qualified than me on DNS here.

So I'm happy to discuss and learn.

 

[coxhaus]

​

Anyways - I'll prefer Security/Integrity over Privacy with DNS - I just want to ensure that the Lookup Results are valid, and this plays into my background in carrier scale networks along with device development.

my 2 cents.

I think we are on the same page here. I want the lookup results to be correct also.