Re: [DNSOP] Special Use Names Summary

[joel jaeggli]

On 10/7/16 1:56 PM, Tim Wicinski wrote:
> 
> 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.

Thank you  for doing this, sieving the discussion  on the adoption was
no small effort.

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

We have previously sent liason statements to ICANN to make them aware of
this work. Personally I would expect that a future liaison statement on
outcomes would need to be supported by an ietf consensus call so I look
to us being able to offer guidance for such a statement.

> Thanks
> 
> Tim/Suzanne
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




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

Re: [DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse

[Mark Andrews]

In message , Roy Arends writes:
> Having read the draft
>
> How does one distinguish a Empty Non-Terminal NODATA response from an
> NXDOMAIN response, solely by looking at the NSEC or NSEC3 records.

NSEC:  Find the NSEC record that proves that there are no records
at the given name (note all of the owner, the next domain name and
the bit map need to be examined to do this).  It either the owner
name or the next domain name of that record are a subdomain of the
given name then it is a ENT otherwise it is a NXDOMAIN.

> There is an attack vector where an RCODE0 can be replaced by RCODE3 while
> keeping the rest of the response completely intact, causing an aggressive
> use enabled cache to deny existing records.
>
> These kind of subtleties arent described in the draft, as far as I can
> tell.
>
> Roy
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

[DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse

[Roy Arends]

Having read the draft…

How does one distinguish a Empty Non-Terminal NODATA response from an NXDOMAIN 
response, solely by looking at the NSEC or NSEC3 records. 

There is an attack vector where an RCODE0 can be replaced by RCODE3 while 
keeping the rest of the response completely intact, causing an aggressive use 
enabled cache to deny existing records.

These kind of subtleties aren’t described in the draft, as far as I can tell. 

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

[Tony Finch]

John Levine  wrote:
> >Should we treat synthesis as if the cache is pretending to be an
> >authoritative server?
>
>
> Yes, although it's kind of subtle.

Yep, that's kind of why I am suggesting a more detailed spec but also
trying to leave as much as possible to the existing intricate
documentation.

>  For example, I query for
> a.h.g.iana.fail:
[snip]
> You can see that the wildcard is *.h.g.iana.fail.
>
> But query for e.h.g.iana.fail:
>
> ;; ANSWER SECTION:
> e.h.g.iana.fail.3600IN  A   2.2.2.2
> e.h.g.iana.fail.3600IN  RRSIG   A 8 4 3600
>   2016121100
> 20161010180056 31806 iana.fail.
>
> You can see that it's synthesized from a wildcard, but you can't tell
> whether the wildcard was
> *.iana.fail or *.g.iana.fail or *.h.g.iana.fail.

Ah, but that is what the label count (4) is for in the RRSIG A. The
QNAME has 5 labels so you know the RRSIG belongs to *.h.g.iana.fail, and
you have to work this out in order to validate it.

> That's OK, and I believe it is straightforward for a cache to tell
> what names it can synthesize and what names it can't, but it means
> it'd probably be a good idea to make it clear that if there are other
> names in the wildcard's range, the cache often can't synthesize
> results.

And the rules for authoritative servers say which records you have to
put in the answer, so I think it is enough for the cache to check that
it already has the right ones.

In your examples, the first NSEC covered *.h.g to b.h.g proving that
a.h.g did not exist and could be the result of wildcard expansion. In
the second query, e.h.g is outside that NSEC's range, so although the
cache knows it e.h.g is a candidate for wildcard synthesis, it
doesn't have the nonexistence proof, so it has to query upstream. And
it knows what nonexistence proof it needs from the rules for
authoritative answers.

I think something that might need saying (it probably isn't in the
existing specs) is that the validator should cache the wildcard record
that it retconned from the answer (*.h.g in this example). Or maybe it
is obvious from the fact that it is being used for synthesis :-)

Tony (sorry this is a bit vague and off the cuff).
--
f.anthony.n.finch    http://dotat.at/  -  I xn--
  zr8h punycode

___
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

[John Levine]

>Should we treat synthesis as if the cache is pretending to be an
>authoritative server?
>
>e.g. for wildcards and NSEC3, something like,
>
>   When synthesizing a wildcard response from its cache, the
>   validating resolver MUST include all the records specified in
>   RFC 5155 section 7.2.5 (for negative responses) or section 7.2.6
>   (for positive responses). That is, it MUST generate a response
>   that matches what an authoritative server would send. If the
>   required records are not present in the cache, the resolver SHALL
>   query upstream instead of synthesizing the response.

Yes, although it's kind of subtle.  For example, I query for a.h.g.iana.fail:

;; QUESTION SECTION:
;a.h.g.iana.fail.   IN  A

;; ANSWER SECTION:
a.h.g.iana.fail.3510IN  A   2.2.2.2
a.h.g.iana.fail.3510IN  RRSIG   A 8 4 3600 2016121100 
20161010180056 31806 iana.fail. 
fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c 
XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 
6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk=

;; AUTHORITY SECTION:
*.h.g.iana.fail.7110IN  NSECb.h.g.iana.fail. A RRSIG NSEC
*.h.g.iana.fail.7110IN  RRSIG   NSEC 8 4 7200 2016121100 
20161010180056 31806 iana.fail. 
iQF8nmONvtzkvDy+8QRjlRRI12+XyJ0XZG8jig/o7EJ21P/VShfE3I9W 
3E+JVnkKuYg3Wg3R4tSUSLVZKxVaL/yGSTDvI0+S4RfjNaTWoeuqb+qo 
vAw78j2TMjevWJPA+NhYjHqc6daB3b38kn5cN3vCYmAO1OR5pn+whdqN d94=
iana.fail.  3510IN  NS  sdn.iecc.com.
iana.fail.  3510IN  NS  osdn.iecc.com.
iana.fail.  3510IN  NS  light.lightlink.com.
iana.fail.  3510IN  RRSIG   NS 8 2 3600 2016121100 
20161010180056 31806 iana.fail. 
I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq 
puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va 
XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0=

You can see that the wildcard is *.h.g.iana.fail.

But query for e.h.g.iana.fail:

;; QUESTION SECTION:
;e.h.g.iana.fail.   IN  A

;; ANSWER SECTION:
e.h.g.iana.fail.3600IN  A   2.2.2.2
e.h.g.iana.fail.3600IN  RRSIG   A 8 4 3600 2016121100 
20161010180056 31806 iana.fail. 
fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c 
XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 
6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk=

;; AUTHORITY SECTION:
b.h.g.iana.fail.7061IN  NSECmx.iana.fail. A RRSIG NSEC
b.h.g.iana.fail.7061IN  RRSIG   NSEC 8 5 7200 2016121100 
20161010180056 31806 iana.fail. 
hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 
7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 
ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8=
iana.fail.  3403IN  NS  sdn.iecc.com.
iana.fail.  3403IN  NS  osdn.iecc.com.
iana.fail.  3403IN  NS  light.lightlink.com.
iana.fail.  3403IN  RRSIG   NS 8 2 3600 2016121100 
20161010180056 31806 iana.fail. 
I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq 
puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va 
XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0=

You can see that it's synthesized from a wildcard, but you can't tell whether 
the wildcard was
*.iana.fail or *.g.iana.fail or *.h.g.iana.fail.

And if I query for i.g.iana.fail:

;i.g.iana.fail. IN  A

;; ANSWER SECTION:
i.g.iana.fail.  3600IN  A   1.1.1.1
i.g.iana.fail.  3600IN  RRSIG   A 8 3 3600 2016121100 
20161010180056 31806 iana.fail. 
u3icLxUEeJ2RMuhUufrhvze8hUAEkNCKPAfVHXYlQq7D1don0l4opjI2 
Sd6fxEPKcF8ah1vtCvIewFctbXQ/HH6gviKslrJekzJcX6PQccsMtygG 
SzAr3HyWf2HfcMfDJqW2PjP5v9teB/uR7KCWGbxYogFt+sEXu77xHhqi Kug=

;; AUTHORITY SECTION:
b.h.g.iana.fail.6796IN  NSECmx.iana.fail. A RRSIG NSEC
b.h.g.iana.fail.6796IN  RRSIG   NSEC 8 5 7200 2016121100 
20161010180056 31806 iana.fail. 
hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 
7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 
ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8=
iana.fail.  3138IN  NS  sdn.iecc.com.
iana.fail.  3138IN  NS  osdn.iecc.com.
iana.fail.  3138IN  NS  light.lightlink.com.
iana.fail.  3138IN  RRSIG   NS 8 2 3600 2016121100 
20161010180056 31806 iana.fail. 
I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq 
puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va 
XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0=

I get a different synthesized answer because in this case, there's one
wildcard for *.g.iana.fail and another one for *.b.g.iana.fail.

That's OK, and I believe it is 

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Viktor Dukhovni]

