Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-root-loopback-01.txt

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Nov 2014 08:21:29 -1000

Greetings again. Based on some great input from Evan Hunt, we have updated our draft. The algorithm is both simpler and easier to configure. In fact, we have examples of how to configure BIND and Unbound/NSD to match the new spec.

We'll be talking about the new draft in today's meeting.

--Paul Hoffman

> Name:		draft-wkumari-dnsop-root-loopback
> Revision:	01
> Title:		Decreasing Access Time to Root Servers by Running One on Loopback
> Document date:	2014-11-11
> Group:		Individual Submission
> Pages:		7
> URL:            http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-root-loopback-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-wkumari-dnsop-root-loopback/
> Htmlized:       http://tools.ietf.org/html/draft-wkumari-dnsop-root-loopback-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-root-loopback-01
> 
> Abstract:
>   Some DNS recursive resolvers have longer-than-desired round trip
>   times to the closest DNS root server.  Such resolvers can greatly
>   decrease the round trip time by running a copy of the full root zone
>   on a loopback address (such as 127.0.0.1).  This document shows how
>   to start and maintain such a copy of the root zone in a manner that
>   is secure for the operator of the recursive resolver and does not
>   pose a threat to other users of the DNS.

---

From: Bob Harold <[email-masked]>
Date: Tue, 11 Nov 2014 13:51:25 -0500

This sounded good until "Note that using this configuration will cause the
recursive resolver to fail if the local root zone server fails."  Could I
use "forward first" instead of "static-stub" so that it would fall back to
the normal root servers if the local root server could not get zone
transfers or had some other error?

-- 
Bob Harold
University of Michigan

> Htmlized:
> http://tools.ietf.org/html/draft-wkumari-dnsop-root-loopback-01
>

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Nov 2014 19:15:29 +0000

> transfers or had some other error?

In the case of BIND, the sample configuration has the root server built in
to the recursive server (it's a separate view, but not a separate process),
so if the root server dies, then the recursive server is also dead.  A
simple nanny script can restart it if this happens.

This might be a larger concern with the sample NSD/Unbound configuration,
in which there are two separate server processes that don't necessarily
share fates.  However, it may be possible to set up the stub zone in
Unbound so that it tries localhost first, and fails over to traditional
root servers if that doesn't work.  (I know you can list multiple server
addresses, but I don't know whether Unbound favors the first one or
round-robins the lot of them.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Bob Harold <[email-masked]>
Date: Tue, 11 Nov 2014 14:43:02 -0500

On Tue, Nov 11, 2014 at 2:15 PM, Evan Hunt <[email-masked]> wrote:

> Thanks, but what about the case where the zone transfers are refused and
the root zone expires?  My server is still running, but cannot answer for
the root zone.  That's a case where I want it to fail over to the real
roots.

-- 
Bob Harold
University of Michigan

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Nov 2014 21:07:18 +0000

Paul Hoffman <[email-masked]> wrote:

> Greetings again. Based on some great input from Evan Hunt, we have
> updated our draft. The algorithm is both simpler and easier to
> configure. In fact, we have examples of how to configure BIND and
> Unbound/NSD to match the new spec.

I have been running with a similar config on my toy nameserver for nearly
a year, and it is reasonably satisfactory. I have not really exercised its
failure modes. Previously I just slaved the root zone without validating
it.

I thought the idea of validating the zone transfer before putting the zone
live was interesting. I could probably lash up a script to do that along
the lines of the following, though it also needs to check the KSK matches
the trust anchor.

for server in $root_servers
do if dig axfr . @$server >root.db &&
      dnssec-verify -o . root.db
   then nsdiff -s localhost . root.db | nsupdate -l
        exit $?
   fi
done

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire: Easterly or southeasterly 5 to 7, occasionally gale 8 in south.
Moderate becoming rough. Showers later. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Nov 2014 11:48:10 -1000

On Nov 11, 2014, at 11:07 AM, Tony Finch <[email-masked]> wrote:
> a year,

That makes me feel better about our assertion that we probably did not invent this.

> and it is reasonably satisfactory.

That makes me feel better in general. :-)

> I have not really exercised its

