Subject: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

From: Tim Wicinski <[email-masked]>
Date: Sun, 16 Nov 2014 13:45:46 -0800

This starts a Call for Adoption for draft-wkumari-dnsop-root-loopback

The draft is available here:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-root-loopback/

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.

We will take all adoption support from Warren's email.

This official call for adoption ends Sunday, November 30th, 2014.

Thanks,
tim wicinski
DNSOP co-chair

---

From: "John Levine" <[email-masked]>
Date: 16 Nov 2014 22:12:41 -0000

>by DNSOP, and comments to the list, clearly stating your view.

Yes, I think the WG should adopt it.  It has some editorial issues, and perhaps
should explain why it doesn't allow, e.g., root on the same LAN rather than only
the same host, but we can easily deal with those.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 16 Nov 2014 14:28:19 -0800

Hi

In case I wasn't clear enough, the chairs will accept all the emails 
supporting the CfA from warren's previous email, so you'll not need to 
resend.

thanks
tim

---

From: Doug Barton <[email-masked]>
Date: Sun, 16 Nov 2014 15:12:58 -0800

On 11/16/14 1:45 PM, Tim Wicinski wrote:
|
| This starts a Call for Adoption for
| draft-wkumari-dnsop-root-loopback

I have read the draft, I support its adoption, and I will review and
contribute text as necessary.

It should come as no surprise that I'm in support, as I've been
advocating slaving the root zone locally since 2001. :)

The one flaw I see in the draft is that the configuration it
recommends is needlessly complex. Where possible (such as for BIND)
slaving the zone in the resolver instance gives a lot of benefits, and
few drawbacks. Before commenting further I'd love the authors to flesh
out their reasoning for not simply slaving the zone where possible.
There is currently some mumbling about the resolver not handing out
AA, but no reasoning as to why that is a problem. I've read the
threads on the original draft, and on this one, and there was some
good discussion of pros and cons there, I'd like to see some of that
discussion in the text. (And yes, I'm aware that one of the primary
motivators is DNSSEC, but the only thing in the root that we care
about are the DS records, and a validating resolver is going to chase
those up to its trust anchor anyway.)

Doug

---

From: Evan Hunt <[email-masked]>
Date: Mon, 17 Nov 2014 07:12:50 +0000

On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote:
> Before commenting further I'd love the authors to flesh

I'm not one of the authors, but I can give you an answer: in BIND,
and I believe in other DNS implementations as well, local authoritative
data isn't subject to DNSSEC validation. 

> (And yes, I'm aware that one of the primary motivators is DNSSEC, but the
> only thing in the root that we care about are the DS records, and a
> validating resolver is going to chase those up to its trust anchor
> anyway.)

No. If the root zone is slaved locally in the same view as the
validator, then the server (correctly) sees the top level DS as
local authoritative data, and presumes it to be valid.

(I just tested BIND to confirm this.  The log shows that org/DNSKEY,
isc.org/DS, and isc.org/DNSKEY were validated, but org/DS wasn't.)

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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 17 Nov 2014 07:14:39 +0000

> supporting the CfA from warren's previous email, so you'll not need to 

I can't remember if I already said I supported adoption. If so, I
support adoption again.

---

From: Doug Barton <[email-masked]>
Date: Mon, 17 Nov 2014 14:16:22 -0800

> isc.org/DS, and isc.org/DNSKEY were validated, but org/DS wasn't.)

That seems like something that should be fixable in BIND, yes? (And 
thanks for doing that testing, btw)

Doug

---

From: Paul Vixie <[email-masked]>
Date: Mon, 17 Nov 2014 14:23:43 -0800

> Doug Barton <mailto:[email-masked]>
> Monday, November 17, 2014 2:16 PM
>
>
it's not broken. dnssec has no facility for validating data at slave
synchronization time (after each axfr or ixfr or rsync). this isn't a
bind-ism. validation is defined to happen at consumption time.

-- 
Paul Vixie

---

From: Evan Hunt <[email-masked]>
Date: Mon, 17 Nov 2014 22:50:45 +0000

> thanks for doing that testing, btw)

Yes, by using two views and slaving the root in one of them and validating
in the other one, like it recommends in the draft. :)

With a single view, if you're authoritative for a zone, then you're
the authority, period.  You *know* the corect answer.  Validating yourself
to find out whether you're lying to yourself would be somewhat silly.

---

From: Doug Barton <[email-masked]>
Date: Mon, 17 Nov 2014 15:39:43 -0800

