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 < [email protected]> 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@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 > >
