Subject: [DNSOP] Call for Adoption: draft-kh-dnsop-7706bis

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Jul 2018 12:33:31 -0400

We discussed this and there appears to be support to adopt this, with
the caveat of fleshing out some of the discussions which came up.

This starts a Call for Adoption for draft-kh-dnsop-7706bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 9 August 2018

Thanks,
tim wicinski
DNSOP co-chair

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Jul 2018 13:35:47 -0400 (EDT)

On Tue, 24 Jul 2018, Tim Wicinski wrote:

> The draft is available here: https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/

While I agree with the goal of the draft, to keep root server queries on
the local host, I don't like how it is suggesting to run a DNS server on
localhost:53, because that is going to cause problems with running
validating resolvers on the stub. There is already enough racy
conditions on systems with virtual machines and running dhcp/dns servers
for those that are racing to own 127.0.0.1:53

But again, having a well integrated method for slaving the root zone on
a local validating stub resolver is something that everyone should do
(along with query minimalization)

Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2018 14:17:26 -0400

Can you unpack that a bit, Paul?   What's the scenario where this is a
problem?   Not disagreeing, just not seeing it.

On Tue, Jul 24, 2018 at 1:35 PM, Paul Wouters <[email-masked]> wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2018 17:08:22 -0400

In article <[email-masked]> you write:
>localhost:53

That seems easy enough to fix, move it to another address in 127/8 or
a different port.  I agree that there's a lot of software that expects
to find a local DNS cache on localhost:53 so it's not a good place to
put something else.

R's,
John

PS: I agree with the call for adoption.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 24 Jul 2018 17:08:16 -0700

> for those that are racing to own 127.0.0.1:53

If you find a place where the draft is suggesting that, please let us 
know: it should not be doing that. That's why the draft explicitly 
states:

. . .
    2.  Start the authoritative server with the root zone on an address
        on the host that is not in use.  For IPv4, this could be
        127.0.0.1, but if that address is in use, any address in 127/8 
is
        acceptable.  For IPv6, this would be ::1.
. . .
    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.
. . .

> (along with query minimalization)

Hopefully, that's a recommendation for adoption of the draft.

--Paul Hoffman

---

From: Petr Špaček <[email-masked]>
Date: Wed, 25 Jul 2018 09:12:58 +0200

> This starts a Call for Adoption for draft-kh-dnsop-7706bis

I support adoption with caveat that it should allow also other ways to
implement this.

E.g. Knot Resolver literally imports (validated) root zone data into
local cache so it does not provide any 'authoritative' server reachable
from outside. If refresh/reimport does not go well the data in cache
will just expire as usual (... and then you have opportunity to use
serve-stale :-).

Petr Špaček  @  CZ.NIC