Subject: Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

From: Ray Bellis <[email-masked]>
Date: Fri, 26 Oct 2018 10:52:38 +0100

On 12/09/2018 18:57, Paul Hoffman wrote:

> Greetings again. One of the things that people said they wanted in 7706bis is more example configurations for different systems. We currently have:
> - BIND 9.9 with views
> ...
> I'll test BIND 9.10 with views to see if it's the same setup, and also more recent Unbound/NSDs.

BIND 9.9 and BIND 9.10 were both EOL as of July this year.

BIND 9.11 is the "ESV" version with an EOL date of July 2021.

(see the version table under the "BIND" drop down at
<https://www.isc.org/downloads/>)

The setup should be identical to the earlier versions, though.

That said - I want to take issue with the continuing focus on "same
host", even though the "running on loopback" restriction isn't there.

IMHO there's simply no need for this.  Even the largest ISP shouldn't
need more than a few local root zone servers, and it's an unnecessary
complication to shoe-horn those local copies onto the same host and/or
server as the recursive instance.

The document says "The primary goals of this design are to provide
faster negative responses to stub resolver queries that contain queries
that result in NXDOMAIN responses, and to prevent queries and responses
from being visible on the network".

IMHO, that second goal should be for those queries not to _leave_ the
network.

By all means describe how one _could_ run on the same host, but as a
whole I still find this document unnecessarily proscriptive.

I'd like to see examples of configurations where the local root copy
*isn't* on the same host.  This is, I believe, a potentially more useful
configuration and avoids the needs for nasty hacks like the use of
"views" to allow the recursor to perform DNSSEC validation.

Ray

---

From: "John Dickinson" <[email-masked]>
Date: Fri, 26 Oct 2018 11:32:39 +0100

On 26 Oct 2018, at 10:52, Ray Bellis wrote:

>> Greetings again. One of the things that people said they wanted in 
>> 7706bis is more example configurations for different systems. We 
>> currently have:
>> - BIND 9.9 with views
>> ...

I agree, there is no need to restrict the document to loopback and we 
should not be using examples that require non-standardised features like 
views.

John

> Ray
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: Tony Finch <[email-masked]>
Date: Fri, 26 Oct 2018 12:14:33 +0100

Ray Bellis <[email-masked]> wrote:
> *isn't* on the same host.

It's basically the same as the examples in RFC 7706, but you use the other
host's address instead of 127.12.12.12. RFC 7706 even says,

   The examples here use a loopback address of 127.12.12.12, but typical
   installations will use 127.0.0.1.  The different address is used in
   order to emphasize that the root server does not need to be on the
   device at "localhost".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Cyclonic 5 to 7, becoming northeast 6 to gale 8, perhaps severe gale 9
later. Moderate or rough, becoming rough or very rough. Rain then showers.
Poor becoming good.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 26 Oct 2018 12:33:23 +0100

On 26/10/2018 12:14, Tony Finch wrote:

> host's address instead of 127.12.12.12.
The BIND configuration becomes *much* simpler if you don't try to put
(validating) recursion and root zone copy into the same server.

You just need:

zone "." {
  type static-stub;
  server-addresses { x.x.x.x };
};

> RFC 7706 even says,

The 7706-bis text changes that to say:

   The examples here use a loopback address of 127.12.12.12, but typical
   installations will use 127.0.0.1.  The different address is used in
   order to emphasize that the root server does not need to be on the
   device at the name "localhost" which is often locally served as
   127.0.0.1.

My reading of this is that "the device" referred to is still "the local
device", not "a n other device".  I think the text is just trying to say
"just because it's on loopback doesn't require that it be *called*
localhost".

Ray

---

From: Joe Abley <[email-masked]>
Date: Fri, 26 Oct 2018 04:46:43 -0700

>   device at the name "localhost" which is often locally served as

Perhaps the pertinent question is why the word "loopback" features in
that text at all.

If the group thinks that a loopback interface is the right way to
connect local-root and resolver then perhaps provide that
recommendation explicitly with rationale. The general case surely does
not require the connecting network to be a loopback interface, and the
text you quoted could be interpreted as suggesting otherwise.

(The connecting network could be a bit of Internet, or a local switch,
or virtual switch between VMs, or something implementation-specific
between containers, or...)

I think it's probably reasonable to observe that there is a dependency
between the local root server and the resolver and that if the former
is not available to the latter there might be unexpected failures.
Orchestration of workloads to reflect that dependency is arguably
easier in some of those scenarios than others seems reasonable. I
still don't think there's any need to be prescriptive about the use of
a loopback interface.

I think the whole document could be reasonably re-cast to make it more
clear that "same server" is really just one example of the use of a
local root, and that many other scenarios are plausible.

Happy to contribute if the group considers this to be a reasonable
idea and not simply the dangerous ravings of a known lunatic.

Joe

---

From: Bjørn Mork <[email-masked]>
Date: Fri, 26 Oct 2018 13:57:48 +0200

>    order to emphasize that the root server does not need to be on the

This might be just me, but I find that paragraph very confusing.
127.12.12.12 is just as unroutable as 127.0.0.1, and must therefore
belong to the local host. And "localhost" as in the DNS name makes no
sense at all in this context.

When it comes to using 127.0.0.1 for this purpose, I believe you should
recommend some caution.  It's not uncommon to stick "nameserver
127.0.0.1" into the /etc/resolv.conf on recursive servers.  And many
admin fingers will automatically type "dig @127.0.0.1" when they want to
query the local server.  This will give unexpected results if you put a
non-recursive view on that address.

I'd also like to repeat my previous comment on the BIND example config:
Configuring a "static-stub" root zone has some unexpected consequences.
It makes the server refuse non-recursive queries for root instead of
redirecting.  Not a big problem, but it does make "dig +trace" fail with
such a server as starting point. It would be nice to see this issue
discussed in the RFC, including justification of the "static-stub" zone
type.  The reason for that choice is not obvious.  To me, at least.

Bjørn

---

From: Ray Bellis <[email-masked]>
Date: Fri, 26 Oct 2018 13:11:10 +0100

On 26/10/2018 12:57, Bjørn Mork wrote:

> I'd also like to repeat my previous comment on the BIND example
> config: Configuring a "static-stub" root zone has some unexpected
> consequences. It makes the server refuse non-recursive queries for
> root instead of redirecting.  Not a big problem, but it does make
> "dig +trace" fail with such a server as starting point.

Oh, so it does!

> It would be nice to see this issue discussed in the RFC, including
> justification of the "static-stub" zone type.  The reason for that
> choice is not obvious.  To me, at least.

>From my (admittedly limited) testing I don't think there's any other
BIND zone type that would work.

When I tried "type forward" it sent not just the root zone queries to
the specified server but *all* queries for all sub-domains thereof, too.

Ray

---

From: Tony Finch <[email-masked]>
Date: Fri, 26 Oct 2018 14:18:40 +0100

> > "dig +trace" fail with such a server as starting point.

The setup I have on my toy server uses `match-recursive-only` on the
recursive view, which avoids this problem. It has the side-effect that
RD=0 queries do not probe the cache, but I haven't noticed any problems
due to that. (But this server is only used by me so it doesn't get a wide
variety of weird traffic.)

> BIND zone type that would work. When I tried "type forward" it sent not
> just the root zone queries to the specified server but *all* queries for
> all sub-domains thereof, too.

A `forward` zone makes `named` act as a recursive client for that part of
the namespace, so if you point it at an authoritative server for that
zone, you won't get the right answer for any delegations or out-of-zone
CNAMEs.

A `stub` zone works kind of like root hints: `named` queries the
configured server for the zone's NS records, then uses those. So it can't
be used to redirect queries to an unofficial secondary.

Directly using a `slave` zone in the recursive view suppresses validation,
so it can't detect on-the-wire mangling in the way the `static-stub` setup
does.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: North 5 to 7, occasionally gale 8. Moderate or
rough. Squally showers, perhaps wintry later. Good occasionally moderate.

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2018 15:43:58 -0400

>   device at the name "localhost" which is often locally served as

The usual reason not to put the local root on 127.0.0.1 is that's
where the cache is.  Depending on the quirks of your system, you might
put the local root on another loopback address in 127/8. on a
different port on 127.0.0.1 (works fine in unbound/nsd, haven't tried
it on bind), or even port 53 or another port on a real interface and
firewall out external queries.

R's,
John