Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Stephane Bortzmeyer]

On Thu, Aug 04, 2016 at 08:03:35PM -0400,
 Tim Wicinski  wrote 
 a message of 27 lines which said:

> This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-priming

I know, it's too late (damned holidays) but I think the document is
OK, I just suggest a few additions:

Section 3.3: Replace the first two sentences by:

The resolver MAY set the DNSSEC OK [RFC4033] bit.  At the time this
document is being published, there is little use to performing DNSSEC
validation on the priming query. This is because all root name servers
are under a separate zone, "root-servers.net" (delegated to the root
name servers). The resolver will eventually need  and A RRsets of
the NS names in this zone. But the "root-servers.net" zone is not
signed. So a man-in-the-middle attack on the priming query can result
in malicious data in the responses.

(it was proposed and explained in
)

Same section 3.3, at the end, add:

Note a validating resolver won't accept responses from rogue root name
servers, if they are different from the real responses, since the
resolver has a trust anchor for the root and the answers from the root
are signed. So, if there is a man-in-the-middle attack on the priming
query, the only result for a validating resolver will be a denial of
service.

Section  5, add a reference to section 3.3, after "DNSSEC".

There is also a small contradiction between the abstract ("and the
necessary address information for reaching the root servers") and
section 4.1 ("There ___may be___ an Additional section with A and/or
 RRSets").

Two personal questions (I cannot find a discussion on these two points
in the archive):

Section 4.1 "There may be an Additional section with A and/or 
RRSets" There is no mention of what the resolver should do if this
section is missing. Sending a query XXX.root-servers.net/ to the
same authoritative server used for the priming?

Section 4.2 "a resolver SHOULD consider the address information found
in the Additional section complete for any particular server that
appears at all" Why this rule? (Most root name servers, when the
advertised buffer is too small, sacrifice IPv6 addresses.)

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[神明達哉]

At Fri, 19 Aug 2016 16:31:18 -0700,
"Paul Hoffman"  wrote:

> > - Section 2
> >
> >Therefore, it is important that resolvers be able to cope with
> >change, even without relying upon configuration updates to be
> > applied
> >by their operator.
> >
> >   If we really want to make it work "even without relying upon
> >   configuration updates", we may need to consider some extreme cases
[...]
> This seems like a far-fetched example that would require a new fallback
> mechanism. There are many, many reasons why the root server operators
> would prevent *all* the addresses from changing during the TTL.

I'm okay with dismissing the issue.

> > - Section 3.3 (DNSSEC with Priming Queries)
> >
> >   I remember I commented on this section before and we had discussions
> >   about how to address it.  I don't remember the conclusion at that
> >   time, but is this a result of that discussion?  I'm asking this
> >   because the current text still seems to have some explanation gap to
> >   me.
>
> The conclusion was the current text. In essence, it says "turn on DO if
> you want; although it is useless now, it might be useful in the future".

Okay, then that's fine for me.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Edward Lewis]

On 8/4/16, 20:03, "DNSOP on behalf of Tim Wicinski"  wrote:
>Remember the Resolver Priming draft?

Comments on the draft 
(https://tools.ietf.org/id/draft-ietf-dnsop-resolver-priming-07.txt):

## 3.3.  DNSSEC with Priming Queries
##
##The resolver MAY set the DNSSEC OK [RFC4033] bit.  At the time this
##document is being published, there is little use to performing DNSSEC
##validation on the priming query because the "root-servers.net" zone
##is not signed, and so a man-in-the-middle attack on the priming query
##can result in malicious data in the responses.  However, if the
##"root-servers.net" zone is later signed, or if the root server
##operators choose a different zone to identify themselves and that
##zone is signed, having DNSSEC validation for the priming queries
##might be valuable.

Recommend against altering the trust anchor settings based on anything learned 
via priming.  Not that a priming query would contain DS or DNSKEY resources 
records "normally" (and thus should not have them) but if the idea to "push" 
additional records comes around again, the priming query is not the place to 
also update the secure entry points.

In section 4.2:

##For an EDNS response, a resolver SHOULD consider the address
##information found in the Additional section complete for any
##particular server that appears at all.  Said another way: in an EDNS
##response, if the additional section only has an A RRSet for a server,
##the resolver SHOULD assume that no  RRSet exists.

Is "an EDNS response" a term well-enough defined to be used this way?

A possible rewording ought to include - if the priming query contained, via 
EDNS, Requestor's Payload Size of more than XXY bytes, the address 
information...complete.  But this assumes that the priming query Size was large 
enough, e.g., it wasn't set to be 515 bytes.

## 5.  Security Considerations
##
##Spoofing a response to a priming query can be used to redirect all of
##the queries originating from a victim recursive resolver to one or
##more servers for the attacker.  Until the responses to priming
##queries are protected with DNSSEC, there is no definitive way to
##prevent such redirection.

There is one use case I'm concerned about - because it has happened.

http://research.dyn.com/2008/05/identity-theft-hits-the-root-n-1/

In so much as at that article is true, a defense that can be used is to 
recommend multiple (2 or 3) priming queries and have the receiver check for 
consistency.  Two might indicate a problem, three can point out which is a 
problem.  In the absence of DNSSEC validation and the observation that Root 
System changes happen one at a time and fairly well spread out in time, this 
might be beneficial to recommend.

I offer this just as a suggestion.  (I've been told my major operators that 
having at least three sources of information increases reliability.  I'm basing 
my comment on that, more so than the linked story.)


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Paul Hoffman]

On 17 Aug 2016, at 9:45, 神明達哉 wrote:


I've read draft-ietf-dnsop-resolver-priming-07.  I think this is a
useful document and is almost ready for publication.


Thanks for the careful review.


But there seem
to be a few non-trivial issues that may need to be addressed.

Specific comments:

- Section 2

   Therefore, it is important that resolvers be able to cope with
   change, even without relying upon configuration updates to be 
applied

   by their operator.

  If we really want to make it work "even without relying upon
  configuration updates", we may need to consider some extreme cases
  where all of the ./NS data (and/or all of their glue /A records)
  change while a resolver keeps running for a very long period.  If
  this happens, once the cached priming data expires, even the next
  priming would fail, since at that point the resolver needs to use
  the configured data but none of the configured data is usable.  If
  we want to make it work even in such cases, we may have to encourage
  some specific techniques more strongly, e.g., query prefetch or
  auto-update the configured "root hint" with the result of priming
  query, etc.  Or, if this sentence doesn't intend to cover such
  extreme cases, it may probably have to be reworded to avoid
  misunderstanding.


This seems like a far-fetched example that would require a new fallback 
mechanism. There are many, many reasons why the root server operators 
would prevent *all* the addresses from changing during the TTL.



- Section 3.1

   The recursive
   resolver SHOULD expire the NS records of the root servers according
   to the TTL values given in the priming response.

  Isn't this (= expiring cached data according to TTL) obvious and
  non-specific to priming responses?  I don't see why we bother to say
  the obvious, and if we want to say that I don't see why it's not
  even a MUST.


Agree. We'll reword this.


- Section 3.2

   If a priming query does not get a response within 2 seconds, the
   recursive resolver SHOULD retry with a different target address 
from

   the configuration.

  This sentence doesn't seem to be necessary (and may even cause an
  unnecessary confusion), so I'd primarily suggest just removing it
  (see my other message on this specific point).


