[DNSOP] (no subject)

[johnl]

>From not-for-mail  Fri Oct  7 22:00:19 2016
To: list-iecc-lists-ietf-dn...@johnlevine.com
Path: not-for-mail
Subject: Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call 
for adoption on Special Use Names
Date: Sat, 8 Oct 2016 02:00:18 + (UTC)
Organization: Taughannock Networks, Trumansburg NY
Message-ID: 
References: <20161007012033.23623.qm...@ary.lan> 
 
 
<1b1fe5e9-2708-82de-a77d-a9fc20c3a...@gnu.org>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: jo...@aryv.lan (John L)
From: John Levine 

>We have .example and example.* for documentation, yet the XMPP
>documentation uses shakespeare.lit (I don't think .lit matches any SUN
>or any entry in any DNS-related RFC.) FWIW, wikipedia sends .lit to some
>Microsoft file extension.  One cannot say that Peter St Andre is
>ignorant of IETF processes.  Use of *example* in documentation and
>.invalid in free software is a good sign that developers are ready to
>follow suit and respect the norms.

In RFC 6120, it's shakespeare.example.com and shakespeare.example.  

If you're referring to some random web site, life is too short to
enumerate all of the things that are wrong on the web.

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

Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

[Warren Kumari]

On Fri, Oct 7, 2016 at 11:54 AM, Warren Kumari  wrote:
> Okey dokey, everyone!
>
> I will be attempting to re-add, and better explain the "positive" answers bit.
> I really appreciate all of the feedback which we have received - I'm
> juggling a few plates at the moment, and so am somewhat distracted,
> but I'll try integrate them fully and in order.
>
> This will likely require some assistance / patience from the WG to
> make sure that I've worded things cleanly / clearly.

Ok everyone -- I have put back the "positive text", and have reworded
a bunch of surrounding stuff to try and make it more clear.
Unfortunately while doing this I have moved so much around that I am
having a hard time making sure that I have correctly integrated /
addressed everyones comments. The new "wildcard" text also seems
suspiciously short, but I'm having a hard time writing better text.

Basically at this point I've spent so much time staring at the same
bits of text (and shuffling it around) that my brain is dribbling out
my ears.

Please have a look and let me know if it is OK, and if not, please
suggest some text. If I've missed your comments, or somehow messed
them up, I'm truly sorry, please let me know (preferably by providing
text or using baby words!) and I'll try address them.

I was initially just going to submit to Github and ask for review
there, but reordering the sections made enough of a change (and I want
wider review) that I figured I should just publish -04.

Thank you all,
W


>
> W
>
>
> On Thu, Oct 6, 2016 at 9:47 PM, Tim Wicinski  wrote:
>>
>>
>> On 10/6/16 3:58 PM, Stephane Bortzmeyer wrote:
>>>
>>> On Thu, Oct 06, 2016 at 01:47:28PM -0400,
>>>  John R Levine  wrote
>>>  a message of 34 lines which said:
>>>
 It still seems to me that the time to add the wildcards back in
 would be less than the time to do two separate documents.  Unless
 there's some reason that this needs to be published in a hurry,
>>>
>>>
>>> Not for me, I'm fine with a delay (there have been many important
>>> changes between -02 and -03, during the WGLC, so, some time to digest
>>> and study them may be worth it).
>>>
>>
>> I agree. There is no need to hurry this along. I'd rather get this right.
>>
>> tim
>>
>>
>> ___
>> 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



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

[DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : Aggressive use of NSEC/NSEC3
Authors : Kazunori Fujiwara
  Akira Kato
  Warren Kumari
Filename: draft-ietf-dnsop-nsec-aggressiveuse-04.txt
Pages   : 15
Date: 2016-10-07

Abstract:
   The DNS relies upon caching to scale; however, the cache lookup
   generally requires an exact match.  This document specifies the use
   of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers
   to generate negative answers within a range, and positive answers
   from wildcards.  This increases performance / decreases latency,
   decreases resource utilization on both authoritative and recursive
   servers, and also increases privacy.  It may also help increase
   resilience to certain DoS attacks in some circumstances.

   This document updates RFC4035 by allowing validating resolvers to
   generate negative based upon NSEC/NSEC3 records (and positive answers
   in the presence of wildcards).

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.This document is being
   collaborated on in Github at: https://github.com/wkumari/draft-ietf-
   dnsop-nsec-aggressiveuse.  The most recent version of the document,
   open issues, etc should all be available here.  The authors
   (gratefully) accept pull requests.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] Working Group Last Call

[Tim Wicinski]

On 10/7/16 7:07 PM, Warren Kumari wrote:

DONE.
I now have:
"Use of NSEC / NSEC3 resource records without DNSSEC validation may
create serious security issues, and so this technique requires DNSSEC
validation."

I could just drop this sentence, but someone (Stephane?) wanted
reinforcement that validation is needed.


I can't find the reference but I remember folks asking to keep it in.

I honestly feel if we took it out, during the IESG review cycle, we 
would be asked to put it back in


tim

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

Re: [DNSOP] Working Group Last Call

[Warren Kumari]

On Thu, Oct 6, 2016 at 2:49 AM, Tim Wicinski  wrote:
>
>
> On 10/5/16 2:30 PM, 神明達哉 wrote:
>>
>> At Tue, 4 Oct 2016 17:39:55 -0400,
>> Warren Kumari  wrote:
>>
 - Section 3: this section also has an issue of "recursive resolver".
   Although it may not be as critical as other part of the draft since
   it's only used as an example scenario, it's probably better to not
   limit the role of resolver to avoid misleading.  Maybe "recursive
   resolver" is just changed to "validating resolver", and
   "authoritative server" is changed to, e.g., "external servers"
   (meaning either authoritative or or other recursive servers).
>>>
>>>
>>> DONE.
>>> I did some fix up - how do you like:
>>> "If a validating resolver gets a query for cat.example.com, it will
>>> query the example.com servers and will get back an NSEC (or NSEC3)
>>> record starting that there are no records between apple and elephant.
>>> The resolver then knows that cat.example.com does not exist; however,
>>> it does not use the fact that the proof covers a range (apple to
>>> elephant) to suppress queries for other labels that fall within this
>>> range. This means that if the validating resolver gets a query for
>>> ball.example.com (or dog.example.com) it will once again go off and
>>> query the example.com servers for these names."
>>>
>>> Does that cover it sufficiently? (and I think I now better understand
>>> your concern).
>>
>>
>> To be perfectly generic, "it will query the example.com servers" is
>> not always the case.  It (= validating resolver) might query another
>> intermediate resolver (often called a "forwarder") that performs
>> recursion.  By "external server" I tried to generalize the concept.
>>
>
> Maybe this?
>
> "If a validating resolver receives a query for cat.example.com, it contacts
> its resolver (which may be itself) to query the example.com servers and will
> get back an NSEC (or NSEC3) record starting that there are no records
> between apple and elephant."
>
>> I'm not sure how we address the subtlety without being overly
>> verbose.  Perhaps we can note in the terminology section that this
>> draft generally describes (validating) resolvers as those performing
>> recursive resolution, but the proposal will also work for resolvers
>> that rely on other recursive (or "full service" if you love to use
>> this term) resolvers.  And then we can keep Section 3 as is (as of ver
>> 02).
>
>
> I'm now understanding the distinction you're trying to make.  I've spent
> some time staring at 7719 and 4035 with no better suggestion.
>
>
>>> How is:
>>> "Aggressive use of NSEC / NSEC3 resource records without DNSSEC
>>> validation may create serious security issues, and so this technique
>>> requires DNSSEC validation."? I don't love it, additional suggestions
>>> or text welcomed.
>>
>>
>> To me the main point isn't address with this text.  I might be able to
>> offer alternative text, but can't we perhaps just remove these 2
>> sentences?  In a sense these talk about the obvious, and in other
>> sense it could be even harmful as it can be misleading.
>>
>
> I think you could drop the "Aggressive" and discussing NSEC/NSEC3 records
> w/out validation.  4035 is pretty clear on that

