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

2016-10-10 Thread 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

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

2016-10-10 Thread 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 pr

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

2016-10-10 Thread 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/d

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

2016-10-10 Thread 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-

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

2016-10-10 Thread 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 coul

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

2016-10-10 Thread 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

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

2016-10-10 Thread 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 ver

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

2016-10-10 Thread 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

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

2016-10-10 Thread 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 aski

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

2016-10-10 Thread 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 sectio

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

2016-10-10 Thread 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 documentati

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

2016-10-10 Thread 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

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

2016-10-10 Thread 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 t

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

2016-10-10 Thread Roy Arends
On 10 Oct 2016, at 21:39, Mark Andrews wrote: > > > 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 pr

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

2016-10-10 Thread Mark Andrews
In message <0be787cd-3877-48c0-8bf9-3e15f605d...@dnss.ec>, Roy Arends writes: > On 10 Oct 2016, at 21:39, Mark Andrews wrote: > >=20 > >=20 > > In message , Roy Arends = > writes: > >> Having read the draft > >>=20 > >> How does one distinguish a Empty Non-Terminal NODATA response from an > >> NX

Re: [DNSOP] Special Use Names Summary

2016-10-10 Thread 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 > p