<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 23/12/2022 2:30 am, Jesus Cea wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1ff54843-c846-ca3c-dd0e-c8f4defe4224@jcea.es">Is there
      any way to configure bind to verify DNSSEC integrity and signal
      the AD flag for authoritative domains?. Views (it would lose the
      AA flag, then)?
      <br>
      <br>
      What would be the best practice for dnssec verification? To use a
      fully validating local resolver? Any other choice? I am currently
      using a local "bind" as a resolver and it works fine for DNSSEC
      verification, except for my authoritative domains.
    </blockquote>
    <p>Yes you can use views to effectively separate the concerns of the
      recursive resolver function from the authoritative server, without
      having to deploy extra servers. For example:</p>
    <pre>view "resolver" {
        # Match criteria
        match-clients { ... };
        match-recursive-only yes;

        zone "example.com" {
                type static-stub;
                server-addresses { ::1; };
        };

        include "/etc/bind/named.conf.default-zones";
};

view "authority" {
        # View settings
        empty-zones-enable no;
        recursion no;
        allow-recursion { none; };
        rate-limit {
                responses-per-second 5;
                window 5;
        };

        zone "example.com" {
            ...
        };
};
</pre>
    <p>The idea here is that a recursive query (received from an
      'internal' address covered by the match-clients criteria) will be
      handled by the <i>resolver</i> view, which will use the
      static-stub zone to query (via loopback address) the <i>authority</i>
      view, which is authoritative for the example.com zone. Provided
      the answer from the <i>authority</i> view is DNSSEC signed and
      the <i>resolver</i> view can successfully validate the signature,
      then the answer returned by the <i>resolver</i> view to the
      original client performing the recursive query includes the AD
      flag (but not the AA flag).</p>
    <p>It could actually work without the static-stub zone, but I prefer
      to keep this to stop the <i>resolver</i> view from sending the
      queries to a different (authoritative) server.<br>
    </p>
    <p>Nick.<br>
    </p>
  </body>
</html>