Yes. Earlier WG discussion brought this up, and we'll remove anything 
about time.


- Section 3.3 (DNSSEC with Priming Queries)

  I remember I commented on this section before and we had discussions
  about how to address it.  I don't remember the conclusion at that
  time, but is this a result of that discussion?  I'm asking this
  because the current text still seems to have some explanation gap to
  me.


The conclusion was the current text. In essence, it says "turn on DO if 
you want; although it is useless now, it might be useful in the future".



- Section 4.1

   [...]  There may be an Additional section with A
   and/or  RRSets for the root name servers pointed at by the NS
   RRSet.

  At least in principle, I suspect the additional A and/or  RRsets
  is critical information for priming to work correctly.  If the
  priming response completely replaces ./NS in the cache populated
  from the local configuration but the response lacks the additional
  address RRsets, then no further recursive resolution will be
  successful.  I don't know what's the best way to address this, but
  one easy tweak is to say "there should be an Additional section..."
  instead of "may".


Good suggestion.



- Section 4.2

   Said another way: in an EDNS
   response, if the additional section only has an A RRSet for a 
server,

   the resolver SHOULD assume that no  RRSet exists.

  It's not clear to me why we need to say this, especially with an
  RFC2119 keyword.  What's wrong, for example, if a resolver tries to
  resolve a "missing"  via a separate direct query?