> in the other one, like it recommends in the draft. :)

:)

> to find out whether you're lying to yourself would be somewhat silly.

... except in the case where you're an authoritative slave, not the 
authoritative master.

But even as the master, let's say you do off-line signing, and now the 
file is sitting on the name server. I would still like to see a knob 
that says "validate everything, even if I'm authoritative for it" since 
that data file may have been tampered with. Perhaps that's needlessly 
paranoid (if they can attack the file they can probably attack other 
things as well), but in the case of a validating resolver that is also 
slaving signed data, "validate everything just in case" makes a lot of 
sense to me.

I would even go so far as to argue that the fact this isn't done is an 
oversight, since even if you're authoritative for a given strata there 
is always a signer a level above you. In the case of the root zone 
that's the root KSK, so even if I'm "authoritative" for the root zone I 
would still want the data in it to be validated when it's used.

... and yes, I realize that the different views (or different instances) 
trick will work, but now you're doing more work than you would have to 
do if there was a "validate everything" knob, PLUS you have the 
disadvantage of your resolving view caching data for long periods even 
though that data has changed in the slave view. So to me the "validate 
everything" knob seems like a win/win. Am I missing something?

Doug

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 17 Nov 2014 17:50:07 -0800

Trying to be polite here, but this seems just silly, and the only thing really should be "Don't Bother".

Root latency frankly speaking does not matter.  Lookups to the root themselves should be rare, and the responses have very long TTLs (48 hours!).  So this is clearly optimizing something that needs no optimization.

Lets say your resolver is behind an insanely high latency link with 10s RTTs to everywhere else on the Internet.

The additional latency for lookups to the root will be in the absolute noise compared with the latency for the lookups to the TLDs, or for the TCP RTT latency on all connection setup, or anything else like that.  So why waste the effort optimizing the one thing which doesn't matter?

A far better approach if you actually want to improve resolver performance on high latency links would be to prefetch on expiration: if an element is fetched out of the cache at least X times, when you expire it from the cache immediately trigger a new fetch for that name.

This would have a much better performance benefit than a root zone mirror.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: David Conrad <[email-masked]>
Date: Mon, 17 Nov 2014 17:57:11 -0800

Nicholas,

On Nov 17, 2014, at 5:50 PM, Nicholas Weaver <[email-masked]> wrote:
> Lookups to the root themselves should be rare, and the responses have very long TTLs (48 hours!).  

Lookups for names that do not exist are quite (one might say insanely) frequent and the TTL less ("Values of one to three hours have been found to work well and would make sensible a default").

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Nov 2014 20:04:56 -0800

> Root latency frankly speaking does not matter.  Lookups to the root themselves should be rare, and the responses have very long TTLs (48 hours!).  So this is clearly optimizing something that needs…

It's fine if you don't want the WG to adopt this draft, but that second sentence is clearly wrong. The third paragraph of the introduction says:

      <t>The primary goal of this design is to provide faster negative
      responses to stub resolver queries that contain junk queries. This
      design will probably have little effect on getting faster positive
      responses to stub resolver for good queries on TLDs, because the data
      for those zones is usually long-lived and already in the cache of the
      recursive resolver; thus, getting faster positive responses is a
      non-goal of this design.</t>

Lookups to the root for things that don't actually exist in the root happen all the time, yes?

--Paul Hoffman

---

From: Jacques Latour <[email-masked]>
Date: Thu, 20 Nov 2014 17:11:03 +0000

I think the one big drawback for me is the loss visibility and control for the root operators. As an example, DITL, what value will that have if only subset of queries make it to root servers? Will DNS-OARC have to collect logs from all these loopback authoritative slave recursive?  
-1 for adoption.
 
> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: November-17-14 11:05 PM
> To: Nicholas Weaver
> Cc: dnsop
> Subject: Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
> 
> > Root latency frankly speaking does not matter.  Lookups to the root
> themselves should be rare, and the responses have very long TTLs (48 hours!).
> So this is clearly optimizing something that needs no optimization.
> 
> It's fine if you don't want the WG to adopt this draft, but that second sentence is
> clearly wrong. The third paragraph of the introduction says:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Doug Barton <[email-masked]>
Date: Thu, 20 Nov 2014 09:19:03 -0800

The question at the end of this post was a serious one, FWIW.

---

From: Bob Harold <[email-masked]>
Date: Thu, 20 Nov 2014 12:28:10 -0500