DONE.
I now have:
"Use of NSEC / NSEC3 resource records without DNSSEC validation may
create serious security issues, and so this technique requires DNSSEC
validation."

I could just drop this sentence, but someone (Stephane?) wanted
reinforcement that validation is needed.

W


>
> tim
>



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

[Warren Kumari]

On Fri, Oct 7, 2016 at 12:22 PM, 神明達哉  wrote:
> At Thu, 6 Oct 2016 02:49:34 -0400,
> Tim Wicinski  wrote:
>
>> >> I did some fix up - how do you like:
>> >> "If a validating resolver gets a query for cat.example.com, it will
>> >> query the example.com servers and will get back an NSEC (or NSEC3)
>> >> record starting that there are no records between apple and elephant.
> [...]
>> >> Does that cover it sufficiently? (and I think I now better understand
>> >> your concern).
>> >
>> > To be perfectly generic, "it will query the example.com servers" is
>> > not always the case.  It (= validating resolver) might query another
>> > intermediate resolver (often called a "forwarder") that performs
>> > recursion.  By "external server" I tried to generalize the concept.
>>
>> Maybe this?
>>
>> "If a validating resolver receives a query for cat.example.com, it
>> contacts its resolver (which may be itself) to query the example.com
>> servers and will get back an NSEC (or NSEC3) record starting that there
>> are no records between apple and elephant."
>
> Yes, this is one way to address my point.  I'd leave it to the authors
> specifically how to address it.

Great.
DONE.


>
> --
> JINMEI, Tatuya



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

[Warren Kumari]

On Tue, Oct 4, 2016 at 8:06 AM, Matthijs Mekking  wrote:
> All,
>
> I reviewed this draft and while it is shaping up nicely, I don't think it is
> quite ready for publication:
>
> 1. As John pointed out earlier, the document makes an inconsistent use of
> RFCC 2119 keywords, and we need to decide whether to use MAY or SHOULD.
> Looking at the definitions of the keywords again I am leaning towards MAY,
> but given the described benefits I could see how SHOULD would be
> appropriate. Either way, it should be consistent. Also, the used keyword for
> NSEC should not be different than that for NSEC3.

Ok, I *think* that I have this correct, but it MAY still be muddled. :-)

>
> 2. In addition to the first point, I don't think it is appropriate to use
> RFC 2119 keywords to dictate name server configuration. Mentioning it would
> be useful to have configuration options for enabling and disabling this
> functionality seems okay, but drop the RFC 2119 formalities.

I think that we came to agreement further down-thread that it is OK to
have this. If you disagree with this, please provide some text
>
> 3. In section 6 on Benefits, it says "currently around 65% of queries to
> Root Name servers result in NXDOMAIN responses." This is quickly outdated,
> so I would replace 'currently' with 'at the time of writing'. But more
> importantly, where does this number come from? A reference here seems
> appropriate.

Good point on the "currently". I put in a reference to
www.root-servers.org. Many letters are posting RSSAC-002 data - I took
a few days statistics and calculated the average from this.


>
> 4. There are several bikeshedding issues/nits that I have put up a PR for
> here:
>
>   https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/1

Thank you. I incorporated those.