Agree: we will remove the SHOULD.

--Paul Hoffman

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Tim Wicinski]

All

The WGLC last call for resolver-priming has concluded. There was a solid 
number of good reviews, and no reasons to not publish this.


I want to thank everyone who gave reviews and feedback. I'm going to go 
over the list with the author(s) and make sure everything was covered.


thanks
tim


On 8/4/16 8:03 PM, Tim Wicinski wrote:

All

Remember the Resolver Priming draft? This thing has been kicking around
for a good solid 5 years. It stalled for a few years waiting for the
busy authors perform some updates.
Then Paul Hoffman took the reins and has done a great job getting this
ready for publication.

This starts a Working Group Last Call  for
draft-ietf-dnsop-resolver-priming

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/

Please review the draft and offer relevant comments. Also, if someone
feels the document is *not* ready for publication, please speak out with
your reasons.

This starts a two week Working Group Last Call process, and ends on 19
August, 2016

thanks
tim


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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Bob Harold]

On Wed, Aug 17, 2016 at 12:45 PM, 神明達哉  wrote:

> At Thu, 4 Aug 2016 20:03:35 -0400,
> Tim Wicinski  wrote:
>
> > This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-
> priming
> >
> > Current versions of the draft is available here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
> >
> > Please review the draft and offer relevant comments. Also, if someone
> > feels the document is *not* ready for publication, please speak out with
> > your reasons.
> >
> > This starts a two week Working Group Last Call process, and ends on 19
> > August, 2016
>
> I've read draft-ietf-dnsop-resolver-priming-07.  I think this is a
> useful document and is almost ready for publication.  But there seem
> to be a few non-trivial issues that may need to be addressed.
>
> Specific comments:
>
> - Section 2
>
>Therefore, it is important that resolvers be able to cope with
>change, even without relying upon configuration updates to be applied
>by their operator.
>
>   If we really want to make it work "even without relying upon
>   configuration updates", we may need to consider some extreme cases
>   where all of the ./NS data (and/or all of their glue /A records)
>   change while a resolver keeps running for a very long period.  If
>   this happens, once the cached priming data expires, even the next
>   priming would fail, since at that point the resolver needs to use
>   the configured data but none of the configured data is usable.  If
>   we want to make it work even in such cases, we may have to encourage
>   some specific techniques more strongly, e.g., query prefetch or
>   auto-update the configured "root hint" with the result of priming
>   query, etc.  Or, if this sentence doesn't intend to cover such
>   extreme cases, it may probably have to be reworded to avoid
>   misunderstanding.
>
> I think we could clarify the sentence by adding some thing like "as long
as at least one of the configured addresses (for each address type, IPv4
and IPv6) responds with the correct list."  Even if all the IP's change, we
just need one of the IP's to respond with the new list.


