<div dir="ltr">Hi Casper,<br><br>Why not using a script to generate your config at that point?<br><div><br>Manu</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 10:55 PM Casper Ti. Vector via Unbound-users <<a href="mailto:unbound-users@nlnetlabs.nl">unbound-users@nlnetlabs.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On my machine, I use dnscrypt-proxy (let's suppose it listens on<br>
<a href="http://127.0.0.1:1153" rel="noreferrer" target="_blank">127.0.0.1:1153</a>) for most DNS queries; in order to avoid slow CDNs<br>
returned by the dnscrypt servers, certain domains are resolved using<br>
regular unencrypted DNS.  The unbound setup I want in the first place<br>
would be something like:<br>
<br>
========================================================================<br>
server:<br>
    port: 53<br>
    do-not-query-localhost: no<br>
<br>
forward-zone:<br>
    name: "<a href="http://cdn.example.com" rel="noreferrer" target="_blank">cdn.example.com</a>"<br>
    name: "<a href="http://cdn.example.org" rel="noreferrer" target="_blank">cdn.example.org</a>"<br>
    forward-addr: 1.2.3.4<br>
<br>
forward-zone:<br>
    name: "."<br>
    forward-addr: 127.0.0.1@1153<br>
========================================================================<br>
<br>
However, since unbound.conf(5) allows only one `name:' directive for<br>
each forward zone, the example configuration above is clearly invalid,<br>
and I need to replace the first `forward-zone:' clause with:<br>
<br>
========================================================================<br>
forward-zone:<br>
    name: "<a href="http://cdn.example.com" rel="noreferrer" target="_blank">cdn.example.com</a>"<br>
    forward-addr: 1.2.3.4<br>
<br>
forward-zone:<br>
    name: "<a href="http://cdn.example.org" rel="noreferrer" target="_blank">cdn.example.org</a>"<br>
    forward-addr: 1.2.3.4<br>
========================================================================<br>
<br>
... which quickly becomes inconvenient with the growth in the number of<br>
CDN-related domain names, and especially with older dnscrypt-proxy<br>
versions which did not support failover (so multiple forward addresses<br>
needed to be specified for each of these zones).  My current solution is<br>
to use dnsmasq for <a href="http://127.0.0.1:53" rel="noreferrer" target="_blank">127.0.0.1:53</a>, which relays DNS queries to two unbound<br>
instances listening on <a href="http://127.0.0.1:1053" rel="noreferrer" target="_blank">127.0.0.1:1053</a> and <a href="http://127.0.0.1:1054" rel="noreferrer" target="_blank">127.0.0.1:1054</a>:<br>
<br>
========================================================================<br>
server=127.0.0.1#1053<br>
server=/<a href="http://cdn.example.com/127.0.0.1#1054" rel="noreferrer" target="_blank">cdn.example.com/127.0.0.1#1054</a><br>
server=/<a href="http://cdn.example.org/127.0.0.1#1054" rel="noreferrer" target="_blank">cdn.example.org/127.0.0.1#1054</a><br>
========================================================================<br>
<br>
My questions are:<br>
* Is there a simpler way to implement my requirements, that does not<br>
  involve dnsmasq or multiple unbound instances?<br>
* If the current answer to the previous question is "no", may I propose<br>
  to let unbound allow multiple names for each forward zone?<br>
<br>
>From my limited understanding of unbound, the proposed interface change<br>
seems to be quite backward compatible:<br>
* (As shown above,) in a naive implementation, all necessary for the<br>
  feature is just a "macro expansion" that transforms each forward zone<br>
  with multiple names into multiple "regular" zones, so old<br>
  configurations are guaranteed not to be broken.<br>
* The naive approach might be inefficient due to unnecessary duplication<br>
  in configuration for the zones, and an obvious improvement is to let<br>
  the generated zones to "point to" some shared data structure that<br>
  represent the configuration; however, this is just an implementation<br>
  detail, and has virtually zero impact on the backward compatibility.<br>
<br>
-- <br>
My current OpenPGP key:<br>
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)<br>
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C<br>
<br>
</blockquote></div>