On Tue, Oct 11, 2016 at 01:56:42AM +1100, Mark Andrews wrote:

> If the IETF was setting servers that went and checked DNS servers
> and informed the operators then the IETF would be in the business
> of enforcing protocols.  At this stage I don't see the IETF doing
> that nor is this document asking the IETF to do that.
> 
> The is a difference between innovation and not exercising care /
> lazyness.
> 
> Returing FORMERR because you see a EDNS flag you don't understand
> is not innovation.
> 
> Returing FORMERR because you see a EDNS option you don't understand
> is not innovation.
> 
> Returing FORMERR because you see a EDNS version you don't understand
> is not innovation.
> 
> If there was anything innovative in what I'm seeing I'd be all for
> it but there isn't.

Amen.  This draft documents widely problematic behaviour that is
seen much too often.  It is good to have it all written down in
one place.

-- 
Viktor.

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

UI

On Monday, October 10, 2016, Bob Harold  wrote:

>
> On Thu, Oct 6, 2016 at 2:53 AM, 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:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>>
>> and speak up with any final questions, concerns, etc.
>>
>> (Reading the version at https://github.com/wkumari/draft-ietf-dnsop-nsec-
> aggressiveuse in case it is different)
>
> Section "3. Problem Statement"
> The example domain includes a wildcard, but the text reads as though the
> answer to "cat.example.com" would be that is does not exist.  Should the
> wildcard be removed for this example?
>


