Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Dave,
On Wed, Oct 10, 2018 at 3:52 PM Dave Crocker  wrote:

> On 10/10/2018 4:38 PM, Paul Vixie wrote:
> > i can live with that.
> >
> >>
> >> which is one heck of a lot of "resource record types" in the same, short
> >> paragraph.
> >
> > truth hurts.
>
> mumble. drat.  that's two in favor, which for this topic rates as
> overwhelming consensus.
>
> sigh.  k.  if you insist...
>

Oh, it's a No-Objection comment. I would only ask that people do the right
thing, but you'll know what that is ;-)

Spencer


>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Spencer Dawkins at IETF]

On Mon, Sep 10, 2018 at 9:48 AM Benjamin Kaduk  wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
>
>
> --
> COMMENT:
> --
>




> Section 4.4
>
> Why are we enumerating transports instead of talking about the properties
> they provide?  We've got multiple new transports in the works, and it would
> be a shame to ignore them out of the gate.
>

It's probably also worth pointing out (chiming in on Benjamin's ballot)
that talking about transport properties would help us make sure we keep
those properties in mind when we work on new transports :-) ...

Spencer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Spencer Dawkins' Yes on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Paul,

On Tue, Aug 28, 2018 at 2:52 PM Paul Hoffman  wrote:

> On Aug 27, 2018, at 8:55 PM, Spencer Dawkins <
> spencerdawkins.i...@gmail.com> wrote:
> > In this text,
> >
> > 2.  Names
> >
> > ...
> >
> >  The common display format is used in applications and free text.
> >  It is the same as the presentation format, but showing the root
> >  label and the "." before it is optional and is rarely done.  For
> >  example, in common display format, a fully-qualified domain name
> >  with two non-root labels is usually shown as "example.tld" instead
> >  of "example.tld.".  Names in the common display format are
> >  normally written such that the directionality of the writing
> >  system presents labels by decreasing distance from the root (so,
> >  in both English and C the root or TLD label in the ordered list is
> >  right-most; but in Arabic it may be left-most, depending on local
> >  conventions).
> >
> > I bet I know what you mean by "C", but I'm guessing. Perhaps it's worth
> > providing a reference, for all the Javascript and Python programmers who
> > skipped over C?
>
> We can change this to "the C programming language". I don't think an
> actual reference is going to help anyone who doesn't recognize the language.
>

That's better than anything I was thinking about (I've been reviewing
drafts for too long. Sorry!)


> > I'm looking at
> >
> > Administration of names -- Administration is specified by
> >  delegation (see the definition of "delegation" in Section 7).
> >  Policies for administration of the root zone in the global DNS are
> >  determined by the names operational community, which convenes
> >  itself in the Internet Corporation for Assigned Names and Numbers
> >  (ICANN).  The names operational community selects the IANA
> >  Functions Operator for the global DNS root zone.  At the time this
> >  document is published, that operator is Public Technical
> >  Identifiers (PTI).  (See  for more
> >  information about PTI operating the IANA Functions.)  The name
> >  servers that serve the root zone are provided by independent root
> >  operators.  Other zones in the global DNS have their own policies
> >  for administration.
> >
> > and wondering what the stability of an ICANN URL that refers to the name
> of the
> > current IANA Functions Operator will be in 5-10 years. I'm not sure what
> else
> > you can do to make that more useful if a different operator is selected,
> but if
> > you can do something, maybe that would be useful.
>
> We already say "At the time this document is published". And it's not like
> documents like RFC 7868 are titled "Cisco's (or Whoever Purchases Them
> Later) Enhanced Interior Gateway Routing Protocol (EIGRP)". :-)
>

Right. Emphasizing that this may not be a solvable problem, my point was
that I can easily imagine that what was once " "
would disappear and something like "" would pop
up when The Competing IANA Functions Operator takes over, which is more
drastic, so you get 404 Not Found.

In a perfect world, ICANN would return 301 Moved Permanently, I suppose.
Mumble. Moving on.

