<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Matthias.</p>
    <p>It isn't clear whether the issue you're trying to solve is (a)
      avoiding DNS resolution going out then in to get to your
      authoritative servers, or (b) with resolved addresses of your
      servers being the public address which means that data packets
      sent to/from those servers are going out then in to get to them?<br>
    </p>
    <p>It looks like Darren has assumed (a)? If that is correct then it
      is worth noting that using forwarders like this will require your
      authoritative servers to answer recursive queries. If that is
      undesirable, you might want to look at using "mirror" zones on
      your recursive resolvers? I haven't personally used zones of this
      type, but according to the documentation, this has following
      advantage over using "secondary" zones to achieve the same thing:
      <i>Answers coming from a mirror zone look almost exactly like
        answers
        from a zone of type </i><i><code class="docutils literal
          notranslate"><span class="pre">secondary</span></code></i><i>,
        with the notable exceptions that
        the AA bit (“authoritative answer”) is not set, and the AD bit
        (“authenticated data”) is.</i></p>
    <p>However I suspect your issue is actually (b), in which case I'd
      suggest using views to serve two versions of your zone file - one
      with public IP addresses that is served to external clients, and
      one with private IP addresses that is served to internal clients
      only, along the lines of the following:<br>
    </p>
    <pre># View containing zone with public IP addresses.
view "public" {
    match-clients { ... };

    zone "fechner.net" {
        type primary;
        file "../master/fechner.net/<b>public-</b>fechner.net";
        dnssec-policy "one-year-zsk";
        inline-signing yes;
    };
};

# View containing zone with private IP addresses.
view "private" {
    match-clients { ... };

    zone "fechner.net" {
        type primary;
        file "../master/fechner.net/<b>private-</b>fechner.net";
        dnssec-policy "one-year-zsk";
        inline-signing yes;
    };
};
</pre>
    <p>The two copies of the zone are signed using the same keys.<br>
    </p>
    <p>For the sake of simplicity I've glossed over the details of
      replicating the two different copies of the zone to your secondary
      DNS servers, but the general idea is to have the secondaries use
      different TSIG signatures for transferring each copy, and have the
      "match-clients" use the TSIG key to figure out which view they are
      talking to. Let me know if you need more info about how to set
      this up?<br>
    </p>
    <p>Nick.</p>
    <p><br>
    </p>
    On 6/02/23 01:08, Darren Ankney wrote:<br>
    <blockquote type="cite"
cite="mid:CAKabWHhvwJR3fVa-LLXVz9F8eSFz-nV12Cz6_=uRvfn33_HDVA@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Matthias,

This is what I did to force my resolver bind instance to lookup my
internal domain directly on my authoritative bind instance without
asking any other servers (would have failed anyway as it is a fake
domain "mylocal"):

// on resolver (or caching name server)
zone "mylocal" {
  type forward;
  forwarders {
    192.168.40.142; // authoritative server 1
    192.168.40.182; // authoritative server 2
  };
  forward only; // don't ask any other server
};

Not sure if that will break dnssec for you. There are probably other
way(s) to accomplish this, especially for a real domain on real IP
address(s). But maybe its somewhere to start.

-Darren

On Sun, Feb 5, 2023 at 1:21 AM Matthias Fechner <a class="moz-txt-link-rfc2396E" href="mailto:idefix@fechner.net"><idefix@fechner.net></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
Dear all,

I have a question regarding a setup I use at home.
It is for domain idefix.fechner.net.

I have at home a small server running with some services at it. As I do
not have a public IP, I tunnel traffic using pf on FreeBSD and openvpn
to route a public IP to my server at home.
This works nice but if I now access idefix.fechner.net it will always go
outside to the internet and then back through the tunnel to my local
server which is a real performance problem, as the internet connection
here is really slow.

The complete domain is dnssec signed using the following configuration:
zone "fechner.net" {
         type master;
         file "../master/fechner.net/fechner.net";
         dnssec-policy "one-year-zsk";
         inline-signing yes;
};

Now I want to make sure if I access idefix.fechner.net that it does not
use the tunnel but access it directly using the local address.

So the idea was to configure my named running at home to resolve some
host names differently.

What is here recommended best practice doing it?

Just added a new domain fechner.net and overwrite some A records? I
think that will break dnssec or?

Thanks for any pointer into the right direction.

Gruß
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

--
Visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.


bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
      </blockquote>
    </blockquote>
  </body>
</html>