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
[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
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
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
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
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
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
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"
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.
>
> > 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
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
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
>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'
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