>
> 5. It seems that sections 5.2 and 5.3 only consider NXDOMAIN responses. Is
> it perhaps that at the end of section 5.1 NODATA answers are covered?
> I would suggest a better structure to make more explicit the scope.
> Currently it reads as if NODATA answers should always be subject to
> aggressive use of negative cache, while NXDOMAIN answers only if the
> configuration option enables it.
>
> Given these remarks, I suggest the following structure and text:
>
>   If the negative cache of the validating resolver has sufficient
>   information to validate the query, the resolver MAY use NSEC, NSEC3
>   and wildcard records aggressively. Otherwise, it MUST fall back to
>   send the query to the authoritative DNS servers.
>
>   It is recommended that resolvers that implement Aggressive Use of
>   Negative Caching provide a configuration switch to disable the
>   feature. Separate configuration switches can be implemented for
>   the aggressive use of NSEC, NSEC3 and wildcard records.
>
>   5.2 NSEC
>
>   5.2.1 No Data
>
>   If the query has an NSEC record matching the query name, proving
>   the data requested does not exist, the resolver MAY respond with an
>   empty NOERROR (No Data) answer.
>
>   5.2.2 Name Error
>
>   If the resolver has an NSEC record covering the source of synthesis
>   and an NSEC record covering the query name, it MAY respond with an
>   NXDOMAIN answer.
>
>   5.2.3 Wildcard No Data
>
>   If the resolver has an NSEC record matching the source of synthesis
>   and an NSEC record covering the query name, it MAY respond with an
>   empty NOERROR (No Data) answer.
>
>   5.2.3 Wildcard Answer
>
>   If the resolver has an NSEC record covering the query name, but no
>   NSEC record matching the source of synthesis, it MAY respond with an
>   wildcard expanded answer from the cache. If the corresponding
>   wildcard record is not in the cache, it MUST fall back to send the
>   query to the authoritative DNS servers.
>
>   5.2 NSEC3
>
>   ...
>
>
> A similar layout for NSEC3 should be provided, and I am willing to provide
> that if this layout is accepted.

So, I have incorporated a number of changes around this section, and
much of it has been rewritten. I *think* that this is now clearer, and
covers your concern -- however, I've been staring at the same text for
many hours, and shuffling text back and forth, and so I may simply be
confused. Please let me know if you still think it needs changing.
W


>
> Best regards,
>   Matthijs
>
>
> On 22-09-16 14:19, Tim Wicinski wrote:
>>
>> All
>>
>> This draft has been worked on and it seems that the Working Group is
>> happy with the updates that have been made and I feel it's ready for the
>> next step.
>>
>> This starts a Working Group Last Call for:
>> "Aggressive use of NSEC/NSEC3"
>>   draft-ietf-dnsop-nsec-aggressiveuse
>>
>> Current versions of the draft is available here:
>>https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>
>> 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.
>>
>> It's 

[DNSOP] Special Use Names Summary

[Tim Wicinski]

Special Use Names Summary


First, thanks to all for a pretty useful discussion.  There were a few 
things uncovered which are not in either draft.  It does appear that the 
draft-tldr-sutld-ps is the very rough consensus choice as a starting 
point. Both drafts say useful things, and the chairs would very much 
like to see people keep working to get all relevant points into one. The 
scoping question of choosing between “What do we think of RFC 6761” and 
“What underlying problem do we actually have” came up quite clearly, and 
seemed like a key factor to us.


The chairs felt that a limited scope draft was possible, and what we 
were looking for. Even with a limited scope draft, we've found we can't 
ignore questions about the underlying assumptions behind 6761, both 
because they're not fully articulated and because they may not include 
several cases we care about. For example:
- what problem do we have because we value uniqueness in domain 
names as an architectural principle, regardless of specific strings chosen?
- what problem exists for the IETF even if we say we don’t care 
what other groups (ICANN, the Tor Project, open source creators) do?

- what happens if we abandon this work, or deprecate RFC 6761?

There are also several items which need clarifying, which the WG 
discussion may also include and the chairs will work on with the IESG 
and the IAB as appropriate.


- Describing, as much as possible, how this work interlocks with 
ICANN’s policy authority over the DNS root zone

- Providing guidelines for IETF WGs
- Providing guidelines for domain name use outside of the IETF
disposing of some distractions that keep coming up
- Clarifying, to the degree possible, who has process authority 
over what (IESG, IAB, this WG, other IETF WGS)


Thanks

Tim/Suzanne

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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[hellekin]