> - Section 3.1
>
>The recursive
>resolver SHOULD expire the NS records of the root servers according
>to the TTL values given in the priming response.
>
>   Isn't this (= expiring cached data according to TTL) obvious and
>   non-specific to priming responses?  I don't see why we bother to say
>   the obvious, and if we want to say that I don't see why it's not
>   even a MUST.
>
> - Section 3.2
>
>If a priming query does not get a response within 2 seconds, the
>recursive resolver SHOULD retry with a different target address from
>the configuration.
>
>   This sentence doesn't seem to be necessary (and may even cause an
>   unnecessary confusion), so I'd primarily suggest just removing it
>   (see my other message on this specific point).
>
> - Section 3.3 (DNSSEC with Priming Queries)
>
>   I remember I commented on this section before and we had discussions
>   about how to address it.  I don't remember the conclusion at that
>   time, but is this a result of that discussion?  I'm asking this
>   because the current text still seems to have some explanation gap to
>   me.
>
> - Section 4.1
>
>[...]  There may be an Additional section with A
>and/or  RRSets for the root name servers pointed at by the NS
>RRSet.
>
>   At least in principle, I suspect the additional A and/or  RRsets
>   is critical information for priming to work correctly.  If the
>   priming response completely replaces ./NS in the cache populated
>   from the local configuration but the response lacks the additional
>   address RRsets, then no further recursive resolution will be
>   successful.  I don't know what's the best way to address this, but
>   one easy tweak is to say "there should be an Additional section..."
>   instead of "may".
>
> - Section 4.2
>
>Said another way: in an EDNS
>response, if the additional section only has an A RRSet for a server,
>the resolver SHOULD assume that no  RRSet exists.
>
>   It's not clear to me why we need to say this, especially with an
>   RFC2119 keyword.  What's wrong, for example, if a resolver tries to
>   resolve a "missing"  via a separate direct query?
>
> --
> JINMEI, Tatuya
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[神明達哉]

At Sat, 13 Aug 2016 14:01:52 +0300,
Andreas Gustafsson  wrote:

> There is nothing wrong with existing resolvers that use the same
> timeout and retransmission strategies for priming queries as for any
> other query, and it seems wrong to me that a specific retransmission
> timeout should be required for some queries but not others.

+1.  This is actually I thought in my own read of the draft.
Mentioning a specific timeout value seems a clear overkilling (with no
apparent reason) to me, and while I wouldn't be necessarily opposed to
mentioning the retry at all, it's still awkward to me.  So I'd be
happier if it's simply removed.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Marek Vavruša]

On Sun, Aug 14, 2016 at 4:27 PM, Paul Hoffman  wrote:
> On 5 Aug 2016, at 2:45, Shane Kerr wrote:
>
>> First, we have:
>>
>>   "If a priming query does not get a response within 2 seconds, the
>>   recursive resolver SHOULD retry with a different target address from
>>   the configuration."
>>
>> The "2 seconds" seems a bit arbitrary. I'm not sure why any
>> recommendations need to be made at all. The document already says that
>> these are basically normal DNS queries elsewhere - surely that is enough?
>> (And maybe if we do want to recommend a retry then we need to be clear
>> that if an answer comes from an earlier query that the resolver may
>> accept it?)
>
>
> It's sounding like people don't like the mention of a time at all. Proposed
> replacement:
>
> If a priming query does not get a response within a short time, the
> recursive resolver needs to retry the query with a different target address
> from the configuration.
>
> (I am avoiding saying "within a configured time" because I don't think this
> is easily configured in some common recursors.)

Since root-servers.net is not signed, recursor also has to deal with
compatibility problems, such as EDNS stripping for example. I wonder
how much should be clarified. I was a bit surprised the
root-servers.net is still unsigned, is this deliberate or what would
it take to sign it? It's a critical zone, and signing it would make
this draft much shorter.

Marek