I agree:   the "validate everything" knob seems like a win/win.

I would also like the option of verifying a DNSSEC domain when I do a zone
transfer, because that might be more efficient.

-- 
Bob Harold
University of Michigan

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Nov 2014 09:34:54 -0800

> The question at the end of this post was a serious one, FWIW.

If I understand it correctly, the question is a feature request for BIND/NSD/whatnot, not an issue with the draft, correct? That is, I think you are asking for your authoritative server to have a feature that performs DNSSEC validation on an incoming zone transfer (or possibly on a zone in your authoritative list). If your question is actually about the draft, by all means please clarify so we can deal with it in the draft.

--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Thu, 20 Nov 2014 10:08:50 -0800

> If I understand it correctly, the question is a feature request for BIND/NSD/whatnot, not an issue with the draft, correct? That is, I think you are asking for your authoritative server to have a f…

Paul,

I'm ignoring your message, as you obviously ignored mine. :)

Doug

---

From: Bob Harold <[email-masked]>
Date: Thu, 20 Nov 2014 13:20:07 -0500

I can see where "validate on zone transfer" would be a feature request.
And "validate everything" similarly.

For the draft, could a small paragraph be added explaining the difference
between using a separate view for the root zone and just loading it in the
same view, so that people like me realize the tradeoffs before we decide to
implement the draft with what we might think is a minor simplification, not
realizing the impact?

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
[email-masked]
734-647-6524 desk

On Thu, Nov 20, 2014 at 12:34 PM, Paul Hoffman <[email-masked]>
wrote:

> If I understand it correctly, the question is a feature request for
> BIND/NSD/whatnot, not an issue with the draft, correct? That is, I think
> you are asking for your authoritative server to have a feature that
> performs DNSSEC validation on an incoming zone transfer (or possibly on a
> zone in your authoritative list). If your question is actually about the
> draft, by all means please clarify so we can deal with it in the draft.
>
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Nov 2014 10:25:22 -0800

On Nov 20, 2014, at 10:20 AM, Bob Harold <[email-masked]> wrote:
> I can see where "validate on zone transfer" would be a feature request.  And "validate everything" similarly.
> 
> For the draft, could a small paragraph be added explaining the difference between using a separate view for the root zone and just loading it in the same view, so that people like me realize the tradeoffs before we decide to implement the draft with what we might think is a minor simplification, not realizing the impact?

Yes, we can add this to the BIND example in the appendices. Given that I kinda suck at BIND, proposed wording would cause less grief in the next draft...

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Thu, 20 Nov 2014 10:27:47 -0800

Jacques,

On Nov 20, 2014, at 9:11 AM, Jacques Latour <[email-masked]> wrote:
> I think the one big drawback for me is the loss visibility and control for the root operators.