On 10/07/2016 06:36 PM, Alain Durand wrote:
> 
> However, there is something that can be done before: provide a safe place
> in the DNS tree where people can exist without colliding with the rest of
> the tree. We can't prevent people from ignoring it and keep using whatever
> name they want, but at least we would have provided a way to play nice. In
> that spirit, efforts like .alt and friends are a step in the right direction.
> 

We have .example and example.* for documentation, yet the XMPP
documentation uses shakespeare.lit (I don't think .lit matches any SUN
or any entry in any DNS-related RFC.) FWIW, wikipedia sends .lit to some
Microsoft file extension.  One cannot say that Peter St Andre is
ignorant of IETF processes.  Use of *example* in documentation and
.invalid in free software is a good sign that developers are ready to
follow suit and respect the norms.

==
hk

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

Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Warren Kumari]

On Thu, Oct 6, 2016 at 12:32 PM, Stephane Bortzmeyer  wrote:
> On Thu, Oct 06, 2016 at 02:53:38AM -0400,
>  Tim Wicinski  wrote
>  a message of 17 lines which said:
>
>> Just a reminder that the WGLC for
>> draft-ietf-dnsop-nsec-aggressiveuse will end later today (barring
>> any stuck issues).  The authors appear to have addressed all open
>> issues
>
> The way I understand it, in -03, there is no more *positive* answers
> (NOERROR synthetized from a wildcard in the cache), only negative ones
> (NXDOMAIN). Am I correct? (If so, I agree with the change.)

Yes, you *were* correct -- however, since then the WG has demanded^w
requested that we re-introduce the positive answer text, and so I have
just committed that to Github.
I have not yet, however, incorporated your original text fixup, I'll
do that now...

W

>
> If this is true, then I would suggest some work on rewriting section 7
> new text for updating RFC 4035. True, the cache needs to look at
> wildcards to see if it can synthetize NXDOMAINs or not but the way it
> is written, it is confusing, since a wildcard would *prevent*
> synthesis. May be:
>
>Once the records are validated, DNSSEC enabled validating
>resolvers MAY use NSEC/NSEC3 resource records
>to generate negative responses until their effective TTLs
>or signatures for those records expire. (This requires to also
>check there is no wildcard applicable for the QNAME.)
>
> ___
> 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] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Warren Kumari]

On Thu, Oct 6, 2016 at 7:18 AM, Tony Finch  wrote:
> I have read through the draft and sent a pull request with some minor
> editorial fixes.

Thank you. These have been accepted / incorporated.

>
> Here are some more substantial suggestions / questions. Sorry for being so
> late in the process.
>

No apologies needed, thanks for feedback.

>
> Would it make sense to be more specific about how to match queries to"
> cached NSEC/NSEC3 records? By cross-referencing to the relevant part of
> the NSEC and NSEC3 specs, rather than repeating.

Yup!

>
> The draft seems to imply that only one NSEC record is needed for denial of
> existence, and that wildcards are only problematic for NSEC3 - but
> wildcards can also trip up NSEC, if the covering NSEC does not also cover
> a relevant wildcard.
>
> eg (modified text) ...
>
> 5.1.  NSEC
>
>Implementations which support aggressive use of NSEC SHOULD enable
>this by default.  Implementations MAY provide a configuration switch
>to disable aggressive use of NSEC and allow it to be enabled or
>disabled per domain.
>
>The validating resolver needs to check the existence of an NSEC RR
>matching/covering the source of synthesis and an NSEC RR covering the
>query name.
>
>If denial of existance can be determined according to the rules set out
>in RFC 4035 section 5.4, using NSEC records in the cache, then the
>resolver can immediately return an NXDOMAIN or NODATA response.

DONE.
Thank you for providing text. It certainly makes it easier to
understand / address comments.


