BIND9 Feature Request: 'fowarders' priority & round-robin pools

[nr...@eml.cc]

I run bind 9.10.2-P3.

I have three classes of forwarders that I'd like to use:

(1) my own, hosted forwarder. fast & private, but not redundant infrastructure
(2) private/encrypted hosted forwarders. slow, private, and redundant infrastructure.
(3) reliable ISP & public forwarders. fast, redundant, privacy-challenged (Google, OpenDNS, AT&T, etc).

Reading the Arm & chatting in #irc IIUC 'forwarders' are NOT queried in order listed, and there's no option to set priority, failover, round-robin etc.

I'm requesting such a feature.

For example,

Forwaders would be queried in order of priority, and pools of multiple forwarders would be round-robin weighted within a given priority level.

So in conf, we could have

forward only;
forwarders { 11.11.11.11 port 11111 prio 1; 22.22.22.1 port 53 prio 2; 22.22.22.2 port 53 prio 2; 8.8.8.8 prio 3; 8.8.4.4 prio 3; };

Thanks!

[Darcy Kevin (FCA)]

Forwarders are selected based on an RTT(round-trip-time)-based algorithm, so none of this configuration complexity should be necessary from a performance/availability standpoint. The algorithm will choose faster forwarders over slower ones, and penalization/eventual-redemption of failed/non-responding forwarders is built into the algorithm. It's similar to the NS-selection algorithm; in fact, it might be a common server-selection routine that handles both situations.

Have you considered the option of not forwarding *at*all*? If your BIND instances have direct access to the Internet DNS, then forwarding isn't usually a good choice anyway. As a side benefit, talking directly to the authoritative nameservers should allay the privacy concerns associated with talking through a third party.

- Kevin

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[nr...@eml.cc]

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.

[Reindl Harald]

and you gain what?

one of your forwarding resolvers needs to do recursion an dguess what
it's unencrypted - and even if you prefer 1) for whatever reasons
(instead change to a ISP you trust) why not just make that VPN
connection relieable and fault tolerant instead abuse named?

[Darcy Kevin (FCA)]

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: nr...@eml.cc [mailto:nr...@eml.cc]
Sent: Monday, August 24, 2015 2:19 PM
To: Darcy Kevin (FCA); bind-...@lists.isc.org
Subject: Re: BIND9 Feature Request: 'fowarders' priority & round-robin pools

Hi

[nr...@eml.cc]

On Mon, Aug 24, 2015, at 11:56 AM, Darcy Kevin (FCA) wrote:
> 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?

No.

> Non-deterministic security, what a concept!

Didn't take long for you to resort to childish snark to did it?

> 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?

No, because I prefer not to waste my time with hypothetical/idle speculation.

> -1 on this feature request.

I don't know who you are. Is that an opinion, or a project decision?

[Alan Clegg]

On 8/24/15 3:09 PM, nr...@eml.cc wrote:
>
>
> On Mon, Aug 24, 2015, at 11:56 AM, Darcy Kevin (FCA) wrote:
>> 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?
>
> No.

Actually, "yes". That's pretty much exactly what you are doing.

>
>> Non-deterministic security, what a concept!
>
> Didn't take long for you to resort to childish snark to did it?

If "what a concept" is snark, then I'm one of the snarkiest people in
the world. However, he's pointing out a problem with your configuration.

>> 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?
>
> No, because I prefer not to waste my time with hypothetical/idle speculation.

Unfortunately, security has a lot to do with figuring out the weak
points in a configuration - that which you call "hypothetical/idle
speculation". Not good.

>> -1 on this feature request.
>
> I don't know who you are. Is that an opinion, or a project decision?

I'm with Kevin on this one. -1 on this feature request.

AlanC
--
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.

[Reindl Harald]

Am 24.08.2015 um 21:09 schrieb nr...@eml.cc:
>
>
> On Mon, Aug 24, 2015, at 11:56 AM, Darcy Kevin (FCA) wrote:
>> 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?
>
> No.

YES but you maybe don't realize the impact of your idea

>> Non-deterministic security, what a concept!
>
> Didn't take long for you to resort to childish snark to did it?

not more childish than your feature request nobody ever would setup that way

>> 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?
>
> No, because I prefer not to waste my time with hypothetical/idle speculation.

why then the original post at all instead fix the root cause?

>> -1 on this feature request.
>
> I don't know who you are. Is that an opinion, or a project decision?

an opinion

[nr...@eml.cc]

Somehow all that ^ puffery translates into NOT wanting to allow the user to prioritize the use of forwarders the way they want?

Um, ok ...

[Alan Clegg]

On 8/24/15 3:21 PM, nr...@eml.cc wrote:
> Somehow all that ^ puffery translates into NOT wanting to allow the
> user to prioritize the use of forwarders the way they want?

You are trying to use forwarders in a way that they are not intended,
and is not a good idea. That is the translation of all of the responses
to this point.

All puffery aside.

[Darcy Kevin (FCA)]

I believe you could implement what you're looking for with a reasonably-sophisticated software/hardware load-balancer technology and/or some number of virtual machines, no BIND code changes required.

Personally, I don't like forwarding much at all -- I only use it where it's absolutely necessary, due to the presence of a multi-tiers-of-security network topology -- so this whole discussion pretty much falls into my "trying to teach a pig to sing" category. Feel free to ignore any or all of my comments in the thread.

- Kevin

-----Original Message-----
From: bind-user...@lists.isc.org [mailto:bind-user...@lists.isc.org] On Behalf Of nr...@eml.cc
Sent: Monday, August 24, 2015 3:21 PM
To: bind-...@lists.isc.org
Subject: Re: BIND9 Feature Request: 'fowarders' priority & round-robin pools

Somehow all that ^ puffery translates into NOT wanting to allow the user to prioritize the use of forwarders the way they want?

Um, ok ...

[Mark Andrews]

Additional,
BIND is open source so you are free to modify it to see if doing
so helps you.

The forwarders are sorted in lib/dns/resolver.c.
The grammer is defined in lib/isccfg/namedconf.c
The forward table is constructed using the routines in lib/dns/forward.c
which are called from bin/named/server.c

This should be encough to get a C developer started.

Mark

In message <2473e4d01ffe46f9...@mxph4chrw.fgremc.it>, "Darcy Kevin

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org