> I'm looking at this text:
> >
> >  Passive DNS:  A mechanism to collect DNS data by storing DNS
> >  responses from name servers.  Some of these systems also collect
> >  the DNS queries associated with the responses, although doing so
> >  raises some privacy concerns.
> >
> > and thinking that the problem isn't collecting DNS queries associated
> with
> > responses, it's that it's possible to collect DNS queries associated with
> > responses (so, if one of these systems stops collecting DNS queries, you
> still
> > have an exposure; it's just not happening now). Is that wrong?
>
> Yes. Although this definition was well-discussed in the WG, I can see
> where you missed the salient bit. With RFC 7871, the query gives more
> information about the user making the request than the response does.
>

Yes, exactly. If you guys think you might have readers that don't realize
that, perhaps

 Passive DNS:  A mechanism to collect DNS data by storing DNS
  responses from name servers.  Some of these systems also collect
  the DNS queries associated with the responses, although doing so
  raises some privacy concerns, because the query reveals more
  information about the user making the request than the response does.

would be helpful. Do the right thing, of course.


> > I'm looking at this text:
> >
> >  Privacy-enabling DNS server:  "A DNS server that implements DNS over
> >  TLS [RFC7858] and may optionally implement DNS over DTLS
> >  [RFC8094]."  (Quoted from [RFC8310], Section 2)
> >
> > and seeing a race condition with
> > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ (which
> isn't
> > news to the authors who contributed to both specifications). Is it w

Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

Hi, Ted,

Chopping down to clearing my Discuss, and one wording suggestion for new
text ...

On Tue, Jul 31, 2018 at 1:41 PM Ted Lemon  wrote:

> On Jul 27, 2018, at 12:33 AM, Spencer Dawkins <
> spencerdawkins.i...@gmail.com> wrote:
>
> I really like this document, and think it's headed the right direction. Of
> course I have four pages of comments, because reasons, but the only part
> I'm
> really confused about is this one ...
>
> I would have thought that if you end up with a different endpoint because
> your
> anycast address now resolves differently, the new endpoint would have to
> have
> shared a lot of state with the previous endpoint, for this to work:
>
>  When an anycast service is configured on a particular IP address and
>   port, it must be the case that although there is more than one
>   physical server responding on that IP address, each such server can
>   be treated as equivalent.  If a change in network topology causes
>   packets in a particular TCP connection to be sent to an anycast
>   server instance that does not know about the connection, the normal
>   keepalive and TCP connection timeout process will allow for recovery.
>
> What I would have expected to happen, is that the new endpoint sees a
> packet
> arrive that's not on a synchronized TCP connection, and immediately
> responds
> with a RST (reset), rather than the normal keepalive and TCP connection
> timeout
> process happening. That's also the way I'm reading
> https://tools.ietf.org/html/rfc7828#section-3.6. Is that not the way it's
> working for anycast these days?
>
>
> I believe this is correct—thanks for pointing it out.   I think the fix is
> straightforward:
>
>   When an anycast service is configured on a particular IP address and
>   port, it must be the case that although there is more than one
>   physical server responding on that IP address, each such server can
>   be treated as equivalent.  If a change in network topology causes
>   packets in a particular TCP connection to be sent to an anycast
>   server instance that does not know about the connection, the new
>   server will automatically terminate the connection with a TCP reset,
>   since it will have no record of the connection, and then the client can
>   reconnect or stop using the connection, as appropriate.
>
> Does that sound good?
>

I'll clear based on this text, but you might want to consider being a bit
more precise about what you're thinking of, when you say "each such server
can be treated as equivalent", which, IIRC, was what started my journey
into the weeds on this paragraph.

ISTM that there are two ways people could be using anycast
(overgeneralizing wildly) -

   - I have nine servers that are geographically close enough to maintain
   TCP state across the set of servers and I'm using anycast for
   loadbalancing, or
   - I have nine servers that are geographically diverse, and I'm using
   anycast to provide more robust service, and they're not close enough to
   maintain TCP state across the set of servers.

I think your point is that the first case is fine (a change in network
topology means that the server now being used either knows or can figure
out quickly that to do with the incoming packet), and the second case is
not (a change in network topology means that the server being used has no
idea what to do with the incoming packet, and has no way to figure that
out).

If I got that right (at a 50,000 foot level), you might think about how to
say it more correctly, but I'm clearing now, so do the right thing.


The text in 6.1.  DSO Session Initiation seems rough to me, for a couple of
> reasons.
>
>   The client may perform as many DNS operations as it wishes using the
>   newly created DSO Session.  Operations SHOULD be pipelined (i.e., the
>
> I don't understand why this would be a SHOULD. At least from the client's
> perspective, it's not needed for interoperation.
>
>   client doesn't need wait for a response before sending the next
>   message).  The server MUST act on messages in the order they are
>   transmitted, but responses to those messages SHOULD be sent out of
>   order when appropriate.
>
> Is it correct to say that "responses to those messages SHOULD be sent when
> they
> become available, even if the responses are sent out of order"? If not, I'm
> probably missing what "when appropriate" means.
>
>
> Good points.   I've made the following change:
>
>  The client may perform as many DNS operations as it wishes using the
> -newly created DSO Session. Operations SHOULD be pipelined (i.e., the
> -client doesn't need wait for a response before sending the next message)..
> +newly created DSO Session. When the
> +client has multiple messages to send, it SHOULD NOT wait for each
> response before sending the next message.
> +This prevents TCP's delayed acknowledgement algorithm from forcing the
> +client into a slow lock-step.
>  The server MUST act on messages in the order they are transmitted, but
> -responses to th

Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

Hi, Benjamin,

On Fri, Jul 27, 2018 at 12:33 PM Benjamin Kaduk  wrote:

> On Thu, Jul 26, 2018 at 09:33:20PM -0700, Spencer Dawkins wrote:
> > --
> > COMMENT:
> > --
> [snip]
> >
> > This next one is well within the "Spencer wouldn't have done it this
> way, but
> > Spencer's not the working group, or the IETF" range, but
> >
> >   However, in the typical case a server will not know in advance
> >whether a client supports DSO, so in general, unless it is known in
> >advance by other means that a client does support DSO, a server MUST
> >NOT initiate DSO request messages or DSO unacknowledged messages
> >until a DSO Session has been mutually established by at least one
> >successful DSO request/response exchange initiated by the client, as
> >described below.  Similarly, unless it is known in advance by other
> >means that a server does support DSO, a client MUST NOT initiate DSO
> >unacknowledged messages until after a DSO Session has been mutually
> >established.
> >
> > seems fragile, especially in environments where clients can come and go,
> and
> > servers may be addressed using anycast (so I knew in advance that the
> four
> > servers at that anycast address supported DSO, but somebody installed a
> fifth
> > server that does not). Is that unlikely to be a problem?
>
> Note that the client is only prohibted from using "unacknowledged"
> (one-shot) messages -- it can send always normal requests and use the
> presence of a reply to determine server support, on this connection.
> So this seems like a pretty vanilla "client initiates" thing, if I
> understand correctly.
>

Ah - that helps me understand. Thank you for that.

Spencer


> -Benjamin
>
> [snip]
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Benoit,

On Jul 5, 2017 12:32 PM, "Benoit Claise"  wrote:

Hi,

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon  wrote:

> Spencer, not to respond to all your comments right now, but just to point
> this out: the list of problems is not claimed to be correct.   It is
> claimed to be the list of problems that people have asserted exist.   I do
> not agree that all the problems listed are problems, nor I think does
> anyone else.   If that's not clear in the document, that's probably worth
> correcting.
>

I think my comments are more likely to be unclear than the way the document
describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes,
that I think I understand at a surface level, but I don't think I
understand the implications in a few cases, so, that's what I included in
my ballot.

I think the document is clear enough on "claimed to be the list of problems
that people have asserted exist", and even if I didn't think that was a
fine basis for this document, I wouldn't dream of suggesting that the
authors change the criteria for what's included.

Part of my AD review, I asked the text to clarified. Hopefully, it's
clarified.
>From the 04 to 05 diff:


That is clear (and clearer than -04).

Spencer



Regards, B.




On Jul 5, 2017 12:32 PM, "Benoit Claise"  wrote:

Hi,

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon  wrote:

> Spencer, not to respond to all your comments right now, but just to point
> this out: the list of problems is not claimed to be correct.   It is
> claimed to be the list of problems that people have asserted exist.   I do
> not agree that all the problems listed are problems, nor I think does
> anyone else.   If that's not clear in the document, that's probably worth
> correcting.
>

I think my comments are more likely to be unclear than the way the document
describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes,
that I think I understand at a surface level, but I don't think I
understand the implications in a few cases, so, that's what I included in
my ballot.

I think the document is clear enough on "claimed to be the list of problems
that people have asserted exist", and even if I didn't think that was a
fine basis for this document, I wouldn't dream of suggesting that the
authors change the criteria for what's included.

Part of my AD review, I asked the text to clarified. Hopefully, it's
clarified.
>From the 04 to 05 diff:


Regards, B.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon  wrote:

> Spencer, not to respond to all your comments right now, but just to point
> this out: the list of problems is not claimed to be correct.   It is
> claimed to be the list of problems that people have asserted exist.   I do
> not agree that all the problems listed are problems, nor I think does
> anyone else.   If that's not clear in the document, that's probably worth
> correcting.
>

I think my comments are more likely to be unclear than the way the document
describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes,
that I think I understand at a surface level, but I don't think I
understand the implications in a few cases, so, that's what I included in
my ballot.

I think the document is clear enough on "claimed to be the list of problems
that people have asserted exist", and even if I didn't think that was a
fine basis for this document, I wouldn't dream of suggesting that the
authors change the criteria for what's included.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Paul,

On Tue, Dec 6, 2016 at 8:39 PM, Paul Hoffman  wrote:

> [[ BTW, sorry for not changing the subject line on this thread. It really
> does relate to all the IESG comments, not jus Ben's. ]]
>
> On 6 Dec 2016, at 18:32, Spencer Dawkins at IETF wrote:
>
> On 30 Nov 2016, at 22:48, Spencer Dawkins wrote:
>>>
>>> I find myself curious about both SHOULDs in
>>>
>>>>
>>>>Resolver software SHOULD treat the response to the priming query as a
>>>>normal DNS response, just as it would use any other data fed to its
>>>>cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs.
>>>>
>>>> Do you think these SHOULDs (especially the first one) are required for
>>>> interoperation?
>>>>
>>>>
>>> Yes.
>>>
>>> I'm wondering (1) why they aren't MUSTs, and (2) why RFC
>>>
>>>> 2119 language is actually needed at all. If they are RFC 2119 SHOULDs,
>>>> what happens if the resolver software violates them?
>>>>
>>>>
>>> We cannot tell. For the first one, if a resolver treats the response to
>>> the priming query in a special way, we don't know what "special" means.
>>>
>>
>>
>> I'm somewhat curious about why this isn't a MUST, but ... ok.
>>
>
> For example, an implementation might treat the responses special by
> altering the TTLs based on some understanding that the vendor has that only
> is relevant to priming queries. Why prevent that?


That wasn't my intention. Thanks for indulging my curiosity.

Sometimes, I'm a curious guy ;-)


>
>
> For the second one, if a resolver expects exactly 13 NS RRs and gets
>>> fewer, we don't know what it will do (fail to come up? retry incessantly?
>>> ...?)
>>>
>>>
>> I'm really curious about why this is not a MUST - can anything good happen
>> when you expect 13 NS RRs? Usually, we're saying "SHOULD NOT, unless you
>> can assess the risks of doing it". Is that possible, in this case?
>>
>
> We could certainly say "SHOULD NOT expect exactly 13 NS RRs because
> historically some root servers have returned fewer".


That is exactly the kind of thing that seems uber-helpful to mention!

Thanks for the background.

Spencer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Paul,

On Tue, Dec 6, 2016 at 1:08 PM, Paul Hoffman  wrote:

> Thanks for your comments and for having no objections to the document.
> This message follows up on the comments.
>
> --Paul Hoffman
>

Deleted down to


> On 30 Nov 2016, at 22:48, Spencer Dawkins wrote:
>
> I find myself curious about both SHOULDs in
>>
>>Resolver software SHOULD treat the response to the priming query as a
>>normal DNS response, just as it would use any other data fed to its
>>cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs.
>>
>> Do you think these SHOULDs (especially the first one) are required for
>> interoperation?
>>
>
> Yes.
>
> I'm wondering (1) why they aren't MUSTs, and (2) why RFC
>> 2119 language is actually needed at all. If they are RFC 2119 SHOULDs,
>> what happens if the resolver software violates them?
>>
>
> We cannot tell. For the first one, if a resolver treats the response to
> the priming query in a special way, we don't know what "special" means.


I'm somewhat curious about why this isn't a MUST, but ... ok.


> For the second one, if a resolver expects exactly 13 NS RRs and gets
> fewer, we don't know what it will do (fail to come up? retry incessantly?
> ...?)
>

I'm really curious about why this is not a MUST - can anything good happen
when you expect 13 NS RRs? Usually, we're saying "SHOULD NOT, unless you
can assess the risks of doing it". Is that possible, in this case?

Spencer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Shumon,

On Wed, Sep 14, 2016 at 8:47 PM, Shumon Huque  wrote:

> On Wed, Sep 14, 2016 at 6:05 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
>> Hi, Shumon,
>>
>> On Wed, Sep 14, 2016 at 4:33 PM, Shumon Huque  wrote:
>>
>>>
>>>> --
>>>> COMMENT:
>>>> --
>>>>
>>>> I honestly look forward to reading DNSOPS drafts because they are
>>>> uniquely chatty, and this one is no exception (awesome document title,
>>>> dude). That said,
>>>>
>>>>This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it
>>>>updates both of them.
>>>>
>>>> being "a bit modified" is like being a bit dead (either you're dead or
>>>> you're not), so maybe that's TOO chatty?
>>>>
>>>
>>> Yes, agreed. How about?
>>>
>>> "This document updates portions of RFC 1034 and RFC 2308".
>>>
>>
>> That would work for me. "portions of" is implicit in Updates, because if
>> you were updating all of those RFCs you'd probably be Obsoleting them, but
>> I wouldn't object to saying "portions of".
>>
>
> Ah, good point :-) I'm fine with dispensing with "portions of" in that
> case.
>
>
>>>> This draft was very clear to me, as a non-DNS reader. Thanks for that.
>>>>
>>>> Just for my own education,
>>>>
>>>>But if a resolver has cached data under the NXDOMAIN cut, it MAY
>>>>continue to send it as a reply.  (Until the TTL of this cached data
>>>>expires.)
>>>>
>>>> I found myself wondering why this behavior is allowed. Is this a
>>>> performance thing, that you continue to respond normally until normal
>>>> TTL
>>>> expiration happens with no special processing required, or is this about
>>>> the non-tree cache implementations described in Section 6, or is there
>>>> more to it than that? Perhaps that's worth a word or two explaining.
>>>>
>>>
>>> There was a long discussion on list about this point, but the quick
>>> summary is that it is mostly for performance. For implementations that use
>>> a flat data structure like a hash table, it is much more work to invalidate
>>> all cache entries under the NXDOMAIN eliciting node. I believe Section 6 of
>>> the draft does discuss this issue. Maybe we can make it clearer, or let us
>>> know if you have any specific suggestions for doing so.
>>>
>>
>> Just providing a hint would have worked for me, and a forward pointer to
>> Section 6 would be even better. Perhaps something like
>>
>>But if a resolver has cached data under the NXDOMAIN cut, it MAY
>>continue to send it as a reply until the TTL of this cached data
>>expires, since this may avoid additional processing when an NXDOMAIN
>>cut is received. Section 6 provides more information about this.
>>
>
>> But you're more likely to get the text right than I am ...
>>
>
> Your proposed text sounds good to me (although I'd replace your "NXDOMAIN
> cut" with "NXDOMAIN response" in the penultimate sentence above).
>

"But you're more likely to get the text right than I am ..." :D

Thanks for getting it right!

Spencer


>
>
>> In this text in Appendix A,
>>>>
>>>>Even if the accompanying SOA record is
>>>>for example only, one cannot infer that foobar.example is
>>>>nonexistent.  The accompanying SOA indicates the apex of the zone,
>>>>not the closest existing domain name.
>>>>
>>>> it's not clear that this practice is OK, and (especially from the
>>>> example
>>>> that will be deleted), it seems dodgy to the uninitiated. Perhaps it's
>>>> worth saying so clearly (if it is, in fact, OK).
>>>>
>>>
>>> The section is attempting to say that it is NOT OK to use the SOA record
>>> owner name. We could make that clearer.
>>>
>>> I would personally be okay with removing this section also. I can't
>>> recall what discussion happened that caused this scenario to be included -
>>> maybe Stephane remembers.
>>>
>>
>> Do The Right Thing, of course.
>>
>> Thanks for considering my comments!
>>
>
> Sure - and thanks for the comments!
>
> --
> Shumon Huque
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Shumon,

On Wed, Sep 14, 2016 at 4:33 PM, Shumon Huque  wrote:

>
>> --
>> COMMENT:
>> --
>>
>> I honestly look forward to reading DNSOPS drafts because they are
>> uniquely chatty, and this one is no exception (awesome document title,
>> dude). That said,
>>
>>This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it
>>updates both of them.
>>
>> being "a bit modified" is like being a bit dead (either you're dead or
>> you're not), so maybe that's TOO chatty?
>>
>
> Yes, agreed. How about?
>
> "This document updates portions of RFC 1034 and RFC 2308".
>

That would work for me. "portions of" is implicit in Updates, because if
you were updating all of those RFCs you'd probably be Obsoleting them, but
I wouldn't object to saying "portions of".

>
>
>>
>> This draft was very clear to me, as a non-DNS reader. Thanks for that.
>>
>> Just for my own education,
>>
>>But if a resolver has cached data under the NXDOMAIN cut, it MAY
>>continue to send it as a reply.  (Until the TTL of this cached data
>>expires.)
>>
>> I found myself wondering why this behavior is allowed. Is this a
>> performance thing, that you continue to respond normally until normal TTL
>> expiration happens with no special processing required, or is this about
>> the non-tree cache implementations described in Section 6, or is there
>> more to it than that? Perhaps that's worth a word or two explaining.
>>
>
> There was a long discussion on list about this point, but the quick
> summary is that it is mostly for performance. For implementations that use
> a flat data structure like a hash table, it is much more work to invalidate
> all cache entries under the NXDOMAIN eliciting node. I believe Section 6 of
> the draft does discuss this issue. Maybe we can make it clearer, or let us
> know if you have any specific suggestions for doing so.
>

Just providing a hint would have worked for me, and a forward pointer to
Section 6 would be even better. Perhaps something like

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply until the TTL of this cached data
   expires, since this may avoid additional processing when an NXDOMAIN
   cut is received. Section 6 provides more information about this.

But you're more likely to get the text right than I am ...

>
>
>> In this text in Appendix A,
>>
>>Even if the accompanying SOA record is
>>for example only, one cannot infer that foobar.example is
>>nonexistent.  The accompanying SOA indicates the apex of the zone,
>>not the closest existing domain name.
>>
>> it's not clear that this practice is OK, and (especially from the example
>> that will be deleted), it seems dodgy to the uninitiated. Perhaps it's
>> worth saying so clearly (if it is, in fact, OK).
>>
>
> The section is attempting to say that it is NOT OK to use the SOA record
> owner name. We could make that clearer.
>
> I would personally be okay with removing this section also. I can't recall
> what discussion happened that caused this scenario to be included - maybe
> Stephane remembers.
>

Do The Right Thing, of course.

Thanks for considering my comments!

Spencer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

This is Not My Yes, but ...

On Wed, Jul 13, 2016 at 12:28 AM, Terry Manderson  wrote:

> Hi Wes,
>
> Thanks for responding.
>
> I'll trim to only the the remaining items needing a response, and express
> my appreciation at the clarified items.
>
> On 9/07/2016, 9:53 AM, "iesg on behalf of Wes Hardaker"
>  wrote:
>
> >"Terry Manderson"  writes:
> >
> >
> >> s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully
> >> stable URL?
> >
> >Per discussion in another thread: probably.  Olafur certainly won't
> >delete it as the owner, and I doubt github will die anytime soon.
> >
> >The only other choice is to remove the helpful reference.
>
> Thanks.
>
> >
> >I've changed it to "validating resolver daemon" instead.  Make more sense?
>
> It does.
>
>
> >
> >> s3.1.1, please use the example domain for such examples, ie example.com
> ,
> >> and once you have used it do you really need to repeat it for each
> >> 'existing' text until you get to the non-existent tests and so on up to
> >> 3.1.14.
> >
> >Well, here's the deal: example.com won't work and the domain in question
> >actually does work.  Some of them can probably be replaced with the root
> >server, but many others require somewhat specialized tests pointing to a
> >special domain.  That one is known to be the only one that likely will
> >work for some tests at this point.  The question is, what to do about
> >that?  Can we list a known one?  Must we list a useless one instead?
> >Should we pre-declare the problem?  I've been waiting for this to come
> >up :-)
>
> Personally, my advice would be to pre-decalre the issue, and why it's an
> issue and why some special domain is needed and describe the semantics of
> the FQDNs needed for the appropriate tests (including an appendix zone
> file?), and then use example.com as the label which needs to be
> substituted by the person constructing the tests/zone. The benefit here is
> that some folks might like to replicate such a construct in their own
> infrastructure, and this document might give them that guidance.
>
> Does that make sense?


Terry, I like where you're headed, but just to ask the obvious question,
are you thinking the draft would, or would not, also contain something like
"at the time this document was approved, a domain used for this test was $
someactualworkingdomain.com"?

I didn't mention the domains mentioned in this draft in my ballot, but I
was watching when you brought it up ... so I'm still curious.

Thanks,

Spencer


> Thanks
> Terry
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Wes,

On Fri, Jul 8, 2016 at 4:05 PM, Wes Hardaker  wrote:

> "Spencer Dawkins"  writes:
>
> > Spencer Dawkins has entered the following ballot position for
> > draft-ietf-dnsop-dnssec-roadblock-avoidance-04: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > This was an entertaining read.
> >
> > I share Mirja's comments. In addition:
> >
> > I'm not sure how well ESL readers will understand "crap-ware"/"crap" in
> > this passage ("crap-ware" is probably a reasonable term of art, if it's
> > intelligible enough to readers):
>
> Agreed.  I've removed that language that "someone" inserted.  Thanks.
>
> >NOTE: when performing these tests we also assume that the path is
> >clear of "DNS interfering" crap-ware/middle-boxes, like stupid
> >firewalls, proxies, forwarders.  Presence of such crap can easily
> >make the recursive resolver look bad.  It is beyond the scope of the
> >document as how to test around the interference.
> >
> > I'm not sure what "ideally MUST" means, in
> >
> >However, querying many zones will
> >result in answers greater than 1220 bytes so ideally TCP MUST be
> >available.
>
> Changed to:
>
> However, querying many zones will result in
> answers greater than 1220 bytes so DNS over TCP MUST be
> available.
>

That all sounds great, and thank you.

Spencer


>
> --
> Wes Hardaker
> Parsons
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-dns-terminology-04: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Paul,

Thanks for the followup! That works ...

Spencer

On Fri, Sep 18, 2015 at 3:59 PM, Paul Hoffman  wrote:

> On 18 Sep 2015, at 13:41, Spencer Dawkins at IETF wrote:
>
> Hi, Paul,
>>
>> On Fri, Sep 18, 2015 at 2:08 PM, Paul Hoffman 
>> wrote:
>>
>> On 16 Sep 2015, at 9:52, Spencer Dawkins wrote:
>>>
>>> If this
>>>
>>>>
>>>>  For example, at the time this document is published, the "au" TLD
>>>>  is not considered a public suffix, but the "com.au" domain is.
>>>>  (Note that this example might change in the future.)
>>>>
>>>> is intended to say that a subdomain may be a public suffix when its
>>>> domain is not, that could be stated more clearly. If it's intended to
>>>> say
>>>> something else, I don't know what that is (and "For example" didn't
>>>> help!)
>>>>
>>>>
>>> It is just an example of what we already said was an area of
>>> disagreement.
>>>
>>
>>
>> Hmmm. I didn't get that from the text. I'm not understanding what the
>> question is, that people disagree about the answer to. Could you help me
>> understand that?
>>
>
> I think I see the problem now. The text can simply be "For example, at the
> time this document is published, the "com.au" domain is considered a public
> suffix. (Note that this example might change in the future.)".
>
> I wonder if flipping the order would make your point more clearly.
>>
>> DNSSEC-aware and DNSSEC-unaware:  these two terms are not
>>  defined in Section 2 of [RFC4033], but many
>>  types of resolvers and validators, including "non-validating
>>  security-aware stub resolver", "non-validating stub resolver",
>>  "security-aware name server", "security-aware recursive name
>>  server", "security-aware resolver", "security-aware stub
>>  resolver", and "security-oblivious 'anything'" are defined there.
>>  "DNSSEC-aware" and "DNSSEC-unaware" are used in later RFCs,
>>  but the terms that have been formally defined are likely better
>>  choices for new documents. (Note that the term "validating resolver",
>>  which is used in some places in those documents, is nevertheless
>>  not defined in that section.)
>>
>>
>>
>>>
>>> I'm also slightly confused about why "validating resolver" is mentioned
>>>
>>>> in this list item, instead of appearing in a separate list item. Is the
>>>> common element that it's not defined anywhere else, either?
>>>>
>>>>
>>> More the fact that it is another DNSSEC-related term.
>>>
>>>
>> That helps. Perhaps s/nevertheless/also/ would have made this point more
>> clearly to me.
>>
>
> These seem like reasonable changes.
>
> --Paul Hoffman
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Alec,