>
> 5.2.  NSEC3
>
>A validating resolver implementation MAY support aggressive use of
>NSEC3.  If it does aggressive use of NSEC3, it MAY provide a
>configuration switch to disable aggressive use of NSEC3 and allow it
>to be enabled or disabled for specific zones.
>
>NSEC3 aggressive negative caching is more difficult.  If the zone is
>signed with NSEC3, the validating resolver needs to check the
>existence of non-terminals and wildcards which derive from query
>names.
>
>If denial of existance can be determined according to the rules set out
>in RFC 5155 sections 8.4, 8.5, 8.6, 8.7,, using NSEC3 records in the
>cache, then the resolver can immediately return an NXDOMAIN or NODATA
>response.

DONE.
Thank you -- I reordered / reworded things slightly to make it flow
somewhat better, but it is basically still your text.

>
>
> TTLs
>
> Both NSEC and NSEC3 records are supposed to have a TTL matching the SOA
> MINIMUM field. This is not quite the same as RFC 2308 negative cache entry
> TTL, which is the minimum of the SOA MINIMUM and SOA TTL.
>
> Should there be text along the lines of:

... probably :-)

>
> 5.3.  Consideration on TTL
>
>The TTL value of negative information is especially important,
>because newly added domain names cannot be used while the negative
>information is effective.
>
>Section 5 of RFC 2308 states that the maximum number of negative cache
>TTL value is 3 hours (10800).  It is RECOMMENDED that validating
>resolvers limit the maximum effective TTL value of negative responses
>(NSEC/NSEC3 RRs) to this same value.
>
>Section 5 of RFC 2308 also states that a negative cache entry TTL
>is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
>This can be less than the TTL of an NSEC or NSEC3 record, since their
>TTL is equal to the SOA.MINIMUM field. (See RFC 4035 section 2.3 and
>RFC 5155 section 3.)
>
>A resolver that supports aggressive use of NSEC and NSEC3 should reduce
>the TTL of NSEC and NSEC3 records to match the TTL of the SOA record in
>the authority section of a negative response, if the SOA TTL is
>smaller.

DONE.
This is great. I used your text, thank you.

>
> Wildcards
>
> Should the box in section 7 say "positive responses" instead of "negative
> responses"?
>
> If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4
> and RFC 5155 section 8.8 which both discuss validating positive wildcard
> responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide
> text if you want.

NOT DONE.
Yes please. That would be awesome!
I had removed Section 7 (Wildcards) because I thought that that was
what the WG wanted, but I apparently misjudged that. I have now put it
back, and tried to reconcile the positive and negative test, but do
not have any text like the above. I'd really appreciate some!

I have put beck the original Wildcard text, and am committing it to
GitHub. I will then try address the original wording issues which made
me remove it in the first place...

>
>
> Security Considerations
>
> This should mention the impact of replay attacks. Something like,
>
> Although the TTL of NSEC/NSEC3 records is typically fairly short
> (minutes or hours), their RRSIG expiration time can be much
> further in the future (weeks). An attacker who is able to
>

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag

[神明達哉]

At Thu, 6 Oct 2016 03:00:36 -0400,
Tim Wicinski  wrote:

> The authors for this document have addressed some lingering  outstanding
> issues, and it appears ready for Working Group Last Call.
>
> This starts a Working Group Last Call for:
> draft-ietf-dnsop-edns-key-tag
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/
>
> 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've read the 03 version of the draft.  I think it's basically ready
for publication.  However, I have two new points to discuss, which may
result in some non-trivial updates (although they may not be
substantial to warrant another WGLC).

1. regarding recursive resolvers (4.2.2.1), I wonder whether we
   want to explicitly note that the recursive servers MUST NOT (I
   think) forward a DNSKEY query with an EDNS key tag option when it
   already has it in the cache simply because the set of key tags in
   the originally query is different from its own set of key tags.

2. regarding the following note in Section 5.3:

   [ Note RFC1035 says NULL
   RRs are not allowed in master files, but I believe that to be
   incorrect ]

  perhaps we should officially update RFC1035 and clarify that NULL is
  now allowed in master files?  Even if the usage in the authoritative
  side (such as the example shown in Section 5.3.1) is not a normative
  part of this draft, the use of NULL RR is, and so it would be better
  to assure such configuration won't be considered a non-compliant
  setting.