Lack of comprehensive statistics would indeed be an issue (I'm not going to comment on the "control" bit of your assertion), however...

> As an example, DITL, what value will that have if only subset of queries make it to root servers?

The current DITL data is a subset of queries.  

> Will DNS-OARC have to collect logs from all these loopback authoritative slave recursive?  

All? No. However, I suspect if DNS-OARC asked, they might be able to get a sufficient number of operators to volunteer their data to provide a statistically valid sample.

> -1 for adoption.

Is that the only reason you don't think the draft should be adopted?

You are aware that some large resolver operators already do what is documented in root-loopback, right?

Regards,
-drc

---

From: Bob Harold <[email-masked]>
Date: Thu, 20 Nov 2014 13:52:47 -0500

Thanks Paul,
   I use BIND, but am not an expert.  Based on the discussion I will
suggest some words and the experts can correct me:

Note:  By using a separate view, the "recursive" view will do DNSSEC
validation on the responses it receives from the "root" view, which is
necessary for security.  It will cache the answers, including the
validation.

Alternatively, if the root zone was loaded directly in the "recursive"
view, then DNSSEC validation would not be done, as BIND would trust the
zone.  Then you would want to do separate validation on the zone during
zone transfers.  This might result in less caching and less time spent
validating, but requires a more complex configuration.

On Thu, Nov 20, 2014 at 1:25 PM, Paul Hoffman <[email-masked]> wrote:

> > For the draft, could a small paragraph be added explaining the
> difference between using a separate view for the root zone and just loading
> it in the same view, so that people like me realize the tradeoffs before we
> decide to implement the draft with what we might think is a minor
> simplification, not realizing the impact?
>
> Yes, we can add this to the BIND example in the appendices. Given that I
> kinda suck at BIND, proposed wording would cause less grief in the next
> draft...
>
> --Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Thu, 20 Nov 2014 11:13:42 -0800

What about something like this:

When using BIND, or other software that can act as both a recursive and 
authoritative server in the same instance, there is a tradeoff between 
using a separate view (or separate instance) for slaving the root zone, 
versus slaving the zone into the same view (or instance) where the 
recursion is occurring.

Using a separate view/instance has the advantage that when the recursor 
is also performing DNSSEC validation that the DS records in the slaved 
zone will also be validated. In BIND this validation does not occur when 
the zone is slaved into the same view/instance where the 
recursion/validation is occurring.

Slaving the zone into the same view/instance as the recursion has the 
advantage that when changes happen to the data in the zone the recursive 
view/instance will be updated as soon as it receives its copy of the 
zone. When using a separate view for slaving the zone the recursive 
instance will cache all of the queries it looks up. Currently the TTL 
for DS and delegation NS records is 2 days.

On 11/20/14 10:52 AM, Bob Harold wrote:
>     validation on the responses it receives from the "root" view, which
>     is necessary for security.  It will cache the answers, including the
>     validation.
>
>     Alternatively, if the root zone was loaded directly in the
>     "recursive" view, then DNSSEC validation would not be done, as BIND
>     would trust the zone.  Then you would want to do separate validation
>     on the zone during zone transfers.  This might result in less
>     caching and less time spent validating, but requires a more complex
>     configuration.
>
>
>
>
> --
> Bob Harold
> hostmaster, UMnet, ITcom
> [email-masked] <mailto:[email-masked]>
> 734-647-6524 desk
>
> On Thu, Nov 20, 2014 at 1:25 PM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Nov 20, 2014, at 10:20 AM, Bob Harold <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     Yes, we can add this to the BIND example in the appendices. Given
>     that I kinda suck at BIND, proposed wording would cause less grief
>     in the next draft...
>
>     --Paul Hoffman
>
>

---

From: Evan Hunt <[email-masked]>
Date: Thu, 20 Nov 2014 19:27:13 +0000

> for DS and delegation NS records is 2 days.

Accurate summary, but as this is the same behavior as you get when using
traditional root servers, I'm not sure it makes sense to characterize
it as a disadvantage.

---

From: Doug Barton <[email-masked]>
Date: Thu, 20 Nov 2014 11:32:47 -0800

> traditional root servers, I'm not sure it makes sense to characterize

Well I tried to be neutral about that, for just the reason you mention. 
(I don't actually call it a disadvantage, I just point out the 
behavior.) To be fair, I think it actually *is* a disadvantage, so 
perhaps my thoughts on that are clouding my ability to be objective.

How about adding the following to the second-to last sentence, "... 
looks up, as it would using the traditional root hints method."

Does that sound more balanced?

Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Nov 2014 18:12:02 -0800

Clearly, different people view the "advantages" and "disadvantages" separately. The wording below tries to make the comparisons neutral while still fully stating what the differences are. Note that I made this wording specific to BIND: when we have other multi-view servers  in the examples, I'll write specific wording for them. Is the following (re-)wording correct and complete? 

==========
BIND handles both DNSSEC validation and caching of changed authoritative information differently depending on the whether the configuration is to use two separate views (one for the authoritative zone, one for recurison) or to use the same view for both servers.

Validation:
When using separate views, the DS records in the slaved zone will be validated as the zone is refreshed or updated. When using the same view, this validation does not occur for the slaved zone.

Caching:
When using separate views, the recursive server will cache all of the queries it looks up, just as it would using the traditional root hints method. Thus, as the zone in the other view is refreshed or updated, changed information will not appear in the recursive server until the TTL of the old record times out; currently the TTL for DS and delegation NS records is two days. When using the same view, as the zone is refreshed or updated, all zone data in the recursive server will be updated as soon as it receives its copy of the zone.
==========

--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Fri, 21 Nov 2014 19:09:26 -0800

On 11/21/14 6:12 PM, Paul Hoffman wrote:
| Clearly, different people view the "advantages" and "disadvantages"
| separately. The wording below tries to make the comparisons neutral
| while still fully stating what the differences are. Note that I
| made this wording specific to BIND: when we have other multi-view
| servers  in the examples, I'll write specific wording for them. Is
| the following (re-)wording correct and complete?

I chose the wording I did in the version I sent very carefully,
because the issues discussed are exactly the same if you use two views
in the same instance, or if you use multiple instances. The latter
issue is particularly relevant at larger sites since I could easily
imagine a site setting up their own root instance with a slaved copy
of the zone that their resolvers are configured to forward to.

Bob's request was to outline the pros and cons of each method, so that
people who are less sophisticated about these things will know how to
make a decision about what method to choose. I think showing that two
views would operate the same as two different instances is important
for meeting that goal.

Regarding making the wording BIND specific, I'm not opposed to that
per se, I'm just curious if there is any other commonly used software
capable of doing both authority and recursion in the same instance. If
there is, we should not make the wording specific to BIND.

| ========== BIND handles both DNSSEC validation and caching of
| changed authoritative information differently depending on the
| whether the configuration is to use two separate views (one for the
| authoritative zone, one for recurison) or to use the same view for
| both servers.

The sentence above makes little sense, and could even be described as
misleading. If you want to leave the following two paragraphs the way
you have them, and account for what I discussed above, you could open
with something like this:

Name server software that permits authoritative zones and recursion to
exist in the same instance (such as BIND) will treat the zone data
differently if it is slaved into a separate view (or a separate
instance of the software) versus slaving the zone into the same view
or instance that is also performing the recursion.

| Validation: When using separate views, the DS records in the slaved
| zone will be validated as the zone is refreshed or updated.

That is factually incorrect. They will be validated as they are used.
I'm not sure where this obsession came from about validating the zone
when it's transferred. That's never been a part of DNSSEC.

Here's my previous paragraph on this, modified to fit your format a
bit better:

When using a separate view in a recursor that is also performing
DNSSEC the DS records in the slaved zone will be validated as they are
used. In BIND this validation does not occur when the zone is slaved
into the same view where the recursion is occurring.

| When using the same view, this validation does not occur for the
| slaved zone.
|
| Caching: When using separate views, the recursive server will cache
| all of the queries it looks up, just as it would using the
| traditional root hints method. Thus, as the zone in the other view
| is refreshed or updated, changed information will not appear in the
| recursive server until the TTL of the old record times out;
| currently the TTL for DS and delegation NS records is two days.
| When using the same view, as the zone is refreshed or updated, all
| zone data in the recursive server will be updated as soon as it
| receives its copy of the zone.

There are several grammatical problems with this paragraph. Here's an
update with some other refinements:

When using separate views the recursive server will cache all of the
queries for the slaved zone, just as it would using the traditional
root hints method. Thus, as the zone in the other view is refreshed or
updated changed information will not appear in the recursive server
until the TTL of the old record times out. Currently the TTL for DS
and delegation NS records in the root zone is two days. When using the
same view all zone data in the recursive server will be updated as
soon as it receives its copy of the zone.

hth,

Doug

---

From: Doug Barton <[email-masked]>
Date: Fri, 21 Nov 2014 19:12:07 -0800

On 11/21/14 7:09 PM, Doug Barton wrote:
| When using a separate view in a recursor that is also performing
| DNSSEC

validation

| the DS records in the slaved zone will be validated as they are
| used. In BIND this validation does not occur when the zone is
| slaved into the same view where the recursion is occurring.

oops :)

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Nov 2014 20:43:35 -0800

