NextDNS Installer

[gattaca]

^^^ "Even the dry-run involves up to 10 requests per client which can be very significant when the entire release population updates."
That certainly could be part of the RCA on the churn and instability I've seen on what was a very reliable NextDNS setup.

I still especially do not like having to disable RR upstreams:0" Stubby, Encrypted DNS, covers all devices on the router's network automatically. Use the following in stubby.yml: round_robin_upstreams: 0 ....." Will see if things quiet down. I'll report back once I turn it back on manually. Peace.

 

[Delusion]

I have few questions:

1. How do I apply changes I made in the gui? run /jffs/nextdns/update or restart dnsnext or run configuration again ( c in the menu?) or changes in the gui applied automatically?

2. When I change something in the gui, there is no save button, do the changes saved automatically or I need to change the Configuration Name and click save , each time I change something?

3. How is NextDNS configured? DoH or DoT? if I want DoT what do I need to do? cause I see the port on router's log is 443 so I guess NextDNS configured to DoH and not DoT?

 

[maghuro]

I have few questions:

1. How do I apply changes I made in the gui? run /jffs/nextdns/update or restart dnsnext or run configuration again ( c in the menu?) or changes in the gui applied automatically?

2. When I change something in the gui, there is no save button, do the changes saved automatically or I need to change the Configuration Name and click save , each time I change something?

3. How is NextDNS configured? DoH or DoT? if I want DoT what do I need to do? cause I see the port on router's log is 443 so I guess NextDNS configured to DoH and not DoT?

1 and 2 - changes made on the website are automatically applied, no need to do anything nor press save anywhere.

3 - using nextdns Merlin client, you'll use DoH.
If you want to use DoT, disable the client and manually configure the DoT on Wan page on router.

 

[maghuro]

NextDNS just release the ca.cert which can be installed on devices so when using block page it won't throw ssl errors.

 

[dave14305]

NextDNS just release the ca.cert which can be installed on devices so when using block page it won't throw ssl errors.

How should we feel about this from a security perspective? It's voluntary to download, but should NextDNS users be trusting a third-party CA cert that hasn't been fully vetted? This is very different from the act of trusting a locally generated Pixelserv CA cert that never leaves our own LANs and is fully under our control. I wouldn't be an early adopter of this until the implications are fully thought through.

 

[SomeWhereOverTheRainBow]

How should we feel about this from a security perspective? It's voluntary to download, but should NextDNS users be trusting a third-party CA cert that hasn't been fully vetted? This is very different from the act of trusting a locally generated Pixelserv CA cert that never leaves our own LANs and is fully under our control. I wouldn't be an early adopter of this until the implications are fully thought through.

How do you feel about pixelserv-tls? I trust pixelserv-tls more than a remote CA

 

[dave14305]

How do you feel about pixelserv-tls? I trust pixelserv-tls more than a remote CA

I trust it because the CA is generated locally on my router, never leaves my network, and can be reset if necessary.

I don't think there's any intended harm from this move by NextDNS, but I think protecting this CA now becomes their most important job, security-wise. If a bad guy could compromise this CA, they could theoretically MITM any site they wanted for a NextDNS user who decides to trust this CA. "Here's a fresh cert for www.mybank.com signed by NextDNS. Trust me!"

I'm sure everything is both more and less complicated than I believe, but I think it deserves more thought about what is right.

 

[maghuro]

How should we feel about this from a security perspective? It's voluntary to download, but should NextDNS users be trusting a third-party CA cert that hasn't been fully vetted? This is very different from the act of trusting a locally generated Pixelserv CA cert that never leaves our own LANs and is fully under our control. I wouldn't be an early adopter of this until the implications are fully thought through.

From a totally noob perspective, can you please tell me what can be done with a non-trusted cert? Because I really don't know

 

[dave14305]

From a totally noob perspective, can you please tell me what can be done with a non-trusted cert? Because I really don't know

A non-trusted cert is not threatening because browsers will warn you about certs signed by an untrusted intermediate or root CA. If you agree to trust the NextDNS CA (and its 20 year validity), you are giving trust to ANY cert signed by NextDNS, whether related to a blocked domain or not. It’s not their intended purpose that is concerning to me; it’s the unintended consequences.

I’m not a web/security expert, and I’ve never run a web operation like Olivier and NextDNS have, so I’m not trying to be overly negative. It’s just a feature of my personality.

 

[gattaca]

^^^ Correct, that's why they implemented the shorter duration on certs so they expire and have to be replaced periodically too. Another security layer. Correct, a compromised cert opens the door to MIM attacks and a whole range of other issues. I'll have to think about this "block page" option. Personally, I like what pixelserv does...but I know it is really "as-is" whereas NextDNS has a business plan behind the service.

 

[RMerlin]

that's why they implemented the shorter duration on certs so they expire and have to be replaced periodically too. Another security layer.

There was an official industry-wide consultation on this last year. The vote was against a reduction of maximum certification duration, as the majority felt the hassle it would create exceeded any benefit it might bring. So Apple turned around, decided to reduce it ANYWAY in Safari, telling the rest of the industry a big "F U" when a democratic vote didn't go the way they wanted to. And now certificate emitters are forced to reduce the max duration anyway, despite the vote being against it.

Just another reason why I despise Apple as a company...

Certificates could always be revoked if they were compromised. There was no need for a duration reduction. All this does is increase the burden of support on system administrators who have to manage multiple sites, and now have to renew everything every year.

For instance, I manage a bit over 30 certificates for one of my customers. Some of these we were registering for 24 months. Now, these will need to be renewed every year instead.

 

[SomeWhereOverTheRainBow]

There was an official industry-wide consultation on this last year. The vote was against a reduction of maximum certification duration, as the majority felt the hassle it would create exceeded any benefit it might bring. So Apple turned around, decided to reduce it ANYWAY in Safari, telling the rest of the industry a big "F U" when a democratic vote didn't go the way they wanted to. And now certificate emitters are forced to reduce the max duration anyway, despite the vote being against it.

Just another reason why I despise Apple as a company...

Certificates could always be revoked if they were compromised. There was no need for a duration reduction. All this does is increase the burden of support on system administrators who have to manage multiple sites, and now have to renew everything every year.

For instance, I manage a bit over 30 certificates for one of my customers. Some of these we were registering for 24 months. Now, these will need to be renewed every year instead.

I am glad you and your clients could trust certificates for 24 months. It is nice to know the security will last that long. In my mind, I think a lot can happen in 24 months. Call me paranoid, but to me 24 months is too long. I'd settle for 6 months if they had it. The biggest issue I see customers facing is Cost associated with maintaining certificates shorter than 24 months; that is the biggest reason why the NAY vote was given. Remind you apple is not afraid to go after that wallet; that is why apple forces users to renew sooner. They have a financial interest.

 

[XIII]

Let's Encrypt uses even much shorter lifetimes: 90 days.

https://letsencrypt.org/2015/11/09/why-90-days.html

 

[SomeWhereOverTheRainBow]

Let's Encrypt uses even much shorter lifetimes: 90 days.

https://letsencrypt.org/2015/11/09/why-90-days.html

though i respect their humble response. I suspect a trusted certificate longer than 90 days may also require a financial backing of sorts as well.

 

[RMerlin]

It is nice to know the security will last that long.

Compromised certificates can simply be revoked.

Let's Encrypt uses even much shorter lifetimes: 90 days.

https://letsencrypt.org/2015/11/09/why-90-days.html

But Let's Encrypt relies on a fully automated system. That's not always possible with other providers.

 

[XIII]

[mention]Olivier Poitrey [/mention]Did you already watch the “Enable encrypted DNS“ WWDC20 session?

https://developer.apple.com/wwdc20/10047

No more fake VPN needed; both DoT & DoH natively supported in iOS 14!

 

[maghuro]

[mention]Olivier Poitrey [/mention]Did you already watch the “Enable encrypted DNS“ WWDC20 session?

https://developer.apple.com/wwdc20/10047

No more fake VPN needed; both DoT & DoH natively supported in iOS 14!

I wanted native DoH on Android

 

[Olivier Poitrey]

How should we feel about this from a security perspective? It's voluntary to download, but should NextDNS users be trusting a third-party CA cert that hasn't been fully vetted? This is very different from the act of trusting a locally generated Pixelserv CA cert that never leaves our own LANs and is fully under our control. I wouldn't be an early adopter of this until the implications are fully thought through.

As a sane person, you should feel worried. We really dislike this solution, but unfortunately there is no other way to show a blockpage over HTTPS. We implemented this feature with a lot of care tho:
* The root CA key is offline
* There is a revokable first level intermediary CA that is stored in a HSM and is not reachable from the edge servers
* This intermediary cert is used to create short lived CA that are stored on our edge servers
* Those edge CA are rotated every day with an expiration 1 day in the past, 4 days in the future

If one of our edge is compromised, we can quickly revoke the CA as soon as we notice. The key won't be usable for more than 4 days.

Still, if you don't feel comfortable — and I can understand — just don't use the feature, this is totally opt-in. We offer this option as a convenience.

 

[Olivier Poitrey]

[mention]Olivier Poitrey [/mention]Did you already watch the “Enable encrypted DNS“ WWDC20 session?

https://developer.apple.com/wwdc20/10047

No more fake VPN needed; both DoT & DoH natively supported in iOS 14!

Yes we did! That's great news.

 

[G313]

NextDNS 1.7.0 released.