On Thu, Sep 3, 2015 at 6:31 AM, Alec Muffett  wrote:

> Hello Spencer!
>
> I do have one observation that I haven't seen anyone else touch on:
>
> I thought .onion was tied closely to the TOR protocol, so I have no idea
> why the second sentence in this paragraph is here, or what it means, and
> neither the string "TOR" nor the string "onion" appear in RFC 7230, so
> chasing that reference didn't help.
>
>   Like Top-Level Domain Names, .onion addresses can have an arbitrary
>   number of subdomain components.  This information is not meaningful
>   to the Tor protocol, but can be used in application protocols like
>   HTTP [RFC7230].
>
> Am I just being dense the night before a telechat, and everyone else
> understands what this means and why it needs to be included in this
> document?
>
>
>
> This matter has been discussed extensively elsewhere, and in response to
> feedback from that experience, this paragraph will be mildly amended to
> address matters of DNS syntax conformance:
>
>Like Top-Level Domain Names, .onion names can have an arbitrary
>number of subdomain components.  This information is not meaningful
>to the Tor protocol, but can be used in application protocols like
>HTTP [RFC7230].  Note that such names must conform to DNS name syntax
>(as defined in Section 3.5 of [RFC1034] and Section 2.1 of
>[RFC1123]), as they will still be exposed to DNS implementations.
>
>
> What the first half of paragraph is attempting to express is outlined in
> my e-mail to the IETF Discuss list (and DNSOP)
>
> https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html
>
>
> …where I write, at perhaps excessive length (and mildly edited for
> clarity):
>
> Onion names are much closed to (say) dotted quads (or other layer-3
> addresses) than to domain names, albeit that to denote them there is the
> label ".onion" affixed in the place where one would expect to find a TLD.
>
> Where the analogy between onion names and IP addresses breaks down is that
> the following is illegal (or, at least, has never been functionally viable):
>
> http://www.192.168.0.1/  (versus http://eliot.blogs.192.168.0.1/)
>
> ...whereas the following *is* viable:
>
> https://www.facebookcorewwwi.onion/
>
> In some hypothetical alternate universe where we were all using IP
> addresses rather than DNS to connect to endpoints, it might be cute to
> support . and let the "Host" header (and/or the HTTPS
> SNI) disambiguate the intent, though doubtless this would also lead to some
> kind of disaster.
>
> In the Onion world, the canonical representation of an onion name is:
>
> *sixteencharlabel.onion* (compare representations: *192.168.1.1*, *[::1]*,
> etc)
>
> ...and in the outline we sketched of how Onions work, we sought to
> describe them properly in their role as layer-3 analogues, mechanically
> generated hashes of a randomly generated certificate, beyond human choice
> except for brute-force mining.
>
> *However*, the Tor software has a party trick, that (as Richard has
> explained) given an "onion" label for surety, it's happy to parse-out the
> "sixteencharlabel" label and use that for connection establishment,
> ignoring any other labels leftwards of that, if any.
>
> Of course using (say) "ssh" to connect to www.sixteencharlabel.onion will
> not be beneficial, because SSH supports neither "Host" header nor SNI; but
> a web browser using HTTP/S will pass a Host header, and thus we may effect
> virtual hosting over a single ".onion" names.
>
>
> The really short summary of this is: Onion names are layer-3 analogues,
> but they look like domain names and may have trivial “subdomains” where the
> transport protocol would be happy to recognise, honour and differentiate
> subdomains via metadata transfer.
>
> Does that help, please?
>