On Nov 21, 2014, at 7:09 PM, Doug Barton <[email-masked]> wrote:
> in the same instance, or if you use multiple instances.

Good point. In fact, Evan made that point to me earlier and I forgot it. :-(

> The latter

That could be the case, but it is not relevant for this draft, which is only about slaving on a loopback address on the same box.

> views would operate the same as two different instances is important

As long as we are talking about two instances running on the same box, I agree. See below.

> there is, we should not make the wording specific to BIND.

I have been told informally that PowerDNS will be able to do both in the future. However, unless it has the exact same implementation considerations as BIND, trying to have one set of wording cover both will probably be impossible to read. I would rather fork the wording in the two sections and make sure it is succinctly about the specific software.

> or instance that is also performing the recursion.

I was trying to be specific about the differences, but I can see that being more general would make it more readable.

> That is factually incorrect. They will be validated as they are used.

Yeeps, good catch.

> soon as it receives its copy of the zone.

Put together, and still open to comment:

When slaving a zone, BIND will treat zone data differently if it is slaved into a separate view (or
a separate instance of the software) versus slaving the zone into the same view or instance that is
also performing the recursion.

Validation:
When using separate views or separate instances, the DS records in the slaved zone will be validated
as the zone data is accessed by the recursive server. When using the same view, this validation does
not occur for the slaved zone.

Caching:
When using separate views or instances, the recursive server will cache all of the queries for the
slaved zone, just as it would using the traditional root hints method. Thus, as the zone in the
other view or instance is refreshed or updated, changed information will not appear in the recursive
server until the TTL of the old record times out. Currently the TTL for DS and delegation NS records
is two days. When using the same view, all zone data in the recursive server will be updated as soon
as it receives its copy of the zone.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 Nov 2014 00:29:01 -0800

this isn't about views, or bind. rfc 1034 directly contemplated a server
that had both recursive and authoritative responsibilities and content.
however, the specification was incomplete, and early BIND (everything
before BIND9) got it wrong.

a short amendment to rfc 1034 stating that authoritative and recursive
data should not be mixed in the same data structure, and that the RD bit
of a query should control which data structure (recursive or
authoritative) was searched, and giving specific fall-through conditions
under which an RD=1 query could access authoritative data, would have
fixed it. however, we (the whole dns community) were in a panic about
the number of authority-data pollution events that had come from these
"mixed mode" servers, and so there's now a general prohibition against
"mixed mode" servers, even though BIND9 still supports it for backward
compatibility with old BIND8 installations.

DNSSEC was being worked on during these panicked times, and the general
prohibition was very much top-of-mind, and as a result, mixed-mode
DNSSEC servers containing both authoritative and recursive data, are
unspecified.

being unspecified is not always a death sentence, but in this case, it
is. there is no way to truly validate a zone after an ixfr or axfr
without performing some queries, to validate the chain all the way back
to a trust anchor. however, an authority server is not required in
DNSSEC to ever make queries, or to have any trust anchors installed. so,
the best an authoritative-only DNSSEC server can do is integrity
checking against a zone's own keys and signatures, but this leaves it
open to a man-in-the-middle attack where someone uses ARP or IGP or EGP
poison to hijack the master's address and then use the axfr protocol to
send an entirely bogus yet entirely self-consistent zone.

in other words the only DNSSEC server who could truly validate a zone's
content after ixfr/axfr is a mixed-mode server, which has not been
specified.

so, mr. hoffman, the right text to cover this case would look like the
following:

"Note that there exist mixed-mode servers offering both authoritative
and recursive service, but there is no current standard by which
authoritative data is used for validation or returned in recursive
queries in such a server. This document therefore specifies only the
two-servers model, where root name service is provided by an authority
server (subtype: stealth slave) running on the host's loopback network,
and special configuration is used in that host's recursive name server
to use this loopback authority server for DNS root queries. By
implication, the validation of the content of this stealth-slave's root
zone is entirely the responsibility of the co-hosted RDNS server. Any
future revision to this specification which allows for mixed-mode DNS
service will have the burden of explaining how the validation function
is to be performed. Absent such specification, mixed-mode DNSSEC service
is outside the scope of this document."

i didn't enjoy mr. barton's freebsd stealth-roots-everywhere experiment,
and this is one of the reasons why.

vixie

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 26 Nov 2014 17:12:42 +0800

Are the functions of this kind of recursive resolvers similar to the slave server of the root?
The root slave server gets the latest info from root master server, serving many recursive server.
This kind of "root slave server " gets the latest info from root  servers, serving only local recursive server.

Can we understand this concept from this kind of view?

Jiankang Yao

From: Tim Wicinski
Date: 2014-11-17 05:45
To: dnsop
Subject: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

Thanks,
tim wicinski
DNSOP co-chair

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Nov 2014 08:02:00 -0800

> Are the functions of this kind of recursive resolvers similar to the slave server of the root?

Yes, of course. As defined in the document, the local root server has exactly the root server data in it, and acts like an authoritative server.

> The root slave server gets the latest info from root master server, serving many recursive server.

That is not the design in the draft. In the draft, the root server on the loopback can only serve one recursive server, namely the one on the same host.

> This kind of "root slave server " gets the latest info from root  servers, serving only local recursive server.

Correct: "serving only local recursive server", not "serving many recursive server".

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 30 Nov 2014 17:41:46 -0500

All

The Call for Adoption for this is wrapping up, and it appears we have 
consensus on the working group taking on this draft.  I want to thank 
everyone for their comments.  Authors, you should resubmit with the 
proper ID.

thanks
tim

On 11/16/14 4:45 PM, Tim Wicinski wrote:
> 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.
>