Re: [DNSOP] DNS terminology draft

2015-04-01 Thread Dave Lawrence
Dave Lawrence: >> ECS / EDNS client-subnet -- An EDNS option [...] Paul Hoffman: > This seems premature given that the whole area is still under discussion. I have a mixed reaction to this, because I appreciate the point that there is not yet an official RFC on the matter (though there is an assi

Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt

2015-04-01 Thread Shumon Huque
On Tue, Mar 31, 2015 at 4:31 PM, Alain Durand wrote: > > 3) There is another solution, that is do nothing, i.e. Do NOT populate the > reverse tree. >Probably ISPs on that path would like to see an update to RFC1033 & > RFC1912 to >explicitly say that the PTR record requirement is relaxed

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Mark Andrews
In message , Tony F inch writes: > Paul Vixie wrote: > > John Levine wrote: > > > > > > A very short survey reveals that unbound and 8.8.8.8 return SOA, bind > > > doesn't. So it's not all the time, but it's pretty common. > > > > in BIND it's an option. > > It is? I can't work out how to make

Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt

2015-04-01 Thread Stephan Lagerholm
Hi Lee Howard, Here are my comments on the draft: Section 1. What exactly is the reference to [RFC1033] for? I can't see any of the text in this sentence in RFC1033. Section 1.2 I don't see prefix delegation being mentioned in this section and I think it should. If an ISP (perhaps wireless) just

[DNSOP] Draft minutes posted

2015-04-01 Thread Tim Wicinski
I started to clean up the minutes for DNSOP and posted a draft version http://www.ietf.org/proceedings/92/minutes/minutes-92-dnsop please take a look and send any comments, feedback, etc. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Tony Finch
Paul Vixie wrote: > John Levine wrote: > > > > A very short survey reveals that unbound and 8.8.8.8 return SOA, bind > > doesn't. So it's not all the time, but it's pretty common. > > in BIND it's an option. It is? I can't work out how to make it produce a negative response without a SOA. minima

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Shumon Huque
On Wed, Apr 1, 2015 at 4:53 PM, Paul Vixie wrote: > > > John Levine wrote: > >> Good point, I was only thinking of recursive answers, and I don't think > I see SOAs there all the time. We can add > >> that NODATA responses for authoritative responses include the SOA. > > > > A very short survey r

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Paul Vixie
John Levine wrote: >> Good point, I was only thinking of recursive answers, and I don't think I >> see SOAs there all the time. We can add >> that NODATA responses for authoritative responses include the SOA. > > A very short survey reveals that unbound and 8.8.8.8 return SOA, bind > doesn't. S

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Shumon Huque
On Wed, Apr 1, 2015 at 4:37 PM, John Levine wrote: > >Good point, I was only thinking of recursive answers, and I don't think I > see SOAs there all the time. We can add > >that NODATA responses for authoritative responses include the SOA. > > A very short survey reveals that unbound and 8.8.8.8

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread John Levine
>Good point, I was only thinking of recursive answers, and I don't think I see >SOAs there all the time. We can add >that NODATA responses for authoritative responses include the SOA. A very short survey reveals that unbound and 8.8.8.8 return SOA, bind doesn't. So it's not all the time, but it'

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Paul Vixie
Evan Hunt wrote: >>> Should we also mention that NODATA responses usually include a SOA record >>> in the authority section to indicate to resolvers how long to do negative >>> caching for? >> That does not seem to be established firmly enough for us to add. > > It's necessary for negative cachin

Re: [DNSOP] Some comments on draft-hoffman-dns-terminology

2015-04-01 Thread Paul Hoffman
On Apr 1, 2015, at 1:02 AM, Matthijs Mekking wrote: > In section 3 (DNS Message Format) the last three paragraphs discusses > "default TTL", Glue records and Referrals. I wonder if that belongs in the > section about DNS Message Format. To me it sounds like it is more suitable to > be put in th

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Paul Hoffman
On Apr 1, 2015, at 11:24 AM, Evan Hunt wrote: > >>> Should we also mention that NODATA responses usually include a SOA record >>> in the authority section to indicate to resolvers how long to do negative >>> caching for? >> >> That does not seem to be established firmly enough for us to add. >

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Evan Hunt
> > Should we also mention that NODATA responses usually include a SOA record > > in the authority section to indicate to resolvers how long to do negative > > caching for? > > That does not seem to be established firmly enough for us to add. It's necessary for negative caching, so I believe it's

Re: [DNSOP] DNS terminology draft

2015-04-01 Thread Paul Hoffman
On Mar 24, 2015, at 3:02 PM, Dave Lawrence wrote: > EDNS / EDNS0 -- The Extension Mechanisms for DNS, defined by > [RFC6891], are an addition to the original message format to allow DNS > agents [which I acknowledge is not defined, but by which I mean to > indicate "any software which speaks DNS"

Re: [DNSOP] comments on DNS terminology draft

2015-04-01 Thread Paul Hoffman
Sorry for the belated reply. On Mar 24, 2015, at 1:03 PM, Shumon Huque wrote: > Some comments on draft-hoffman-dns-terminology > > >NODATA -- This is not an actual response code, but instead is the > >combination of an RCODE of 0 (NOERROR) and an Answer section that is > >empty. Tha

Re: [DNSOP] Small review of draft-ietf-dnsop-edns-client-subnet-00

2015-04-01 Thread Paul Hoffman
On Apr 1, 2015, at 7:34 AM, Stephane Bortzmeyer wrote: > 1) "The motivation for a user to configure such a Centralized Resolver > varies but is usually because of some enhanced experience, such as > greater cache security or applying policies regarding where users may > connect." OK, but the draft

Re: [DNSOP] Small review of draft-ietf-dnsop-edns-client-subnet-00

2015-04-01 Thread Mark Delany
On 01Apr15, Stephane Bortzmeyer allegedly wrote: > [I am not a big fan of the idea, because I see it as useful mostly for > big public resolvers and I am not a big fan of big public resolvers.] It's also useful for big "private" resolvers too. Such as those run by ISPs, mobile phone networks, larg

Re: [DNSOP] Small review of draft-ietf-dnsop-edns-client-subnet-00

2015-04-01 Thread Edward Lewis
On 4/1/15, 10:34, "Stephane Bortzmeyer" wrote: >connect." OK, but the draft should also mentions the cons of >centralized resolvers such as the privacy risks and the security risks >in the first kilometer (which is many kilometers long). The draft isn't justifying the existence or use of central

Re: [DNSOP] Small review of draft-ietf-dnsop-edns-client-subnet-00

2015-04-01 Thread Stephane Bortzmeyer
On Wed, Apr 01, 2015 at 02:53:41PM +, Edward Lewis wrote a message of 127 lines which said: > The draft isn't justifying the existence or use of centralized > resolvers, just establishing they exist. Digressing into such a > discussion would be a distraction. I disagree. The draft is not

[DNSOP] Small review of draft-ietf-dnsop-edns-client-subnet-00

2015-04-01 Thread Stephane Bortzmeyer
[I am not a big fan of the idea, because I see it as useful mostly for big public resolvers and I am not a big fan of big public resolvers.] Section 1: 1) "The motivation for a user to configure such a Centralized Resolver varies but is usually because of some enhanced experience, such as greater

[DNSOP] Some comments on draft-hoffman-dns-terminology

2015-04-01 Thread Matthijs Mekking
Hi wg, I have reviewed the DNS terminology draft and have some comments. 1. In section 3 (DNS Message Format) the last three paragraphs discusses "default TTL", Glue records and Referrals. I wonder if that belongs in the section about DNS Message Format. To me it sounds like it is more suita