It does(*), as does Christian's explanation. I wonder whether there's a
sentence or two that would capture the salient points (which sound like
"Tor routers ignore leftward labels", and "Onion names can include leftward
labels that aren't used by Tor routers, but might be used to accomplish
techniques like virtual hosting" to me, at least so far).

Could you two talk, and see if that could happen?

My question is at the non-blocking Comment level, but it's also at the "is
the document clear enough on its own?" level. So you can ignore it, if the
answer is "yes, it's clear enough" :-)

Spencer

(*) and I saw your note on the IETF discussion list - thanks for sending it
there.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Christian,

On Sep 3, 2015 01:14, "Christian Grothoff"  wrote:
>
> On 09/03/2015 04:54 AM, Spencer Dawkins wrote:
> > I thought .onion was tied closely to the TOR protocol, so I have no idea
> > why the second sentence in this paragraph is here, or what it means, and
> > neither the string "TOR" nor the string "onion" appear in RFC 7230, so
> > chasing that reference didn't help.
> >
> >Like Top-Level Domain Names, .onion addresses can have an arbitrary
> >number of subdomain components.  This information is not meaningful
> >to the Tor protocol, but can be used in application protocols like
> >HTTP [RFC7230].
> >
> > Am I just being dense the night before a telechat, and everyone else
> > understands what this means and why it needs to be included in this
> > document?
> >
> > If this isn't clear to other people, could you either say more about
what
> > it means, or delete the second sentence?
> >
> > I'm not confused about the first sentence, only the second ...
>
> Spencer, let me explain in 2 sentences ;-).

Thank you for the speedy clarification!

> The Tor (router) ignores
> 'foo' in foo.KEYHASH.onion for the name lookup.  However, the Tor
> browser sends 'foo.KEYHASH.onion' to the HTTP server as part of the
> "Host:" header, so the server may act differently for
> 'foo.KEYHASH.onion' than for 'bar.KEYHASH.onion'. (This feature is
> typically used for "virtual" HTTP hosts where multiple servers share one
> IPv4 address.)

Those are two pretty great sentences!

Could that thought make it into the document? It helped a lot ...

Spencer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop