I’ve been using this myself for a while and I’m really happy with it!
Not sure if I understand the difference. I’m assuming the IVPN app will have to be installed in order to enforce system-wide DNS interception?
This would be a very good differentiator between your product and NextDNS. At this point, it’s still not clear to me what the advantage of modDNS is. NextDNS is also very private, but development seems non-existent.
I agree, but NextDNS also has trust. Feature-wise, what does modDNS have that NextDNS doesn’t? Why should someone pick modDNS over NextDNS?
Q1 is almost over. I’m assuming any price changes will occur in Q2 at the earliest?
I know you can’t share too much details, but given what you have said, will existing IVPN users have access to Mailx and modDNS until their subscription renews? Or will they be asked to pay mid-subscription?
I’m assuming that a future tier including IVPN Pro, Mailx, and modDNS will be more expensive than IVPN Pro is today.
Please bear in mind this is a beta announcement. NextDNS has been in development for like 7 or 8 years. We did not promise we’ll launch this service with clear technical or feature differentiators. As mentioned above, we aim to get there but that takes time.
Trust is a personal thing. Many IVPN users are not doubt will feel more comfortable if we handled their DNS requests instead of NextDNS or ControlD. Further, modDNS is currently free to use and will stay free for IVPN Pro users. That’s another clear benefit. UI/UX is different, I think blocklist handling and custom rules additions are easier to manage, but that’s subjective.
If you are satisfied with NextNDS, have an established setup and you trust them, there is no good reason for you to switch to this service right now, and that’s OK.
As I understand RethinkDNS on Android is primarily a local firewall that enables per-app controls. My interpretation was @Encounter5729 assumed this is a similar product, while it’s closer to NextDNS and co. It depends on what you mean by “system-wide”. But no, you don’t need the IVPN app to use this product for processing all DNS requests on one device, there are setup instructions for popular OS’s.
Hi Victor, I’m sorry if you were offended by my post. I think it’s actually great that you’re launching modDNS. I guess I had this expectation that you were going to launch something that will blow NextDNS out of the water on day one. My bad. I feel like NextDNS has stagnated the last couple of years. It does work, so I guess I can’t complain there, and I do trust their product and yours too. Hopefully, it won’t take modDNS 7-8 years to catch up to NextDNS. I really would love if modDNS becomes a viable replacement for NextDNS.
On macOS, I’m under the impression that something like Little Snitch will need to be installed in order to force all system DNS queries to the DNS service of your choice, let’s say modDNS. So without Little Snitch, how do I ensure all macOS and app queries go through modDNS?
I’m trying it out at the moment. No major issues so far. A few minor quibbles, but I want to test it for longer before summing them up.
Has anyone conducted and latency/performance testing against other providers? I’d be particularly interested in testing it against other ad-blocking DNS resolvers and using DoH, DoT etc.
No offence taken, we appreciate the feedback.
Thanks for the note. We are running latency/performance testing internally from multiple residential locations and do monitoring for routing issues. Our current assessment is that the service is acceptable for day-to-day use, but there is a lot of room for improvement on this point. Feedback from users is very valuable at this point.
Two key things that affect performance:
- We have two PoP’s in the first stage of beta (Amsterdam and Toronto), we’ll be adding more during beta.
- We have identified Tier 1 routing issues where requests from NA are getting routed to Europe and vica versa. We are investigating solutions for this.
How do you plan to handle log policies and legal requests for services other than the VPN, like Mailx and modDNS?
With Mailx and modDNS, users can set things up so that they keep email and DNS logs. This is different from the VPN, which doesn’t do that.
So, I’m curious to know if log requests will be turned down in the same way as for the VPN, or if some logs or info might be shared depending on the situation.
The short answer is we handle requests in a way that fulfils legal requirements, but only to the extent absolutely necessary. These are not services run by anons in an offshore jurisdiction (as with IVPN). This does NOT mean that we flat out refuse requests for information, but we assess the validity and in most cases we can argue on them not being valid. You are right that IVPN is in a better position as we have absolutely zero logs to share on a specific customer or origin IP, even if we were to get a court order on usage data there would be none to share.
what we can do for Mailx and moddns:
- minimise data collection, eg. modDNS has all logs off by default, Mailx immediately deletes successfully delivered messages, etc. we detail these in the respective privacy policies. if you don’t enable logs in modDNS we only record which blocklists are enabled and total number of queries processed in aggregate (abuse mitigation). for Mailx your aliases are stored.
- severe the link between the IVPN account information and other services. this not only helps with compartmentalising potential data on usage, but results in no payment information on file for Mailx, modDNS accounts.
Love this idea as you have the perk of having customizable DNS without having to trust another party. Wish more VPNs would do this. Will this be exclusive to iVPN subscribers? Im mainly asking because this combined with Portmaster could be a really interesting workflow
Yes, for the foreseeable future. If you want to combine Portmaster with modDNS we are working on an IVPN suite plan that will include both (release date and details not finalised).
Hi @viktorivpn
Having reviewed the modDNS Privacy Policy policy, I have a few questions I would be grateful if you could address.
It is presently unclear whether modDNS operates under its own Terms & Conditions, or whether those of IVPN apply by extension. IVPN’s current Terms & Conditions make no reference to modDNS (or Mailx). Could you clarify whether modDNS will have its own Terms & Conditions, or whether IVPN’s will govern by extension?
Furthermore, under the section “What information is logged about DNS activity?”, paragraph (b), the policy sets out the data points logged, which include the timestamp of the query, the requested domain or IP address, the decision and its trigger, the client IP address, and the device identifier where configured.
The same paragraph confirms that users have full control over the retention period, which may be set between a minimum of one hour and a maximum of one month, with a default of one hour. It further confirms that any logs exceeding a newly configured timeframe are immediately deleted upon a change to that setting, and that users may permanently delete all stored query logs at any time via the dashboard.
However, the paragraph does not expressly state what occurs to logged data upon the expiry of the applicable retention period in the ordinary course, that is, absent any manual deletion or reconfiguration by the user. It can reasonably be inferred from the section “How do you respond to legal requests for data?” that logs are deleted at the end of the retention period; however, a consumer may not reasonably make such inference across separate sections of a policy that is, in all likelihood, incorporated into the contractual terms. I would be grateful if you could confirm if the Privacy Policy will be amended, prior to modDNS exiting beta, to state in plain terms that query logs are automatically and permanently deleted from your systems upon expiry of the user-configured retention period.
modDNS has its own ToS, IVPN one is not applicable:
Thanks for the request for clarification on the privacy policy, your note makes sense, we will review and modify as deemed necessary.