Sure, but this is an unnecessary change to what recursives do today, which is to validate each response. It feels better to keep as much as we can from the current methodology.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Nov 2014 22:34:22 +0000

Paul Hoffman <[email-masked]> wrote:
> Sure, but this is an unnecessary change to what recursives do today,
> which is to validate each response. It feels better to keep as much as
> we can from the current methodology.

On the other hand, something vaguely like that kind of validation is often
part of a high-assurance authoritative DNS setup. And I was suggesting a
shonky way to add that validation to the authoritative side of the local
root server, leaving the recursive side relatively normal.

The problem with slaving the root zone locally is that you damage the
DNS's and DNSSEC's resilience features. Since you can't TSIG-authenticate
the zone transfers I think you really need some other kind of sanity
check, if you are going to recommend local root zones as a standard
configuration. (as opposed to an experiment on a hostmaster's
workstation.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay, Fitzroy: Westerly or southwesterly 6 to gale 8. Moderate at
first in southeast Biscay, otherwise rough or very rough, occasionally high in
Fitzroy. Thundery showers. Good, occasionally poor.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Nov 2014 23:28:22 +0000

> the root zone.  That's a case where I want it to fail over to the real

If the slave zone expires, it's because your server isn't receiving
transfers from *any* of the five root servers in the masters statement,
and in that situation you'd be having troubles whether you used this
configuration or not.

I suppose some of the five might disable transfers while continuing to
allow queries... but as long as one of them still supports transfers,
you'd be okay. I'm confident that f-root, operated by ISC, will always
support them.

(Honestly, I don't know why it isn't a requirement for all the root
ops. It's not like the zone contents are a secret.)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Nov 2014 22:02:17 -0800

> Tony Finch <mailto:[email-masked]>
> Tuesday, November 11, 2014 1:07 PM
>
> ...
>
> live was interesting.

this is something deliberately left out of the dnssec design, because it
doesn't obviate validation by query initiators of the underlying data.
in this case the query initiator will be the rdns coupled to this
stealth slave, which MUST do rfc 5011 key rolls and full dnssec
validation, no matter whether the root zone is checked after each transfer.

given that adding logic to a crypto system usually makes it less safe
not more safe, we'd need a compelling reason to recommend validation.
especially since it would have to be redone after each IXFR, and
especially since the full zone might be arbitrarily large (that is, the
root zone isn't the only one that can benefit from this kind of
hot-cache inside the RDNS itself.)

i am therefore strongly -1 to any kind of validation of transferred
contents. transfers, like the lack of signatures on delegation NS
RRsets, are deliberately outside the design envelope for secure dns.
let's not add stuff like this just because it's possible or interesting.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Nov 2014 10:05:59 +0000

> doesn't obviate validation by query initiators of the underlying data.

Right, but DNSSEC usually assumes that the zone transfers themselves are
authenticated, so they can't be corrupted in transit. This is not the
case for local root zones.

With normal DNSSEC validation, resolvers have a way to recover from data
corruption. With this local root zone proposal they do not.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Viking: Southeasterly 7 to severe gale 9. Very rough. Occasional
rain. Moderate or good.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Nov 2014 06:52:10 -0800

> Wednesday, November 12, 2014 2:05 AM
>
> authenticated, so they can't be corrupted in transit.

no.

> This is not the case for local root zones.

it's not the case, period. the root zone happens to be transferred using
TSIG keys between the verisign distribution servers and the root
publication servers. but for most dnssec-secured zones there is no TSIG.
data tampering is handled downstream, when queries are received from the
possibly-tampered zone.
> corruption. With this local root zone proposal they do not.

i seem to have missed a step. why? an RDNS which has been programmed to
forward root queries to a stealth name server running on the loopback,
and is set up with rfc 5011 key roll, and DNSSEC validation. in BIND9,
unsecured data as well as wrongly signed data received at this RDNS from
the loopback-stealth server will be rejected. so, axfr-level tampering
will be ineffective, other than creating a denial-of-service problem for
that RDNS. i see no difference in recovery between the status quo vs.
the kumari/hoffman proposal, except that in BIND9 we'd probably want the
"forward first" logic.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Nov 2014 15:13:13 +0000

> publication servers. but for most dnssec-secured zones there is no TSIG.

That surprises me.

> i seem to have missed a step. why?

If a validating resolver gets a bogus answer it will retry the query on
another server. With a local root zone you are disabling this fallback.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy, Sole: Westerly 6 to gale 8 backing southerly or southwesterly 7 to
severe gale 9, perhaps storm 10 later in east Sole. Rough or very rough. Rain
or thundery showers. Moderate or poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Nov 2014 07:19:12 -0800

> Wednesday, November 12, 2014 7:13 AM

that's either an argument for listing multiple servers, the first being
on the loopback, the other(s) being real global root name servers; or,
instead of telling bind9 "forward only", tell it "forward first".

the other thread on this draft reached a similar end when considering
what happens when the zone times out. these are just different forms of
data-unavailablility, which can *always* be forced.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Nov 2014 15:30:08 +0000

Paul Vixie <[email-masked]> wrote:
> on the loopback, the other(s) being real global root name servers;

That would probably work.

> or, instead of telling bind9 "forward only", tell it "forward first".

That would not work: you can't forward to an authoritative server.

> data-unavailablility, which can *always* be forced.

Right, but can you recover from data-unavailability without user
intervention? What if the local copy of the zone is corrupted rather
than just stale?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight: Southeast 5 or 6 veering south 4. Rough at first in northwest,
otherwise slight or moderate. Showers. Good, occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Nov 2014 07:35:26 -0800

> Wednesday, November 12, 2014 7:30 AM

um. "type forward" is a possible zone type in bind9. we do it when we
deliver DNS RBL policy zones. i was not talking about the kind of
forwarding used for recursive service.

> intervention? What if the local copy of the zone is corrupted rather

i do not know the recommended behaviour if one of the servers for a zone
is giving unsigned or wrongsigned answers. i do think that "servers for
the zone" should be interpreted as "statically configured, if it's a
type=forward zone in bind9". and i do think that the recommended
behaviour is, "treat it as servfail, in other words, try the next server
for the zone." my bet is, none of that is well specified and none of
those recommendations are written down anywhere even if they represent
consensus.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Nov 2014 16:07:27 +0000

> forwarding used for recursive service.

Yes, I know that. "type forward" does not work if the server you are
forwarding to is authoritative-only and if the zone has delegations. The
resolver that is forwarding sends recursive queries and gets upset if the
authoritative server sends a referral. Type forward will mostly work for a
leaf zone (such as a DNSBL) though there might be problems if the zone
contains CNAME or DNAME records.

That is why the sample configuration uses type static-stub.

> those recommendations are written down anywhere even if they represent

Hmm, I thought there was something saying that resolvers should try to
recover from failure, but I can't find it. Your description matches my
understanding of what happens in practice.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Southeast Iceland: Northeasterly 7 to severe gale 9. Rough or very rough.
Rain. Moderate or poor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Nov 2014 03:28:51 +1100

> configuration. (as opposed to an experiment on a hostmaster's

We could re-introduce zone signatures and require them for the
root zone but leave them optional for other zones..
 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Nov 2014 10:42:23 +0000

So I have adjusted the configuration on my workstation's name server to
include the global root servers (for robustness) as well as a local
stealth slave (for low latency). Here's a count of queries directed at the
root zone and the servers chosen to handle them. I wonder how different it
would be if I had worse connectivity...

 115 ::1#53
  28 128.63.2.53
  14 192.112.36.4
  23 192.203.230.10
  27 192.228.79.201
  22 192.33.4.12
  28 192.36.148.17
  21 192.5.5.241
  35 192.58.128.30
  21 193.0.14.129
  30 198.41.0.4
  28 199.7.83.42
  28 199.7.91.13
  15 2001:500:1::803f:235
  20 2001:500:2::c
  14 2001:500:2d::d
   8 2001:500:2f::f
  14 2001:500:3::42
  12 2001:500:84::b
  60 2001:503:ba3e::2:30
  36 2001:503:c27::2:30
  14 2001:7fd::1
  17 2001:7fe::53
  40 2001:dc3::35
  29 202.12.27.33

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Viking: Southeasterly 7 to severe gale 9. Rough or very rough.
Occasional drizzle. Moderate or good.