Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Chris Thompson
On Aug 14 2014, Joe Abley wrote: [...] It seems to me that no delegation is a perfectly reasonable steady state, It fails to break the chain of trust. Because a validator can prove that the names in the putative subzone do not exist, it will consider locally defined content bogus. The only

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Joe Abley
Hi Chris, I went quiet on this thread because I was going to try this out in a lab before commenting further, but since I haven't done that and you had something to say... On 20 Aug 2014, at 12:50, Chris Thompson c...@cam.ac.uk wrote: On Aug 14 2014, Joe Abley wrote: [...] It seems to me

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Mark Andrews
In message 19ae3cb3-b108-42cb-bae2-a2f1fbb55...@hopcount.ca, Joe Abley writes : Hi Chris, I went quiet on this thread because I was going to try this out in a lab before commenting further, but since I haven't done that and you had something to say... On 20 Aug 2014, at 12:50, Chris

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Joe Abley
On 20 Aug 2014, at 17:48, Mark Andrews ma...@isc.org wrote: You will give answers that validate as bogus in the stub resolver. This seems to be the crux of our differing world views. A validating stub resolver Validating stub resolvers? In my own personal taxonomy a stub resolver doesn't

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Mark Andrews
In message e4ad7d21-995c-46b1-813e-70ca0919f...@hopcount.ca, Joe Abley writes : On 20 Aug 2014, at 17:48, Mark Andrews ma...@isc.org wrote: You will give answers that validate as bogus in the stub resolver. This seems to be the crux of our differing world views. A validating stub

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Mark Andrews
In message 20140820235118.e952b1d1b...@rock.dv.isc.org, Mark Andrews writes: In message e4ad7d21-995c-46b1-813e-70ca0919f...@hopcount.ca, Joe Abley writ es : On 20 Aug 2014, at 17:48, Mark Andrews ma...@isc.org wrote: You will give answers that validate as bogus in the stub

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Ted Lemon
On Aug 20, 2014, at 9:21 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Aug 21, 2014 at 10:52:46AM +1000, Mark Andrews wrote: It was also a required step as you can't reliably validate in the client unless the recursive server has filtered out the spoofed answers. If I

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Mark Andrews
In message 20140821012100.gc2...@mx1.yitter.info, Andrew Sullivan writes: On Thu, Aug 21, 2014 at 10:52:46AM +1000, Mark Andrews wrote: It was also a required step as you can't reliably validate in the client unless the recursive server has filtered out the spoofed answers. If I

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Mark Andrews
In message 54885a5d-2afa-4d37-9b83-2229082d7...@virtualized.org, David Conrad writes: Hi, On Aug 20, 2014, at 6:21 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Aug 21, 2014 at 10:52:46AM +1000, Mark Andrews wrote: It was also a required step as you can't reliably

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-20 Thread Evan Hunt
On Thu, Aug 21, 2014 at 12:17:25PM +1000, Mark Andrews wrote: If they fail it can fallback to making iterative queries or just accept the failure. I'd quibble with this bit: if it can make iterative queries, then we might as well just call it a validating resolver. IMHO the thing we're

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-14 Thread Dick Franks
Mark, Surely, something stronger than a reminder is appropriate. For a mission-critical requirement, this needs to be an explicit and unambiguous request: This document directs IANA to create insecure delegations for the listed zones. Dick On 14 August

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-14 Thread Joe Abley
On 13 Aug 2014, at 20:16, Mark Andrews ma...@isc.org wrote: Can we please move on this. The reverse address are not yet insecurely delegated as would be required for RFC 6598 compliance. This is starting to cause operational problems for ISP's that validate DNS

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-14 Thread Joe Abley
On 14 Aug 2014, at 12:04, Mark Andrews ma...@isc.org wrote: The assignements go: 0.0.0.0/0 IANA (IN-ADDR.ARPA) 100.0.0.0/8 ARIN(100.IN-ADDR.ARPA) 100.64.0.0/10 IANA (64.100.IN-ADDR.ARPA through 127.100.IN-ADDR.ARPA)

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-14 Thread Mark Andrews
In message 7ea38d42-3915-403e-afe3-c0a8e4a39...@hopcount.ca, Joe Abley writes: On 14 Aug 2014, at 12:04, Mark Andrews ma...@isc.org wrote: The assignements go: 0.0.0.0/0 IANA (IN-ADDR.ARPA) 100.0.0.0/8 ARIN(100.IN-ADDR.ARPA) 100.64.0.0/10 IANA

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

2014-08-13 Thread William F. Maton Sotomayor
Hi I have read through this and would support its progress. A reminder for the record would not be a bad idea I think. On Thu, 14 Aug 2014, Mark Andrews wrote: Can we please move on this. The reverse address are not yet insecurely delegated as would be required