>> Second, a possible additional security consideration is that a priming
>> query typically signals a resolver starting with an empty cache
>> (although not always - the Knot resolver has a persistent cache, for
>> example). This may be an especially vulnerable time for a resolver for
>> cache poisoning. I don't know what can be done to mitigate this though
>> aside from requiring TCP or DNS cookies for a time after startup, so
>> perhaps this can be left out.
>
>
> Proposed wording:
>
> An on-path attacker who sees a priming query coming from a resolver can
> inject false answers before a root server can give correct answers. If the
> attacker's answers are accepted, this can set up the ability to give further
> false answers for future queries to the resolver. False answers for root
> servers are more dangerous than, say, false answers for TLDs because the
> root servers are the highest node of the DNS.
>
> --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] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Warren Kumari]

On Sun, Aug 14, 2016 at 6:27 PM, Paul Hoffman  wrote:
> On 5 Aug 2016, at 2:45, Shane Kerr wrote:
>
>> First, we have:
>>
>>   "If a priming query does not get a response within 2 seconds, the
>>   recursive resolver SHOULD retry with a different target address from
>>   the configuration."
>>
>> The "2 seconds" seems a bit arbitrary. I'm not sure why any
>> recommendations need to be made at all. The document already says that
>> these are basically normal DNS queries elsewhere - surely that is enough?
>> (And maybe if we do want to recommend a retry then we need to be clear
>> that if an answer comes from an earlier query that the resolver may
>> accept it?)
>
>
> It's sounding like people don't like the mention of a time at all. Proposed
> replacement:
>
> If a priming query does not get a response within a short time, the
> recursive resolver needs to retry the query with a different target address
> from the configuration.
>
> (I am avoiding saying "within a configured time" because I don't think this
> is easily configured in some common recursors.)


This sounds fine / good to me -- or perhaps even:
"If a priming query does not get a response, the
recursive resolver needs to retry the query with a different target address
from the configuration."

s/ within a short time//.

This avoids the obvious "What did you mean by 'short'?!" question. IMO
implementors can make their own decision here.

W

>
>> Second, a possible additional security consideration is that a priming
>> query typically signals a resolver starting with an empty cache
>> (although not always - the Knot resolver has a persistent cache, for
>> example). This may be an especially vulnerable time for a resolver for
>> cache poisoning. I don't know what can be done to mitigate this though
>> aside from requiring TCP or DNS cookies for a time after startup, so
>> perhaps this can be left out.
>
>
> Proposed wording:
>
> An on-path attacker who sees a priming query coming from a resolver can
> inject false answers before a root server can give correct answers. If the
> attacker's answers are accepted, this can set up the ability to give further
> false answers for future queries to the resolver. False answers for root
> servers are more dangerous than, say, false answers for TLDs because the
> root servers are the highest node of the DNS.
>
> --Paul Hoffman
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Paul Hoffman]

On 5 Aug 2016, at 2:45, Shane Kerr wrote:


First, we have:

  "If a priming query does not get a response within 2 seconds, the
  recursive resolver SHOULD retry with a different target address from
  the configuration."

The "2 seconds" seems a bit arbitrary. I'm not sure why any
recommendations need to be made at all. The document already says that
these are basically normal DNS queries elsewhere - surely that is 
enough?

(And maybe if we do want to recommend a retry then we need to be clear
that if an answer comes from an earlier query that the resolver may
accept it?)


It's sounding like people don't like the mention of a time at all. 
Proposed replacement:


If a priming query does not get a response within a short time, the 
recursive resolver needs to retry the query with a different target 
address from the configuration.


(I am avoiding saying "within a configured time" because I don't think 
this is easily configured in some common recursors.)



Second, a possible additional security consideration is that a priming
query typically signals a resolver starting with an empty cache
(although not always - the Knot resolver has a persistent cache, for
example). This may be an especially vulnerable time for a resolver for
cache poisoning. I don't know what can be done to mitigate this though
aside from requiring TCP or DNS cookies for a time after startup, so
perhaps this can be left out.


Proposed wording:

An on-path attacker who sees a priming query coming from a resolver can 
inject false answers before a root server can give correct answers. If 
the attacker's answers are accepted, this can set up the ability to give 
further false answers for future queries to the resolver. False answers 
for root servers are more dangerous than, say, false answers for TLDs 
because the root servers are the highest node of the DNS.


