Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption"

On Tue, Jul 04, 2017 at 04:42:21AM -0700, IETF Secretariat wrote a message of 11 lines which said: > The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state > Candidate for WG Adoption Did anyone was brave enough to make a detailed comparison

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

On Thu, 20 Jul 2017, Woodworth, John R wrote: Camp#2) Don't break DNS, even for a second Well, yeah, except that there's no such thing as breaking the DNS for a second. If we look at the history of DNSSEC, we'd break the DNS for somewhere between a decade and forever. We have tried very

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque wrote: > On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson > wrote: > >> Shumon, >> >> In section 5 your draft says: >> >>If an Authoritative Server has no algorithms in common with the >>

Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption"

> From: Stephane Bortzmeyer >> The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state >> Candidate for WG Adoption > > Did anyone was brave enough to make a detailed comparison between this > draft and other proposals like draft-yao-dnsop-accompanying-questions? >

Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption"

On 04/07/2017 12:42, IETF Secretariat wrote: > The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state > Candidate for WG Adoption (entered by Tim Wicinski) I heard that someone implemented this during the Hackathon at the weekend. Does anyone know who that was? thanks, Ray

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

Hi Jinmei On Wed, Jul 19, 2017 at 04:14:11PM -0700, 神明達哉 wrote: > At Tue, 18 Jul 2017 18:20:56 +0530, > Mukund Sivaraman wrote: > > > Dealing with water torture and some other attacks have had several > > band-aid approaches that don't always work well in practice. The most > >

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque wrote: > On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson < > ola...@cloudflare.com> wrote: >> >> >> I disagree, if a zone operator selects "less-than" common algorithm they >> do that at their own risk, >> if the risk is not

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Thu, Jul 20, 2017 at 9:51 AM, Stephane Bortzmeyer wrote: > On Wed, Jul 19, 2017 at 02:28:37PM +0200, > Shumon Huque wrote > a message of 153 lines which said: > > > > Suppose I send the list ECDSA;RSA, and I receive only ECDSA > > > signatures. How the

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson wrote: > > > I disagree, if a zone operator selects "less-than" common algorithm they > do that at their own risk, > if the risk is not acceptable then it should dual sign > Yes. The point I was trying to make is

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote: > This basically means that BULK is a master-only feature, which implies > that there's no need for BULK to work across zone transfers, which implies > the need to standardize it for interop is almost nonexistent. I don't think that

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

On Thu, 20 Jul 2017, Tony Finch wrote: John R Levine wrote: BULK absolutely requires online DNSSEC signing, This basically means that BULK is a master-only feature, which implies that there's no need for BULK to work across zone transfers, which implies the need to

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

> On 20 Jul 2017, at 03:12, Woodworth, John R > wrote: > > For now, I think we've narrowed the draft opposition to two camps: > > Camp#1) Don't force me to use IPv6 reverse, I simply will never > > and > > Camp#2) Don't break DNS, even for a second Well I

[DNSOP] REMINDER: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017

The CFP submission deadline is fast approaching. If you'd like to present at this meeting please get your submissions in soon! thanks, Ray --8<--8<-- The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71.

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

Op 20-07-17 om 10:45 schreef Shumon Huque: > On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson > > wrote: > > > I disagree, if a zone operator selects "less-than" common algorithm > they do that at their own risk, > if the risk

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Thu, Jul 20, 2017 at 11:48 AM, Willem Toorop wrote: > Op 20-07-17 om 10:45 schreef Shumon Huque: > > On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson > > > wrote: > > > > > > I disagree, if a zone operator

Re: [DNSOP] [Ext] comments on draft-mglt-dnsop-dnssec-validator-requirements-05

Hi, Thank you for the feed backs Scott. We will address them in the next version. The motivation for crypto deprecation is clearly to follow the crypto recommendations stated by the IETF. However, this requirement for the validator is to actually "validate" those requirements are effective. The

Re: [DNSOP] requesting WGLC for 5011-security-considerations

Wes, It's been a while since I have had a look at this draft, my apologies. I don't think it is ready for WGLC because I am not convinced the math is correct. Section 6 defines the waitTime: waitTime = addHoldDownTime + (DNSKEY RRSIG Signature Validity) +

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

For TCP connections, being able to signal session liveness policy is useful for DNS, not just DNSSD. It seems likely that DNS Push is useful for things other than DNSSD. I think this is generally useful, not just for DNSSD. Rather than thinking of this as a DNSSD-specific enhancement, think

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote: > Is this useful for DNS at all, or is this targeted at DNS-SD only? I can think of at least one way it would be useful. Large authoritatives often have a clear population of query sources that ask a lot -- the "top talkers". It would

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

> But it's certainly another step along the way to DNSbis by accident. Would it be useful to make it not "by accident"? That's why I have a love-hate relationship with TLV inside DNS messages. I have a couple questions: a) make DNS over TCP/TLS sessions without TLV suck less? b) make this

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: > > But it's certainly another step along the way to DNSbis by accident. > > Would it be useful to make it not "by accident"? Yes. That was basically the point I was trying to make at the beginning of today's session, about overall

Re: [DNSOP] EDNS0 clientID is a wider-internet question

It would be nice if there were an RFC to point to that used a method that didn't include PII. For the use cases of which I am ware, there is no need to identify individual devices: only policies. What's lacking is a way to do this in the home router, so the PII winds up getting exported to the

[DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

Dear colleagues, On Mon, Jul 10, 2017 at 06:16:53PM -0400, Shumon Huque wrote: > negotiation from the beginning, fail open would not have been necessary. > This fail open behavior frequently takes people not in the DNSSEC club by > complete surprise. I've lost track of how many "WTF" moments I've

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

On Tue, Jul 18, 2017 at 01:24:33PM -0700, IETF Secretariat wrote a message of 11 lines which said: > The DNSOP WG has placed draft-woodworth-bulk-rr in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at >

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

On Tue, Jul 18, 2017 at 06:20:56PM +0530, Mukund Sivaraman wrote a message of 27 lines which said: > It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned > zones. That's quite funny. During the development of RFC 8020 (draft-ietf-dnsop-nxdomain-cut), which

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

On Wed, Jul 19, 2017 at 09:57:49PM -, John Levine wrote a message of 38 lines which said: > We did this in a horrible ad-hoc way with DNSSEC, and even with > DNSSEC there's the fallback that the unsigned answers you get from a > server that doesn't understand RRSIG et al.

[DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes

multi-qtypes Security Considerations says: >The method documented here does not change any of the security >properties of the DNS protocol itself. I don't think this statement is true. Why? a) DNS DDoS threats are real and there was a shift towards minimizing answers. This goes in

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

Hey, there's one thing I don't really understand from this draft. Is this useful for DNS at all, or is this targeted at DNS-SD only? I think this needs some explaining and perhaps a clear cut is needed. Although it's not mentioned anywhere in the document, the draft makes much more sense to me,