"chase DS servers" while setting up a Split-DNS-Server with static-stub

[Johannes Kastl]

Hi all,

I am trying to get more familiar with named/bind, and thus I am
experimenting a little. I am seeking for guidance in setting up a
split-dns server (aka resolving internal hosts that the outside does
not see and know about).

Host_1
I have bind running as caching resolver in my home dmz, only
accessible on the internal net. All DNS queries go through this one,
works like a charm, even with DNSSEC validation enabled.

Host_2
Then I set up another bind as master for my zone ojkastl.de, which has
all the internal hosts, that the external one does and should not
have. The hosts is set as NS in the SOA of the zone and has an A
record for itself in the zone. Querying this host directly with dig
+norecurse lets me resolve my internal hosts.

I added the following to my named.conf on Host_1, and it works.

-- snip --
zone "ojkastl.de" {
type static-stub;
server-addresses { 192.168.99.3; };
};
-- snip --

The only thing I notice are these lines in the logs:

Host_1
-- snip --
error (chase DS servers) resolving 'ojkastl.de/DS/IN': 192.168.99.3#53
-- snip --

Host_2
-- snip --
client 192.168.99.2#22059 (ojkastl.de): query (cache)
'ojkastl.de/DS/IN' denied
-- snip --

Is this actually something to worry about?

I guess that DS might be DNSSEC related, but apparently one cannot
disable dnssec validation for only one zone (or rather I could not get
it to work). And as this zone is not signed (yet) it might not matter.

When using a forward-type zone I got lots of additional NS records for
de (nic.de etc.) in my dig tests, so I tried the static stub.

Thanks in advance for your help!

Johannes

[Tony Finch]

Johannes Kastl <ma...@ojkastl.de> wrote:
>
> client 192.168.99.2#22059 (ojkastl.de): query (cache) 'ojkastl.de/DS/IN' denied
>

> Is this actually something to worry about?

It's annoying but benign. The recursive server is sending DS queries to
the wrong server, to the child zone's server (from the static-stub
configuration) rather than the parent zone's servers. However it recovers
from this mistake so everything works, apart from the wasted query.

(see also https://tools.ietf.org/html/rfc3658#section-2.2.1.2
for fun edge cases resolving DS records)

> When using a forward-type zone I got lots of additional NS records for
> de (nic.de etc.) in my dig tests, so I tried the static stub.

For a "forward" zone, BIND acts as a recursive client, and expects the
target server to be a recursive server. This mostly becomes important if
there are delegations from the zone.

For a static-stub zone, BIND is an iterative client as usual, so it
expects the target server to be an authoritative server. The static-stub
configuration in effect overrides the zone's NS records.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Fitzroy: Southerly or southwesterly 5 to 7 decreasing 3 or 4, occasionally 5
later in west. Moderate or rough. Rain or showers. Moderate or good.

[Johannes Kastl]

Hi Tony,

On 14.02.17 13:16 Tony Finch wrote:

> It's annoying but benign.

[nice explanation snipped]

Thanks for the confirmation, so it's nothing to worry about.

> For a "forward" zone, BIND acts as a recursive client, and expects
> the target server to be a recursive server. This mostly becomes
> important if there are delegations from the zone.

Nope.

> For a static-stub zone, BIND is an iterative client as usual, so
> it expects the target server to be an authoritative server. The
> static-stub configuration in effect overrides the zone's NS
> records.

It seems my choice of static-stub was not wrong in my case.

Thanks for the fast answer, Tony!

Johannes