--Paul Hoffman

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Andreas Gustafsson]

On Wednesday, Paul Hoffman wrote:
> > The "2 seconds" seems a bit arbitrary.
> 
> Yep. But...
> 
> > I'm not sure why any
> > recommendations need to be made at all. The document already says that
> > these are basically normal DNS queries elsewhere - surely that is 
> > enough?
> 
> The queries are normal, but the reliance on them is not. Without 
> priming, nothing can be answered, so that makes them kinda special.

It's not necessarily the case that nothing can be answered.
Resolvers can and do resolve user queries using the configured root
servers while priming is in progress.

There is nothing wrong with existing resolvers that use the same
timeout and retransmission strategies for priming queries as for any
other query, and it seems wrong to me that a specific retransmission
timeout should be required for some queries but not others.
-- 
Andreas Gustafsson, g...@araneus.fi

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Bob Harold]

On Wed, Aug 10, 2016 at 8:38 PM, Paul Hoffman  wrote:

> On 5 Aug 2016, at 2:45, Shane Kerr wrote:
>
> All,
>>
>> At 2016-08-04 20:03:35 -0400
>> Tim Wicinski  wrote:
>>
>> Remember the Resolver Priming draft? This thing has been kicking around
>>> for a good solid 5 years. It stalled for a few years waiting for the
>>> busy authors perform some updates.
>>> Then Paul Hoffman took the reins and has done a great job getting this
>>> ready for publication.
>>>
>>
>> w00t
>>
>> I like this document, and am happy that it is moving again. :)
>>
>
BH:  I also like the document!

>
>> This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-prim
>>> ing
>>>
>>> Current versions of the draft is available here:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
>>>
>>> Please review the draft and offer relevant comments. Also, if someone
>>> feels the document is *not* ready for publication, please speak out with
>>> your reasons.
>>>
>>
>> I have two minor comments, which may not require any changes.
>>
>>
>> First, we have:
>>
>>   "If a priming query does not get a response within 2 seconds, the
>>   recursive resolver SHOULD retry with a different target address from
>>   the configuration."
>>
>> The "2 seconds" seems a bit arbitrary.
>>
>
> Yep. But...
>
> I'm not sure why any
>> recommendations need to be made at all. The document already says that
>> these are basically normal DNS queries elsewhere - surely that is enough?
>>
>
> The queries are normal, but the reliance on them is not. Without priming,
> nothing can be answered, so that makes them kinda special.


It seems unnecessary to say much here, trying each of the NS records, and
retrying multiple times, should be 'normal' although the details will be
implementation dependent.  Also related is what to do if none of the
servers respond, but again that is application dependent and we don't want
to go down that trail.

>
>
> (And maybe if we do want to recommend a retry then we need to be clear
>> that if an answer comes from an earlier query that the resolver may
>> accept it?)
>>
>
> That would be a radical shift. Instead, how about "If a priming query does
> not get a response within a short period (for example, 2 seconds), ..."?
>
> Second, a possible additional security consideration is that a priming
>> query typically signals a resolver starting with an empty cache
>> (although not always - the Knot resolver has a persistent cache, for
>> example). This may be an especially vulnerable time for a resolver for
>> cache poisoning. I don't know what can be done to mitigate this though
>> aside from requiring TCP or DNS cookies for a time after startup, so
>> perhaps this can be left out.
>>
>
> Priming queries happen both when there is an empty cache and at timeout of
> the root records. Unless we know for sure what the ratio between those two
> are, I'm hesitant to put anything in the document saying that it is
> "common".


Priming queries happen 1) at startup, 2) when cache is emptied (by rndc
flush for example), 3) when the TTL's expire, and 4) when the server
decides to prefetch.  Perhaps there are others, but in every case there are
the same security concerns - an attacker can:  a) inject malicious data, or
b) block valid data from reaching the server.  The first 'owns' the server,
the second disables it.


>
>
> --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] Working Group Last Call draft-ietf-dnsop-resolver-priming