--
JINMEI, Tatuya

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

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

[Alain Durand]

> On Oct 7, 2016, at 6:51 AM, John Levine  wrote:
> 
> f someone creates popular software leaking requests for
> .PICKLE, we can grouse all we want but since we're not the Network
> Police, there's not much we can do about it.

There is not much that can be done after the fact, I agree. However, there is 
something that can be done before: provide a safe place in the DNS tree where 
people can exist without colliding with the rest of the tree. We can't prevent 
people from ignoring it and keep using whatever name they want, but at least we 
would have provided a way to play nice. In that spirit, efforts like .alt and 
friends are a step in the right direction.

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

Re: [DNSOP] Working Group Last Call on "Aggressive use of NSEC/NSEC3"

[Matthijs Mekking]

Warren,

On 04-10-16 18:56, Warren Kumari wrote:

On Thu, Sep 22, 2016 at 11:04 AM, John Levine  wrote:

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 think it's ready to publish with one small caveat.  In section 5.1,
the text in the box says "resolvers MAY use NSEC/NSEC3 resource
records" and the text in the next paragraph says "the resolver SHOULD
use NSEC/NSEC3/wildcard records".  There's a similar MAY in the box in
section 7.

The authors SHOULD make up their minds.  Assuming they really believe
this is a good idea, change the MAY's to SHOULD.


Doh. Thanks.
This was simply sloppiness on my part.

(my editor shows pre-formatted / figure text on a yellow background,
and my eye's now assume that that is protocol layout, so I skip over
it :-)).
Fixed and pushed to repo in
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/tree/12b2d9d46a50502e20d33cfa8f2db89ccb6dadff
- will publish new version with these integrated soon.


To summarize my things:

1. Inconsistent SHOULD and MAY.
2. Get rid of RFC 2119 keywords for configuration recommendations.
3. Reference for "currently around 65% of queries to Root Name servers 
result in NXDOMAIN responses." (and replace currently with "at the time 
of writing")

4. The PR
5. Rewording sections 5.2 and 5.3 by either a repeating exercise (see 
suggested text, or cross-referencing (see Tony's mail).


I think points 2, 3, and 5 were not yet addressed.

Best regards,
  Matthijs





W




R's,
John

___
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] Looking for IANA registry for --xn

[Robert Edmonds]

Jim Reid wrote:
> > On 7 Oct 2016, at 03:33, Phillip Hallam-Baker  wrote:
> > 
> > Protocol matters. And just because IANA does 'assignments' that are not 
> > 'registrations' doesn't mean that is right or should continue.
> 
> I’m sure the RIRs and the hundreds of millions of people who are using IP 
> addresses because of IANA ‘assignments’ will be delighted to hear that.

Is the "IANA IPv4 Address Space Registry" not a registry?

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

-- 
Robert Edmonds

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

Re: [DNSOP] Working Group Last Call

[神明達哉]

At Thu, 6 Oct 2016 02:49:34 -0400,
Tim Wicinski  wrote:

> >> I did some fix up - how do you like:
> >> "If a validating resolver gets a query for cat.example.com, it will
> >> query the example.com servers and will get back an NSEC (or NSEC3)
> >> record starting that there are no records between apple and elephant.
[...]
> >> Does that cover it sufficiently? (and I think I now better understand
> >> your concern).
> >
> > To be perfectly generic, "it will query the example.com servers" is
> > not always the case.  It (= validating resolver) might query another
> > intermediate resolver (often called a "forwarder") that performs
> > recursion.  By "external server" I tried to generalize the concept.
>
> Maybe this?
>
> "If a validating resolver receives a query for cat.example.com, it
> contacts its resolver (which may be itself) to query the example.com
> servers and will get back an NSEC (or NSEC3) record starting that there
> are no records between apple and elephant."

Yes, this is one way to address my point.  I'd leave it to the authors
specifically how to address it.

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

[Warren Kumari]

Okey dokey, everyone!

I will be attempting to re-add, and better explain the "positive" answers bit.
I really appreciate all of the feedback which we have received - I'm
juggling a few plates at the moment, and so am somewhat distracted,
but I'll try integrate them fully and in order.

This will likely require some assistance / patience from the WG to
make sure that I've worded things cleanly / clearly.

W


On Thu, Oct 6, 2016 at 9:47 PM, Tim Wicinski  wrote:
>
>
> On 10/6/16 3:58 PM, Stephane Bortzmeyer wrote:
>>
>> On Thu, Oct 06, 2016 at 01:47:28PM -0400,
>>  John R Levine  wrote
>>  a message of 34 lines which said:
>>
>>> It still seems to me that the time to add the wildcards back in
>>> would be less than the time to do two separate documents.  Unless
>>> there's some reason that this needs to be published in a hurry,
>>
>>
>> Not for me, I'm fine with a delay (there have been many important
>> changes between -02 and -03, during the WGLC, so, some time to digest
>> and study them may be worth it).
>>
>
> I agree. There is no need to hurry this along. I'd rather get this right.
>
> tim
>
>
> ___
> 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] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Warren Kumari]