Doh!
Yes, yes it should.
I was trying to avoid having two separate example zones, but, well,
premature optimization and all that.. The way it is now is, um, just wrong.

W




>
> --
> Bob Harold
>
>

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

[Bob Harold]

On Thu, Oct 6, 2016 at 2:53 AM, 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:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>
> and speak up with any final questions, concerns, etc.
>
> (Reading the version at
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse in case it
is different)

Section "3. Problem Statement"
The example domain includes a wildcard, but the text reads as though the
answer to "cat.example.com" would be that is does not exist.  Should the
wildcard be removed for this example?

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

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Mark Andrews]

In message 
, william manning writes:
> 
> Unfortunately we are no longer in the early days of the Internet AND the
> IETF has no business in enforcing compliance with our protocol standards.
> That's for the zone operators to do.  We are not the dns police.  Even Paul
> mocapetris has called for more innovation in the dns space.   We must not
> presume there is just one way to do things.

If the IETF was setting servers that went and checked DNS servers
and informed the operators then the IETF would be in the business
of enforcing protocols.  At this stage I don't see the IETF doing
that nor is this document asking the IETF to do that.

The is a difference between innovation and not exercising care /
lazyness.

Returing FORMERR because you see a EDNS flag you don't understand
is not innovation.

Returing FORMERR because you see a EDNS option you don't understand
is not innovation.

Returing FORMERR because you see a EDNS version you don't understand
is not innovation.

If there was anything innovative in what I'm seeing I'd be all for
it but there isn't.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] Comments on draft-ietf-dnsop-alt-tld-05

[John R Levine]

I hate to bring this up, but we might want to reconsider whether .alt
is still the best name for this hack.


May be the author of the I-D should change every occurrence of .alt by
TODO-NAME-TO-BE-DISCUSSED-LATER so we can focus on the idea and avoid
discussions about the name?


I'd think we could just note that the name is TBD in discussions about 
whether anyone would actually use a generic not-DNS TLD.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Comments on draft-ietf-dnsop-alt-tld-05

[Stephane Bortzmeyer]

On Sun, Oct 09, 2016 at 05:36:34PM -,
 John Levine  wrote 
 a message of 47 lines which said:

> I hate to bring this up, but we might want to reconsider whether .alt
> is still the best name for this hack.

May be the author of the I-D should change every occurrence of .alt by
TODO-NAME-TO-BE-DISCUSSED-LATER so we can focus on the idea and avoid
discussions about the name?

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

[DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt

[Ondřej Surý]

Dear colleagues,

this is just a refresh to keep the draft going
as we are still waiting for irtf-cfrg-eddsa, but
that looks like it's in IESG Review, so it might
be a good time to have a final look and send the
comments to /me or Robert or curdle WG mailing list.

1. https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/

Cheers,
--
 Ondřej Surý -- Technical Fellow
 
 CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:ondrej.s...@nic.czhttps://nic.cz/
 

- Forwarded Message -
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: cur...@ietf.org
Sent: Monday, 10 October, 2016 15:46:46
Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CURves, Deprecating and a Little more 
Encryption of the IETF.

Title   : EdDSA for DNSSEC
Authors : Ondrej Sury
  Robert Edmonds
Filename: draft-ietf-curdle-dnskey-eddsa-01.txt
Pages   : 8
Date: 2016-10-10

Abstract:
   This document describes how to specify EdDSA keys and signatures in
   DNS Security (DNSSEC).  It uses the Edwards-curve Digital Security
   Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-01


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/

___
Curdle mailing list
cur...@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

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

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[william manning]

Unfortunately we are no longer in the early days of the Internet AND the
IETF has no business in enforcing compliance with our protocol standards.
That's for the zone operators to do.  We are not the dns police.  Even Paul
mocapetris has called for more innovation in the dns space.   We must not
presume there is just one way to do things.

On Sunday, 9 October 2016, Mark Andrews  wrote:

>
> In message <
> caaiteh9rbw4u3gv9gulq-8wdophf3sxqmtry+ctfugrnqsg...@mail.gmail.com
> >, Matthew Pounsett writes:
> >
> > My first impression of this document is that it is still in need of some
> > extreme editing – mostly for grammar and syntax, but also for clarity and
> > readability.  I've included many of the early problems I found in a list
> > of nits at the end of this email, but at two and three errors per
> paragraph
> > (and occasionally per sentence) it's just too much to cover this way, so
> I
> > stopped noting nits after the first couple of sections.  I suggest such
> > sweeping changes to later sections that any nits I noted there may end up
> > being rewritten anyway.
> >
> > The draft still suffers from inconsistent approaches to the content.  In
> > any given section it might shift from a problem description, to
> > admonishment, to advice for workarounds, and back again without a clear
> or
> > consistent structure.  This makes it difficult to figure out what the
> > intended takeaway is in places.  I've tried to point out specifics below,
> > and suggest better approaches where I can.
> >
> > Don't let my criticism of the document give you the wrong impression.  I
> > think this is useful work, and I'm very appreciative of the work that has
> > gone into it so far.  I just happen to think that there is still work
> left
> > to be done.
> >
> >
> > As for the meat of the matter...
> >
> >
> > In the Introduction, in the paragraph which begins "Unless a nameserver
> is
> > under attack" would it make sense to replace "broken delegations" with
> > "lame delegations"?   We have a term for delegating to a name server
> which
> > is not authoritative for the delegation... we should probably use it.
>
>
>
> > Section 2, "Consequences," seems out of place to me.  It makes a number
> of
> > assertions that seem to follow no particular flow, or pattern.  The line
> > of
> > reasoning or evidence that lead to these assertions has not appeared yet
> > in
> > the document, and so they seem unsupported.  If I'm interpreting the
> > author's intent correctly, perhaps this section should be split up and
> > interspersed into the current section 3 as the direct or indirect
> > consequences of each type of dropped response.
> >
> >
> > The way section 3 is titled and introduced I expect to just see a survey
> > of
> > commonly dropped queries, but the content seems to be inconsistent as to
> > whether it's just a survey, or a survey and advice to client authors
> about
> > working around problems, or just advice without a clear description of
> the
> > problem behaviour.  It seems to me that if the section is intended to be
> > advice to authors, then it should be introduced that way.  Also,
> > clarification for server authors on how they should respond–instead of
> > dropping queries–should probably come before any advice on how to work
> > around dropped queries.
> >
> > If the goal here is to help implementors fix what's broken, then I would
> > suggest each subsection start with a clear description of an observed
> > broken behaviour, followed up with a description of how that behaviour
> > should change (possibly only as a short summary with external references,
> > as we don't want to reproduce whole RFCs here) and then follow that with
> > advice for client authors for working around existing brokenness.
> > Sticking
> > to a pattern–either the one I've suggested or some other–for every query
> > type would make the entire section easier to read.  It will also make it
> > easier for the working group to go through the section item by item and
> > discuss whether we agree on the problem descriptions and proposed
> > remediation.
> >
> > RFC 2119 language is conspicuously absent from this section and SHOULD be
> > added.
> >
> >
> > Section 4, "Remediating", is very problematic.  I think the biggest
> issues
> > stem from two false assertions:
> > 1) "TLD operators are being asked to do this as they...have access to a
> > large numbers of nameserver names as well as contact details for the
> > registrants of those nameservers."
> >
> > This is incorrect.  Or, at least, frequently incorrect.  TLD registries
> > fall into one of two categories: thick or thin.   Thick registries do
> have
> > this information, but a significant number of thin registries exist,
> which
> > delegate the responsibility for maintaining registrant contact
> information
> > to the registrar.  All thin registries know is that a delegation should
> > exist, which name servers are currently supposed to be 

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

[Tony Finch]

Warren Kumari  wrote:
>
> >
> > 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!

Thinking about wildcards makes me wonder if we need to approach this whole
idea from two directions - firstly, how the validator proves to itself
that it can synthesize a negative response or a wildcard response; and
secondly, how it can prove that it did the right thing to a downstream
validator. At the moment the draft talks about the first aspect, but not
very much the second.

Specifically,

Should we treat synthesis as if the cache is pretending to be an
authoritative server?

e.g. for wildcards and NSEC3, something like,

When synthesizing a wildcard response from its cache, the
validating resolver MUST include all the records specified in
RFC 5155 section 7.2.5 (for negative responses) or section 7.2.6
(for positive responses). That is, it MUST generate a response
that matches what an authoritative server would send. If the
required records are not present in the cache, the resolver SHALL
query upstream instead of synthesizing the response.

If this makes sense then the other cases should be adjusted to describe
things in a similar way, e.g. referring to section 7 of RFC 5155 instead
of (or as well as?) section 8, and section 3.1 instead of / as well as
section 5 of RFC 4035.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or
moderate. Showers. Good.

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