[william manning]

re the 2 second timeout.

perhaps timeout does not express the intent well.  I think of most of the
DNS timeout options to be effectively hold-down timers - to be used to
prevent excessive "chatty" behaviours.

/W

On Fri, Aug 5, 2016 at 2:45 AM, Shane Kerr 
wrote:

> All,
>
> At 2016-08-04 20:03:35 -0400
> Tim Wicinski  wrote:
>
> > Remember the Resolver Priming draft? This thing has been kicking around
> > for a good solid 5 years. It stalled for a few years waiting for the
> > busy authors perform some updates.
> > Then Paul Hoffman took the reins and has done a great job getting this
> > ready for publication.
>
> w00t
>
> I like this document, and am happy that it is moving again. :)
>
> > This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-
> priming
> >
> > Current versions of the draft is available here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
> >
> > Please review the draft and offer relevant comments. Also, if someone
> > feels the document is *not* ready for publication, please speak out with
> > your reasons.
>
> I have two minor comments, which may not require any changes.
>
>
> First, we have:
>
>   "If a priming query does not get a response within 2 seconds, the
>   recursive resolver SHOULD retry with a different target address from
>   the configuration."
>
> The "2 seconds" seems a bit arbitrary. I'm not sure why any
> recommendations need to be made at all. The document already says that
> these are basically normal DNS queries elsewhere - surely that is enough?
> (And maybe if we do want to recommend a retry then we need to be clear
> that if an answer comes from an earlier query that the resolver may
> accept it?)
>
>
> Second, a possible additional security consideration is that a priming
> query typically signals a resolver starting with an empty cache
> (although not always - the Knot resolver has a persistent cache, for
> example). This may be an especially vulnerable time for a resolver for
> cache poisoning. I don't know what can be done to mitigate this though
> aside from requiring TCP or DNS cookies for a time after startup, so
> perhaps this can be left out.
>
> Cheers,
>
> --
> Shane
>
> ___
> 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] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Shane Kerr]

All,

At 2016-08-04 20:03:35 -0400
Tim Wicinski  wrote:

> Remember the Resolver Priming draft? This thing has been kicking around 
> for a good solid 5 years. It stalled for a few years waiting for the 
> busy authors perform some updates.
> Then Paul Hoffman took the reins and has done a great job getting this 
> ready for publication.

w00t

I like this document, and am happy that it is moving again. :)
 
> This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-priming
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
> 
> Please review the draft and offer relevant comments. Also, if someone 
> feels the document is *not* ready for publication, please speak out with 
> your reasons.

I have two minor comments, which may not require any changes.


First, we have:

  "If a priming query does not get a response within 2 seconds, the
  recursive resolver SHOULD retry with a different target address from
  the configuration."

The "2 seconds" seems a bit arbitrary. I'm not sure why any
recommendations need to be made at all. The document already says that
these are basically normal DNS queries elsewhere - surely that is enough? 
(And maybe if we do want to recommend a retry then we need to be clear
that if an answer comes from an earlier query that the resolver may
accept it?)


Second, a possible additional security consideration is that a priming
query typically signals a resolver starting with an empty cache
(although not always - the Knot resolver has a persistent cache, for
example). This may be an especially vulnerable time for a resolver for
cache poisoning. I don't know what can be done to mitigate this though
aside from requiring TCP or DNS cookies for a time after startup, so
perhaps this can be left out.

Cheers,

--
Shane


pgpl3Vpd0FiUV.pgp
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Tim Wicinski]

All

Remember the Resolver Priming draft? This thing has been kicking around 
for a good solid 5 years. It stalled for a few years waiting for the 
busy authors perform some updates.
Then Paul Hoffman took the reins and has done a great job getting this 
ready for publication.


This starts a Working Group Last Call  for draft-ietf-dnsop-resolver-priming

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.


This starts a two week Working Group Last Call process, and ends on 19 
August, 2016


thanks
tim

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