On Fri, Oct 7, 2016 at 11:55 AM, Warren Kumari  wrote:
> On Thu, Oct 6, 2016 at 3:38 AM, Matthijs Mekking  
> wrote:
>> Hi,
>>
>> On 06-10-16 08:53, Tim Wicinski wrote:
>>>
>>> Just a reminder that the WGLC for  draft-ietf-dnsop-nsec-aggressiveuse
>>> will end later today (barring any stuck issues).  The authors appear to
>>> have addressed all open issues (except JINMEI's last comments).  Please
>>> read the current version here:
>>
>> I don't think my issues have been addressed in -03, except for the
>> bikeshedding Pull Request has been merged.
>
> Whoops, I got so excited by the pull req

( apparently *really* excited, because I sent this before
finishing the reply!. Continuing)

Whoops, I got so excited by the pull request that I skipped over the
rest of your mail :-)
I had removed the positive responses bit, but the WG seems to still
want it, so I'll be re-adding it. I think that that voids your
comment, but *please* let me know if I'm wrong -- I *hope* to publish
a new version later today, or possibly Sunday.

W

>
>>
>> Best regards,
>>   Matthijs
>>
>>
>>
>>
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>>
>>> and speak up with any final questions, concerns, etc.
>>>
>>> thanks
>>> tim
>>>
>>> ___
>>> 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
>
>
>
> --
> 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



-- 
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] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Warren Kumari]

On Thu, Oct 6, 2016 at 3:38 AM, Matthijs Mekking  wrote:
> Hi,
>
> On 06-10-16 08:53, Tim Wicinski wrote:
>>
>> Just a reminder that the WGLC for  draft-ietf-dnsop-nsec-aggressiveuse
>> will end later today (barring any stuck issues).  The authors appear to
>> have addressed all open issues (except JINMEI's last comments).  Please
>> read the current version here:
>
> I don't think my issues have been addressed in -03, except for the
> bikeshedding Pull Request has been merged.

Whoops, I got so excited by the pull req

>
> Best regards,
>   Matthijs
>
>
>
>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>
>> and speak up with any final questions, concerns, etc.
>>
>> thanks
>> tim
>>
>> ___
>> 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



-- 
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] Looking for IANA registry for --xn

[Jim Reid]

> On 7 Oct 2016, at 03:33, Phillip Hallam-Baker  wrote:
> 
> Protocol matters. And just because IANA does 'assignments' that are not 
> 'registrations' doesn't mean that is right or should continue.

I’m sure the RIRs and the hundreds of millions of people who are using IP 
addresses because of IANA ‘assignments’ will be delighted to hear that.

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