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

[Tim Wicinski]

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:


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



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On Nov 26, 2014, at 1:12 AM, Jiankang Yao  wrote:
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jiankang Yao]

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

On 11/20/14 11:27 AM, Evan Hunt wrote:

On Thu, Nov 20, 2014 at 11:13:42AM -0800, Doug Barton wrote:

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.


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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Thu, Nov 20, 2014 at 11:13:42AM -0800, Doug Barton wrote:
> 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.

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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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:

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.




--
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharo...@umich.edu 
734-647-6524 desk

On Thu, Nov 20, 2014 at 1:25 PM, Paul Hoffman mailto:paul.hoff...@vpnc.org>> wrote:

On Nov 20, 2014, at 10:20 AM, Bob Harold mailto:rharo...@umich.edu>> 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




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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.




-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharo...@umich.edu
734-647-6524 desk

On Thu, Nov 20, 2014 at 1:25 PM, Paul Hoffman  wrote:

> On Nov 20, 2014, at 10:20 AM, Bob Harold  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[David Conrad]

Jacques,

On Nov 20, 2014, at 9:11 AM, Jacques Latour  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On Nov 20, 2014, at 10:20 AM, Bob Harold  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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)
rharo...@umich.edu
734-647-6524 desk

On Thu, Nov 20, 2014 at 12:34 PM, Paul Hoffman 
wrote:

> On Nov 20, 2014, at 9:19 AM, Doug Barton  wrote:
> > 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
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

On 11/20/14 9:34 AM, Paul Hoffman wrote:

On Nov 20, 2014, at 9:19 AM, Doug Barton  wrote:

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,

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

Doug


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On Nov 20, 2014, at 9:19 AM, Doug Barton  wrote:
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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

On 11/17/14 3:39 PM, Doug Barton wrote:
>
>> On 11/17/14 2:50 PM, Evan Hunt wrote:
>>
>>> On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:
>>>
 That seems like something that should be fixable in BIND, yes? (And
 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.
>>>
>>
>> ... 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?
>>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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


On 11/17/14 3:39 PM, Doug Barton wrote:

On 11/17/14 2:50 PM, Evan Hunt wrote:

On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:

That seems like something that should be fixable in BIND, yes? (And
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.


... 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?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jacques Latour]

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:dnsop-boun...@ietf.org] 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
> 
> On Nov 17, 2014, at 5:50 PM, Nicholas Weaver 
> wrote:
> > 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.
> 
> 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:
> 
>   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.
> 
> Lookups to the root for things that don't actually exist in the root happen 
> all the
> time, yes?
> 
> --Paul Hoffman
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On Nov 17, 2014, at 5:50 PM, Nicholas Weaver  wrote:
> 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.

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:

  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.

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

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[David Conrad]

Nicholas,

On Nov 17, 2014, at 5:50 PM, Nicholas Weaver  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Nicholas Weaver]

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,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

On 11/17/14 2:50 PM, Evan Hunt wrote:

On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:

That seems like something that should be fixable in BIND, yes? (And
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.


... 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:
> That seems like something that should be fixable in BIND, yes? (And 
> 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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

> Doug Barton 
> Monday, November 17, 2014 2:16 PM
>
>
> That seems like something that should be fixable in BIND, yes? (And
> thanks for doing that testing, btw)
>
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

On 11/16/14 11:12 PM, Evan Hunt wrote:

On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote:

Before commenting further I'd love the authors to flesh
out their reasoning for not simply slaving the zone where possible.


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.)


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


Doug


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Sun, Nov 16, 2014 at 02:28:19PM -0800, Tim Wicinski wrote:
> 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.

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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote:
> Before commenting further I'd love the authors to flesh
> out their reasoning for not simply slaving the zone where possible.

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 -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUaS96AAoJEFzGhvEaGryEOf8IALMQEt2gg3SUuJs8VKSz5w40
lcrooyF+NUrqS3+uWdlzIddHsm2fqluXV25QNiRDySn7J/We/dsokBr8RxH7nqLc
aSupz/domI7uTaPD/hz7LR/5HNf/7vCfUrlhlWn9FoboZQy7FeOqFr8HQrGSEKw1
IsXCCHK23U9QEQM16I96kBCUO+JSM+w1ACqKaSo3qJMxG37fAAzPSga0X6UeLlaJ
+amLZzWu5I2QrbhqQNYeFm4t5jDg2wi8NrS8u5IxDSWRUEWrNnz9lO4UpjOl8gjo
EQS+T618nUeLBawFxMNmcrFMU4SS6654oD0ttXGN+hbxoXBAVRJMHCuGMlXMcik=
=hAqD
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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

On 11/16/14 1:45 PM, Tim Wicinski wrote:


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



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop