Multiple names for each forward zone?

[manu tman]

Hi Casper,

Why not using a script to generate your config at that point?

Manu

On Fri, Feb 1, 2019 at 10:55 PM Casper Ti. Vector via Unbound-users <
unbound-users at nlnetlabs.nl> wrote:

> On my machine, I use dnscrypt-proxy (let's suppose it listens on
> 127.0.0.1:1153) for most DNS queries; in order to avoid slow CDNs
> returned by the dnscrypt servers, certain domains are resolved using
> regular unencrypted DNS.  The unbound setup I want in the first place
> would be something like:
>
> ========================================================================
> server:
>     port: 53
>     do-not-query-localhost: no
>
> forward-zone:
>     name: "cdn.example.com"
>     name: "cdn.example.org"
>     forward-addr: 1.2.3.4
>
> forward-zone:
>     name: "."
>     forward-addr: 127.0.0.1 at 1153
> ========================================================================
>
> However, since unbound.conf(5) allows only one `name:' directive for
> each forward zone, the example configuration above is clearly invalid,
> and I need to replace the first `forward-zone:' clause with:
>
> ========================================================================
> forward-zone:
>     name: "cdn.example.com"
>     forward-addr: 1.2.3.4
>
> forward-zone:
>     name: "cdn.example.org"
>     forward-addr: 1.2.3.4
> ========================================================================
>
> ... which quickly becomes inconvenient with the growth in the number of
> CDN-related domain names, and especially with older dnscrypt-proxy
> versions which did not support failover (so multiple forward addresses
> needed to be specified for each of these zones).  My current solution is
> to use dnsmasq for 127.0.0.1:53, which relays DNS queries to two unbound
> instances listening on 127.0.0.1:1053 and 127.0.0.1:1054:
>
> ========================================================================
> server=127.0.0.1#1053
> server=/cdn.example.com/127.0.0.1#1054
> server=/cdn.example.org/127.0.0.1#1054
> ========================================================================
>
> My questions are:
> * Is there a simpler way to implement my requirements, that does not
>   involve dnsmasq or multiple unbound instances?
> * If the current answer to the previous question is "no", may I propose
>   to let unbound allow multiple names for each forward zone?
>
> From my limited understanding of unbound, the proposed interface change
> seems to be quite backward compatible:
> * (As shown above,) in a naive implementation, all necessary for the
>   feature is just a "macro expansion" that transforms each forward zone
>   with multiple names into multiple "regular" zones, so old
>   configurations are guaranteed not to be broken.
> * The naive approach might be inefficient due to unnecessary duplication
>   in configuration for the zones, and an obvious improvement is to let
>   the generated zones to "point to" some shared data structure that
>   represent the configuration; however, this is just an implementation
>   detail, and has virtually zero impact on the backward compatibility.
>
> --
> My current OpenPGP key:
> RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
> 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190202/aa1440cb/attachment.htm>