So, if your link is saturated to the point that you can't hold up a VPN
connection reliably, you fall back to an less-secure method of resolution?
Non-deterministic security, what a concept!
Has it occurred to you, that you're giving the bad guys -- the ones that want
to pry on your query data -- an incentive to also partially DoS your link, as a
way to downgrade your query security?
-1 on this feature request.
- Kevin
-----Original Message-----
From: n...@eml.cc [mailto:n...@eml.cc]
Sent: Monday, August 24, 2015 2:19 PM
To: Darcy Kevin (FCA); bind-users@lists.isc.org
Subject: Re: BIND9 Feature Request: 'fowarders' priority & round-robin pools
Hi
On Mon, Aug 24, 2015, at 11:10 AM, Darcy Kevin (FCA) wrote:
> Forwarders are selected based on an RTT(round-trip-time)-based algorithm ....
There's an invalid presumption there -- that 'fastest' == 'most desired /
highest priority'. Regardless of any specific case, the requested feature
allows the user to say, simply, what goes where an when -- rather than having
to deal with auto-assumptions.
> Have you considered the option of not forwarding *at*all*?
No. And ...
> talking directly to the authoritative nameservers should allay the privacy
> concerns associated with talking through a third party....
Not entirely accurate IIUC.
The goal is to NOT allow any DNS traffic to traverse over my ISP connection in
unencrypted form -- unless it's the absolutely lowest priority (as I defined
it) fallback case.
For example in my current case,
class (1) traffic is over my VPN 'past' my ISP to my hosted resolver, then out
directly to the authoritative NSs
class (2) traffic is forwarded to/through a dnscrypt-proxy on my bind-instance
machine out to dnscrypt'd servers
class (3) traffic is the fallback case.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
