Re: [DNSOP] Working Group Last Call for "DNS Terminology" (draft-ietf-dnsop-rfc8499bis)

[Sara Dickinson]

Hi, 

LGTM.

I’ve opened a small PR to just update the DoQ references now there is an RFC:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-rfc8499bis/pull/12

Regards

Sara. 

> On 17 Feb 2023, at 15:51, Benno Overeinder  wrote:
> 
> Dear DNSOP WG,
> 
> Following the latest consultation with the Working Group on bailiwick and 
> in-domain/sibling name servers terminology, the authors and chairs believe 
> this document has reached the stage of being ready for Working Group Last 
> Call.
> 
> Due to normative reference to draft-ietf-dnsop-glue-is-not-optional (because 
> that draft explains what to do with the definitions in this draft), both 
> drafts will go to WGLC together.  (WGLC for glue-is-not-optional will be 
> issued early next week.)
> 
> 
> This starts a Working Group Last Call for: draft-ietf-dnsop-rfc8499bis.
> 
> Current versions of the draft is available here: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/.
> 
> The Current Intended Status of this document is: Best Current Practice.
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak 
> out with your reasons.
> Supporting statements that the document is ready are also welcome.
> 
> 
> This starts a two week Working Group Last Call process, and ends on: March 
> 3rd 2023
> 
> Thanks,
> 
> -- Benno
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] [IANA #1129407] Last Call: (C-DNS: A DNS Packet Capture Format) to Proposed Standard

[Sara Dickinson]

Hi All,

We’ve done another update to the draft to add a new section on IANA 
requirements. Hopefully this addresses all the questions on this topic - please 
review and let us know.

*** SINCE THIS SECTION WAS ABSENT IN THE -08 DOCUMENT ORIGINALLY REVIEWED BY 
IANA WE REQUEST RE-REVIEW OF THE -10 DOCUMENT ***

We made one other minor change - we realised there was still a reference to a 
SVG image of a graph in the appendix, we’ve replaced this with a table of the 
data values. 

We think we have now addresses all the issues from the IESG review - please let 
us know if we missed anything.

Best regards

Sara. 



> On 12 Dec 2018, at 13:15, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-10.txt
>   Pages   : 77
>   Date: 2018-12-12
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-10
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop






> On 13 Nov 2018, at 22:35, Amanda Baber via RT  
> wrote:
> 
> (BEGIN IANA COMMENTS)
> 
> IESG/Authors/WG Chairs:
> 
> The IANA Functions Operator has reviewed 
> draft-ietf-dnsop-dns-capture-format-08, which is currently in Last Call, and 
> has the following comments:
> 
> We understand that this document doesn't require any registry actions. 
> 
> While it's often helpful for a document's IANA Considerations section to 
> remain in place upon publication even if there are no actions, if the authors 
> strongly prefer to remove it, we do not object.
> 
> If this assessment is not accurate, please respond as soon as possible.
> 
> Thank you,
> 
> Amanda Baber
> Lead IANA Services Specialist
> 
> (END IANA COMMENTS)
> 
> On Tue Oct 30 13:10:21 2018, iesg-secret...@ietf.org wrote:
>> 
>> The IESG has received a request from the Domain Name System Operations
>> WG
>> (dnsop) to consider the following document: - 'C-DNS: A DNS Packet
>> Capture
>> Format'
>>   as Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> i...@ietf.org mailing lists by 2018-11-13. Exceptionally, comments may
>> be
>> sent to i...@ietf.org instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>> 
>> This document describes a data representation for collections of DNS
>> messages.  The format is designed for efficient storage and
>> transmission of large packet captures of DNS traffic; it attempts to
>> minimize the size of such packet capture files but retain the full
>> DNS message contents along with the most useful transport metadata.
>> It is intended to assist with the development of DNS traffic
>> monitoring applications.
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
>> 
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-
>> format/ballot/
>> 
>> The following IPR Declarations may be related to this I-D:
>> 
>> https://datatracker.ietf.org/ipr/2909/
> 

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

[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-dns-capture-format-09.txt

[Sara Dickinson]

Hi All, 

We’ve published an updated version of the draft that we hope addresses all the 
points raised in the reviews apart from describing the new IANA requirements 
for allocating/extending the various fields (and a couple of idnits).  We are 
working on a version to include that and hope to publish it next week. Please 
let us know if any other updates are needed. 

Best regards

Sara.  

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-09.txt
> Date: 30 November 2018 at 18:36:00 GMT
> To: 
> Cc: dnsop@ietf.org
> Reply-To: dnsop@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>  Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-09.txt
>   Pages   : 74
>   Date: 2018-11-30
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-09
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> On 24 Nov 2018, at 03:58, Benjamin Kaduk  <mailto:ka...@mit.edu>> wrote:
> 
> On Thu, Nov 22, 2018 at 12:01:00PM +0000, Sara Dickinson wrote:
>>> 
>>> Section 7.4.1.1.1
>>> 
>>> Am I parsing the "query-response-hints" text correctly to say that a bit is
>>> set in the bitmap if the corresponding field is recorded (if present) by
>>> the collecting implementation?  The causality of "if the field is omitted
>>> the bit is unset" goes in a direction that is not what I expected.
>>> (Similarly for the other fields in this table.)
>> 
>> ekr picked up on the same point - as responded to him:
>> 
>> "The issue is that if the bit is set the field might still be missing 
>> because although the configuration was set to collect it the data wasn’t 
>> available to the encoder from some other reason. However when the bit is not 
>> set it means that the data will definitely not be present because the 
>> collector is configured not to collect it. 
>> 
>> We do discuss this problem in section 6.2.1 - perhaps a reference in the 
>> table back to that discussion is what is needed?”
>> 
>> Looking again I think a slight update to the text in 6.2.1 might help too:
>> 
>> OLD:
>> “The Storage Parameters therefore also contains a Storage Hints item
>>  which specifies which items the encoder of the file omits from the
>>  stored data."
>> 
>> NEW: “The Storage Parameters therefore also contains a Storage Hints item
>>  which specifies which items the encoder of the file omits from the
>>  stored data and will therefore never be present. (This approach is taken 
>> because a flag that indicated which items were included for collection would 
>> not guarantee that the item was present, only that it might be.) "
> 
> This text helps, but I think it is not quite what I was going after -- that
> is, when I think of a "hint" that feels like something active and that
> would be indicated by setting a bit to one.  In this design, the hints
> about what are *omitted* are the bits that are *zero*, which is
> counter-intuitive, at least to me.  So maybe we could say (in 7.4.1.1.1, in
> addition to your suggested change in 6.2.1):
> 
> Hints indicating which "QueryResponse" fields are candidates for capture or
> omitted, see section 7.6.  If a bit is unset, that field is omitted from
> the capture.

Ah, ok I see the confusion now and yes - this text improves the draft - thank 
you!

> 
>> 
>>> 
>>> Section 7.4.2
>>> 
>>> Do we need a reference for "promiscuous mode”?
>> 
>> Promiscuous mode is discussed on the main PCAP manpage…. Hopefully a way
>> will be found to address the question of a suitable reference format for
>> PCAP material.
>> 
>>> 
>>> Just to check: in "server-addresses", I just infer the IP version from the
>>> length of the byte string?
>> 
>> As mentioned in the DISCUSS response, we probably need to make the transport 
>> flags mandatory.
>> 
>>> 
>>> Do we need to say more about where the vlan-ids identifiers are taken from?
>> 
>> Suggest: 
>> 
>> OLD: “ | vlan-ids | O | A | Array of identifiers (of type unsigned |
>>  |  |   |   | integer) of VLANs selected for |
>>  |  |   |   | collection. “
>> 
>> NEW: “ | vlan-ids | O | A | User specified array of identifiers (of 
>> type unsigned |
>>  |  |   |   | integer) of VLANs  [IEEE 802.1Q] selected for  
>>|
>>  |  |   |   | collection.  "
> 
> It seems likely to me that we want to say that the actual VLAN ID values
> are only unique within an administrative domain.

OK - yes, makes sense.

> 
>>> 
>>> Is the "generator-id" string intended to only be human readable?  Only
>>> within a specific (administrative) context?
>> 
>> The generator ID is intended only to identify the collecting
>> application. Specifying that it is human-readable (if present) seems a
>> good idea. Would this be sufficient?
>> 
>> OLD: "String identifying the collection method.”
>> NEW: “User specified human-readable string identifying the collection 
>> method."
> 
> Does "user-specified" mean that only the user is responsible for reading it
> later (or would we want it to make sense even when the data is conveyed to
> some other party)?

Yes - that’s correct. Maybe 'implementation specific' is better?

> If so, 

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> On 24 Nov 2018, at 03:35, Benjamin Kaduk  wrote:
> 
> On Wed, Nov 21, 2018 at 01:53:09PM +0000, Sara Dickinson wrote:
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Benjamin Kaduk mailto:ka...@mit.edu>>
>>> Subject: Benjamin Kaduk's Discuss on 
>>> draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
>>> Date: 19 November 2018 at 00:28:19 GMT
>>> To: "The IESG" mailto:i...@ietf.org>>
>>> Cc: draft-ietf-dnsop-dns-capture-for...@ietf.org 
>>> <mailto:draft-ietf-dnsop-dns-capture-for...@ietf.org>, Tim Wicinski 
>>> mailto:tjw.i...@gmail.com>>, dnsop-cha...@ietf.org 
>>> <mailto:dnsop-cha...@ietf.org>, tjw.i...@gmail.com 
>>> <mailto:tjw.i...@gmail.com>, dnsop@ietf.org <mailto:dnsop@ietf.org>
>>> Resent-From: mailto:alias-boun...@ietf.org>>
>>> Resent-To: j...@sinodun.com <mailto:j...@sinodun.com>, j...@sinodun.com 
>>> <mailto:j...@sinodun.com>, s...@sinodun.com <mailto:s...@sinodun.com>, 
>>> terry.mander...@icann.org <mailto:terry.mander...@icann.org>, 
>>> john.b...@icann.org <mailto:john.b...@icann.org>
>> 
>> Many thanks for the detailed review. 
>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> It is pretty shocking to not see any discussion of the privacy
>>> considerations of storing data including client addresses (and ports)
>>> alongside DNS transactions, given how central DNS resolution is to user
>>> behavior on the web.  (Note that there are mentions of potentially
>>> anonymized data in Sections 6.2 and 6.2.3 which would presumably
>>> forward-reference the privacy considerations.)  Data normalization would
>>> probably also be mentioned in this section, since (e.g.) the case used for
>>> a query/response could be used in fingerprinting an implementation.
>> 
>> There have been extensive discussion of data storage risks and practices in 
>> two DPRIVE documents so I’d suggest the following changes in the first 
>> instance to address this:
> 
> This is exactly the sort of thing I was hoping to see, thank you!  I have
> just a couple tweaks to suggest, inline.
> 
>> New Privacy Considerations section:
>> “ Storage of DNS traffic by operators in PCAP and other formats is a long 
>> standing and widespread practice. Section 2.5 of 
>> draft-bortzmeyer-dprive-rfc7626-bis is an analysis of the risks to Internet 
>> users of the storage of DNS traffic data in servers (recursive resolvers, 
>> authoritative and rogue server). 
>> 
>> Section 5.2 of draft-dickinson-dprive-bcp-op describes mitigations for those 
>> risks for data stored on recursive resolvers (but which could by extension 
>> apply to authoritative servers). These include data handling practices and 
>> methods for data minimisation, IP address pseudonymization and 
>> anonymization. Appendix B of that document presents an analysis of 7 
>> published anonymization processes. In addition RSSAC have recently published 
>> RSSAC04: " Recommendations on Anonymization Processes for Source IP 
>> Addresses Submitted for Future Analysis”[1].
>> 
>> The above analyses consider full data capture (e.g using PCAP) as a
>> baseline for privacy considerations and therefore this format
>> specification introduces no new user privacy issues beyond those of full
>> data capture. It does provides mechanisms to selectively record only
> 
> I would say "beyond those of full data capture (which are quite severe)".
> That is, while the current state of affairs is a valid baseline for
> comparison, that does not absolve us of responsibility for analyzing the
> current state of affairs.  (To be clear,
> draft-bortzmeyer-dprive-rfc7626-bis is a fine place for the bulk of that
> anlaysis to live, but in this document we should not pretend that the
> current state of affairs is a good situation to be in.)
> 
>> certain fields at the time of data capture to improve user privacy and to
>> explicitly indicate that data is sampled and or anonymised. It also
>> provide flags to indicate if data normalisation has been performed; data
>> normalisation increases user privacy by reducing the potential for
>> fingerprinting individuals however a trade-off is potentially reducing
> 
> I think "however" would be offset by commas on both sides.

Both these WFM - thanks.

And thanks for t

Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> From: Paul Hoffman 
> Subject: Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on 
> draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
> Date: 27 November 2018 at 14:59:51 GMT
> To: Alexey Melnikov 
> Cc: dnsop , The IESG 
> 
> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov  wrote:
>> 
>> On Tue, Nov 27, 2018, at 2:10 AM, Paul Hoffman wrote:
>>>  | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>>  |  |   |   | input. |
>>> 
>>> 
>>> On Nov 26, 2018, at 6:05 PM, Warren Kumari  wrote:
 ... that is where we started.
 The concern was what happens if there are new filters added, and 
 implementations written don't know how to deal with them.
>>> 
>>> New filters being added to tcpdump (or even removed) doesn't affect a C-
>>> DNS application from reading or writing that field. It's just a text 
>>> string. 
>> 
>> I think this depends on how the field is used.
>> 
>> If you want to write an application that validates or does something with 
>> this field, that wouldn't be true.
>> If you think that writing such an application is a dumb idea, then the draft 
>> should clearly state that.
> 
> My interpretation of the spec has been all along that this field, as well as 
> the other fields in CollectionParameters, were informational for whomever is 
> looking at the particular capture. "Parameters relating to how data in the 
> file was collected" seemed sufficient for that. If the authors added "These 
> parameters are informational are only informational and cannot necessarily be 
> validated by looking in the data captured", would that satisfy your concern?

Paul is correct in that the _intention_ of including these fields is just to 
provide informational meta data about the capturing process. I would suggest we 
change the first sentence of the section to be:

“Parameters providing information to how data in the file was collected 
(applicable for some, but not all collection environments). The values are 
informational only and serve as hints to downstream analysers as to the 
configuration of a collecting implementation. They can provide context when 
interpreting what data is present/absent from the capture but cannot 
necessarily be validated against the data captured.”

Given that, I’m hoping the short reference is acceptable 
http://www.tcpdump.org/manpages/pcap-filter.7.html? 
 

Regards

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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> Begin forwarded message:
> 
> From: Benjamin Kaduk mailto:ka...@mit.edu>>
> Subject: Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: 
> (with DISCUSS and COMMENT)
> Date: 19 November 2018 at 00:28:19 GMT
> To: "The IESG" mailto:i...@ietf.org>>
> Cc: draft-ietf-dnsop-dns-capture-for...@ietf.org 
> , Tim Wicinski 
> mailto:tjw.i...@gmail.com>>, dnsop-cha...@ietf.org 
> , tjw.i...@gmail.com 
> ,  dnsop@ietf.org 
> Resent-From: mailto:alias-boun...@ietf.org>>
> Resent-To: j...@sinodun.com , j...@sinodun.com 
> , s...@sinodun.com , 
> terry.mander...@icann.org , 
> john.b...@icann.org 
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: Discuss

To follow up on items not addressed in our previous email.

> --
> DISCUSS:
> --
> 
> There are also a couple of fields whose semantics don't seem to be
> sufficiently well specified for a proposed-standard document, such as
> vlan-ids, generator-id, name-rdata, and ae-code.  (I understand that some
> of them are probably only going to have locally relevant semantics, but we
> should be explicit about when that's the case.)

We have addressed the specific fields mentioned here in the comments below 
related to each of them.

> 
> 
> --
> COMMENT:
> --
> 
> Section 2
> 
> Please consider using the RFC 8174 version of the BCP 14 boilerplate.

Yes - will replace.

> 
> Section 3
> 
>   Because of these considerations, a major factor in the design of the
>   format is minimal storage size of the capture files.
> 
> maybe "storage and transmission”?

Sure.

> 
> Section 6
> 
> In Figure 2, the Query name is marked as "(q)" (only present if there is a
> query), but the running text in Section 4 (bullet 1) says that the Question
> section from the response can be used as an identifying QNAME if there is a
> response with no corresponding query.  Am I misexpanding QNAME here, or is
> there a disagreement between these two parts of the text?  In particular, I
> do not see a part of Figure 2 that would correspond to a Question section
> in the response, given the various "(q)"/"(r)" markings.

Good spot - you are correct this is an error in the diagram and it should read 
'Query name' with no qualifier. 

> 
> Section 6.2.2
> 
>   Messages with OPCODES known to the recording application but not
>   listed in the Storage Parameters are discarded (regardless of whether
>   they are malformed or not).
> 
> (Do we need to say anything that the "discarded" is only w.r.t. the capture
> process, and not meant to imply that DNS queries would not get a normal
> response?)

Suggest: “Messages with OPCODES known to the recording application but not
  listed in the Storage Parameters are discarded by the recording application 
  during C-DNS capture (regardless of whether they are malformed or not)."

> 
> Section 6.2.4
> 
> Please consider using IPv6 examples, per
> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ 
>  .

Yes - will add an IPv6 example.

> 
> Section 7.2
> 
>   o  The column T gives the CBOR data type of the item.
> 
>  *  U - Unsigned integer
> 
>  *  I - Signed integer
> 
> This is venturing a bit far from my normal area of expertise, but my
> understanding is that CBOR native major types are only provided for
> unsigned integer and negative integer, with "signed integer" being an
> abstraction at a slightly higher layer that needs to be managed in the
> application.  Do we need to add any clarifying text here or will the
> meaning be clear to the reader?

CDDL happily talks about uint and int types, but we think this might
indeed be a useful clarification to implementers. We suggest:

OLD: "* I - Signed integer"
NEW: "* I - Signed integer (i.e. CBOR unsigned or negative integer)"

> 
> Section 7.4
> 
> Should probably forward-reference section 8 for the format version numbers'
> semantics.

Yes, will do. 

> 
> Section 7.4.1.1
> 
> We should we reference the IANA registries by name for any of these fields
> (e.g., opcodes, rr-types, etc.).  (Also in Section 7.5.3.1, etc.)

I thought we had done this in the last update but clearly not, will fix.

> 
> Are the storage flags going to be allocated in sequence by updating
> standards-track documents, or some other mechanism?  (Is a registry
> necessary?)

As proposed for the DISCUSS this would be a sub registry.

> 
> For the various address prefix 

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

[Sara Dickinson]

> On 21 Nov 2018, at 03:24, Ben Campbell  wrote:
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: 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-dns-capture-format/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I support Benjamin's DISCUSS point about privacy considerations.
> 
> §2: Is there a reason not to use the boilerplate from RFC 8174? There are a
> number of lower case instances of normative keywords. These are ambiguous 
> under
> the RFC 2119 boilerplate.

Nope - will fix. Thanks

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

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> On 21 Nov 2018, at 17:33, Warren Kumari  wrote:
> 
> [ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ] 
> 
> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson  <mailto:s...@sinodun.com>> wrote:
> 
> 
>> On 21 Nov 2018, at 14:42, Alexey Melnikov > <mailto:aamelni...@fastmail.fm>> wrote:
> 
> Thanks for the quick response.
> 
>> 
>> Hi Sara,
>>>> 
>>>> 1)
>>>> 
>>>> In 7.4.2:
>>>> 
>>>>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>>>   |  |   |   | input. |
>>>> 
>>>> This makes the [pcap] reference Normative. If you don't want to do that, 
>>>> please
>>>> fully specify syntax in this document.
>>> 
>>> Is that true if it is an optional field? 
>> Yes, optionallity of a field doesn't make its full specification optional.
> 
> In which case it seems we can either include a more specific normative 
> reference here to this page:
> http://www.tcpdump.org/manpages/pcap-filter.7.html 
> <http://www.tcpdump.org/manpages/pcap-filter.7.html>
> 
> or reproduce this page in an appendix. I’d prefer the former unless a 
> reference to such a web page would prove problematic as a normative 
> reference? 
> 
> We discussed this on the telechat, and I took the action to try look into 
> this.
> One of the concerns with a normative reference to the webpage is what happens 
> if it is updated to add a new primitive - is it allowed? If someone 
> implements this on Thursday, can they still claim conformance if a new 
> primitive is added on Friday?
> 
> What we made up on the call was to simply grab a copy of 
> http://www.tcpdump.org/manpages/pcap-filter.7.html 
> <http://www.tcpdump.org/manpages/pcap-filter.7.html> (it seems to be under 
> the BSD license) and put it somewhere on ietf.org <http://ietf.org/>, so we 
> have a stable snapshot to reference, and ask you to point to that.
> But, this was simply us making stuff up on the fly - I'm hoping that the RFC 
> Editor can tell us if this is sane or the worst idea ever, or what….

Thanks for the update, we’ll hold off till we hear more on this. 

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

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

[Sara Dickinson]

> Begin forwarded message:
> 
> From: Eric Rescorla 
> Subject: Eric Rescorla's No Objection on 
> draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)
> Date: 21 November 2018 at 02:07:20 GMT
> To: "The IESG" 
> Cc: Tim Wicinski , tjw.i...@gmail.com, dnsop@ietf.org, 
> dnsop-cha...@ietf.org, draft-ietf-dnsop-dns-capture-for...@ietf.org
> Resent-From: 
> Resent-To: j...@sinodun.com, j...@sinodun.com, s...@sinodun.com, 
> terry.mander...@icann.org, john.b...@icann.org
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: No Objection

Hi, 

Many thanks for the review


> --
> COMMENT:
> --
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4670
> 
> 
> I support Ben's DISCUSS.

Ack - hopefully our response to him addresses your concerns.

> 
> Am I understanding the design correctly in that you can't have
> literals in the individual per-query values, but instead references to
> the block tables, so you can't stream inside a block?

Yes, that is correct - do you think we need to add text to clarify this?

> 
> IMPORTANT
> S 7.5.1.
>> | earliest-time| O | A | A timestamp (2 unsigned integers,  |
>> |  |   |   | "Timestamp") for the earliest record   |
>> |  |   |   | in the "Block" item. The first integer |
>> |  |   |   | is the number of seconds since the |
>> |  |   |   | Posix epoch ("time_t"). The second |
>> |  |   |   | integer is the number of ticks since   |
> 
> I don't know what a "tick" is, so you need some definitionf or this.

From 7.4.1.1:

ticks-per-second | M | U | Sub-second timing is recorded in   |
   |  |   |   | ticks. This specifies the number of|
   |  |   |   | ticks in a second. 

This was the solution to a request to allow flexibility in how granular the 
sub-second timing increments are. 

> 
> COMMENTS
> S 7.2.
>> 
>> o  The column O marks whether items in a map are optional.
>> 
>>*  O - Optional.  The item may be omitted.
>> 
>>*  M - Mandatory.  The item must be present.
> 
> FWIW, I think you might be happier with a mandatory "X" and optional
> nothing, but that's up to you.

Yeah - this might make more sense. 

> 
> 
> S 7.4.1.1.1.
>> 
>> +--+---+---++
>> | Field| O | T | Description|
>> +--+---+---++
>> | query-response   | M | U | Hints indicating which "QueryResponse" |
>> | -hints   |   |   | fields are omitted, see section|
> 
> Nit: generally, you would say "indicating which fields are included"
> if 1 means included.

The issue is that if the bit is set the field might still be missing because 
although the configuration was set to collect it the data wasn’t available to 
the encoder from some other reason. However when the bit is not set it means 
that the data will definitely not be present because the collector is 
configured not to collect it. 

We do discuss this problem in section 6.2.1 - perhaps a reference in the table 
back to that discussion is what is needed?

> 
> 
> S 7.5.3.
>> +-+---+---+-+
>> 
>>  7.5.3.  "BlockTables"
>> 
>> Arrays containing data referenced by individual "QueryResponse" or
>> "MalformedMessage" items in this "Block".  Each element is an array
> 
> This is not a sentence.

Suggest: “Map of arrays containing data... "

> 
> 
> S 7.5.3.
>> | qrr   | O | A | Array of type "Question". Each entry  |
>> |   |   |   | is the contents of a single question, |
>> |   |   |   | where a question is the second or |
>> |   |   |   | subsequent question in a query. See   |
>> |   |   |   | Section 7.5.3.3.  |
>> |   |   |   |   |
> 
> So if I understand this correctly:
> 
> QRR is a map of integers to question
> QLIST is a map of integers to question lists, with each question list
> consisting of a set of indexes int o QRR?

Yes, exactly.

> 
> 
> 
> S 7.5.3.2.
>> 
>> ++---+---+--+
>> | Field  | O | T | Description  |
>> ++---+---+--+
>> | server-address | O | U | The index in the item in the "ip-|
>> | -index |   |   | address" array of the server IP  |
> 
> So am I understanding correctly that you can't put the server address
> literally 

Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

[Sara Dickinson]

> On 21 Nov 2018, at 02:09, Adam Roach  wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: No Objection

Hi Adam. 

Many thanks for the review.

> --
> COMMENT:
> --
> 
> 
> 
> I support Benjamin's DISCUSS regarding a treatment of the privacy issues 
> related
> to this capture format.

Please see our reply to Benjamin.

> ---
> 
> id-nits reports:
> 
>  ** There are 11 instances of too long lines in the document, the longest
> one being 9 characters in excess of 72.

These all appear to be in the CDDL definition. We'll fix the formatting there.

>  -- The document has examples using IPv4 documentation addresses according
> to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
> there should be IPv6 examples, too?
> 
> (See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ 
>  for more information
> about the second issue)

Agreed. We'll add an IPv6 example, and position it before the IPv4 example.

> ---
> 
> §5:
> 
>> o  CBOR is an IETF standard and familiar to IETF participants.  It is
> 
> While CBOR is standards-track, it's nowhere near standard yet. Suggest:
> "...is an IETF specification..." (See BCP 9)
> 
> ---

Agreed, thanks for the wording.

> §9.1:
> 
>> DNS style name compression is used on the individual names within the
> 
> Nit: "DNS-style"

Perhaps a better clarification is to say:

OLD: "DNS style name compression is used..."

NEW: "[RFC1035] name compression is used..."

> ---
> 
> Appendix A:
> 
>>  file-type-id  : tstr .regexp "C-DNS",
> 
> I'm far from a CDDL expert, but I just read through that specification, and it
> seems to me that this is a bit overwrought. I think you can accomplish the 
> same
> with the much simpler production:
> 
>file-type-id  : "C-DNS",

Version 0.8.5 and previous of the 'cddl' generation/validation tool
outputs the above as a numeric quantity, h'432D444E53'. The latest
version 0.8.6 seems to get this right and outputs "C-DNS".

> Similarly:
> 
>>  major-format-version => uint .eq 1,
>>  minor-format-version => uint .eq 0,
> 
> would seem to mean the same as the simpler:
> 
>>  major-format-version => 1,
>>  minor-format-version => 0,

'cddl' does seem to output the correct values here.

We've erred on the side of a more explicit definition in the hope that
this is clearer for implementers. But perhaps this is a good question 
for the CBOR WG as to what is the preferred style - we can ask?

> ---
> 
> Appendix B:
> 
>> The next name added is bar.com .  This is matched against 
>> example.com .
> 
> bar.com  is allocated to a private individual who has 
> already had to contend with
> a lot of unwanted traffic (see https://www.bar.com/  
> for details). We should
> consider not making things worse for them. Please use an RFC 2606 address
> instead.

Good point. We will change the names in the next version of the draft
from example.com and bar.com to foo.example and bar.example.

Best regards

Sara.


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

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

[Sara Dickinson]

> On 21 Nov 2018, at 10:58, Alissa Cooper  wrote:
> 
> 
> 
>> On Nov 20, 2018, at 9:01 PM, Joe Abley  wrote:
>> 
>> Hi Alissa!
>> 
>> On Nov 20, 2018, at 20:18, Alissa Cooper  wrote:
>> 
>>> I support Benjamin's first DISCUSS point. In addition to documenting the
>>> privacy considerations, I think it's important for this document to be 
>>> crystal
>>> clear about who is meant to be doing the data collection -- namely, the 
>>> server
>>> operator. There are some statements in the document that otherwise could be
>>> construed to be encouraging third-party passive monitoring of DNS traffic
>>> without explaining why, which seems like a problem:
>> 
>> I think it may be worth exploring why that's a problem.
>> 
>> I think a capture format should be oblivious to the circumstances of
>> the capture;
> 
> Ok. This document is not at all oblivious, though (see Section 3). I read the 
> document to be implicitly assuming the server operator to be doing (or at 
> least in control of) the data collection, which is why the two statements I 
> pointed out seemed so striking for their lack of declaring that limitation. 
> If the document was meant to be oblivious, it shouldn’t make normative (in 
> the dictionary definition sense) claims about what is ideal, optimal, or 
> necessary. 

Hi Alissa, 

If we update the statements as below to clarify the context would that address 
your concern?

Section 1:
OLD:
"There has long been a need to collect DNS queries and responses on
  authoritative and recursive name servers for monitoring and analysis.”

NEW”
“There has long been a need for server operators to collect DNS queries and 
responses on
  authoritative and recursive name servers for monitoring and analysis.”

Section 3:

OLD:
"In an ideal world, it would be optimal to collect full packet
  captures of all packets going in or out of a name server.”

NEW:
“From a purely server operator perspective, collecting full packet
 captures of all packets going in or out of a name server provides the 
 most comprehensive picture of network activity.”

Sara.


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

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> On 21 Nov 2018, at 14:42, Alexey Melnikov  wrote:

Thanks for the quick response.

> 
> Hi Sara,
>>> 
>>> 1)
>>> 
>>> In 7.4.2:
>>> 
>>>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>>   |  |   |   | input. |
>>> 
>>> This makes the [pcap] reference Normative. If you don't want to do that, 
>>> please
>>> fully specify syntax in this document.
>> 
>> Is that true if it is an optional field? 
> Yes, optionallity of a field doesn't make its full specification optional.

In which case it seems we can either include a more specific normative 
reference here to this page:
http://www.tcpdump.org/manpages/pcap-filter.7.html 


or reproduce this page in an appendix. I’d prefer the former unless a reference 
to such a web page would prove problematic as a normative reference? 

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

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> On 19 Nov 2018, at 20:37, Alexey Melnikov  wrote:

Hi Alexey, 

Thanks for the review.

> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: Discuss
> --
> DISCUSS:
> --
> 
> Thank you for this document, it is a useful contribution to RFC series. I
> enjoyed reading it.
> 
> I have a small list of issues that is hopefully easy to fix:
> 
> 1)
> 
> In 7.4.2:
> 
>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>   |  |   |   | input. |
> 
> This makes the [pcap] reference Normative. If you don't want to do that, 
> please
> fully specify syntax in this document.

Is that true if it is an optional field? 

> 
> 2) I believe [I-D.ietf-cbor-cddl] reference needs to be Normative due to use 
> of
> CDDL in Appendix A. If you don't think CDDL is normative, you need to state
> that in Appendix A.

Yes indeed - it should be normative, will fix. 


> 
> --
> COMMENT:
> --
> 
> Was CDDL in Appendix A validated with a tool? This information is missing from
> the shepherding write-up.

We (the authors) have used the CDDL tool described on http://cbor.io/tools.html 
 to read the CDDL in Appendix A and ensured an 
example instance can be created. 

Did you have some other validation tool in mind?

> 
> 6.2.3.  Storage flags
> 
>   The Storage Parameters also contains optional fields holding details
>   of the sampling method used and the anonymisation method used.  It is
>   RECOMMENDED these fields contain URIs pointing to resources
>   describing the methods used.
> 
> Please add a Normative Reference for URI spec here (RFC 3986).

Yes, will do. 

> 
> 7.5.3.2.  "QueryResponseSignature"
> 
>   | qr-transport-flags | O | U | Bit flags describing the transport   |
>   ||   |   | used to service the query.   |
>   ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
>   ||   |   | IPv6 |
>   ||   |   | Bit 1-4. Transport. 4 bit unsigned   |
>   ||   |   | value where 0 = UDP, 1 = TCP, 2 =|
>   ||   |   | TLS, 3 = DTLS. Values 4-15 are   |
>   ||   |   | reserved for future use. |
>   ||   |   | Bit 5. 1 if trailing bytes in query  |
>   ||   |   | packet. See Section 11.2.|
> 
> Would something like DoH appear as a separate transport choice?

No, we need to add DoH to this list (it didn’t exist when we started the 
draft!). 

> 
> How can new values be added to the list if there are no IANA Considerations?

As described in response to the DISCUSS on this issue we propose IANA create a 
C-DNS registry with
subregistries with keys for each of the different maps used in C-DNS.
New entries in these subregistries would follow Expert Review 

> 
> 7.5.3.5.  "MalformedMessageData"
> 
>   ||   |   |  |
>   | mm-transport-flags | O | U | Bit flags describing the transport   |
>   ||   |   | used to service the query. Bit 0 is  |
>   ||   |   | the least significant bit.   |
>   ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
>   ||   |   | IPv6 |
>   ||   |   | Bit 1-4. Transport. 4 bit unsigned   |
>   ||   |   | value where 0 = UDP, 1 = TCP, 2 =|
>   ||   |   | TLS, 3 = DTLS. Values 4-15 are   |
>   ||   |   | reserved for future use. |
> 
> If the above bits supposed to be the same as for qr-transport-flags,
> maybe it is worth defining them once and referencing in all relevant places?

The qr-transport-flags and mm-transport-flags are different in that the 
qr-transport-flags include Bit 5, the trailing bytes indicator.

In the CDDL a base ’TransportFlags’ type is defined and then

mm-transport-flags => TransportFlags,

qr-transport-flags=> QueryResponseTransportFlags,

 QueryResponseTransportFlagValues = &(
  query-trailingdata : 5,
  ) / TransportFlagValues
  QueryResponseTransportFlags = uint .bits QueryResponseTransportFlagValues

We can add some text to the table descriptions in sections 7.5.3.2 and 7.5.3.5 
to clarify the relationship. 

> 
> 7.6.  "QueryResponse"
>   | query-size   | O | U | DNS query message size (see|
>   |  |   |   | below).|
>   |  |   |   | 

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> Begin forwarded message:
> 
> From: Benjamin Kaduk mailto:ka...@mit.edu>>
> Subject: Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: 
> (with DISCUSS and COMMENT)
> Date: 19 November 2018 at 00:28:19 GMT
> To: "The IESG" mailto:i...@ietf.org>>
> Cc: draft-ietf-dnsop-dns-capture-for...@ietf.org 
> , Tim Wicinski 
> mailto:tjw.i...@gmail.com>>, dnsop-cha...@ietf.org 
> , tjw.i...@gmail.com 
> , dnsop@ietf.org 
> Resent-From: mailto:alias-boun...@ietf.org>>
> Resent-To: j...@sinodun.com , j...@sinodun.com 
> , s...@sinodun.com , 
> terry.mander...@icann.org , 
> john.b...@icann.org 

Many thanks for the detailed review. 

> 
> --
> DISCUSS:
> --
> 
> It is pretty shocking to not see any discussion of the privacy
> considerations of storing data including client addresses (and ports)
> alongside DNS transactions, given how central DNS resolution is to user
> behavior on the web.  (Note that there are mentions of potentially
> anonymized data in Sections 6.2 and 6.2.3 which would presumably
> forward-reference the privacy considerations.)  Data normalization would
> probably also be mentioned in this section, since (e.g.) the case used for
> a query/response could be used in fingerprinting an implementation.

There have been extensive discussion of data storage risks and practices in two 
DPRIVE documents so I’d suggest the following changes in the first instance to 
address this:

New Privacy Considerations section:
“ Storage of DNS traffic by operators in PCAP and other formats is a long 
standing and widespread practice. Section 2.5 of 
draft-bortzmeyer-dprive-rfc7626-bis is an analysis of the risks to Internet 
users of the storage of DNS traffic data in servers (recursive resolvers, 
authoritative and rogue server). 

Section 5.2 of draft-dickinson-dprive-bcp-op describes mitigations for those 
risks for data stored on recursive resolvers (but which could by extension 
apply to authoritative servers). These include data handling practices and 
methods for data minimisation, IP address pseudonymization and anonymization. 
Appendix B of that document presents an analysis of 7 published anonymization 
processes. In addition RSSAC have recently published RSSAC04: " Recommendations 
on Anonymization Processes for Source IP Addresses Submitted for Future 
Analysis”[1].

The above analyses consider full data capture (e.g using PCAP) as a baseline 
for privacy considerations and therefore this format specification introduces 
no new user privacy issues beyond those of full data capture. It does provides 
mechanisms to selectively record only certain fields at the time of data 
capture to improve user privacy and to explicitly indicate that data is sampled 
and or anonymised. It also provide flags to indicate if data normalisation has 
been performed; data normalisation increases user privacy by reducing the 
potential for fingerprinting individuals however a trade-off is potentially 
reducing the capacity to identify attack traffic via query name signatures. 
Operators should carefully consider their operational requirements and privacy 
policies and SHOULD capture at source the minimum user data required to meet 
their needs“

[1] https://www.icann.org/en/system/files/files/rssac-040-07aug18-en.pdf 



As noted, there are a few other places we can also highlight the privacy 
aspects:

Introduction:
OLD: “The PCAP [pcap] or PCAP-NG [pcapng] formats are typically used in 
practice for packet captures, but these file formats can contain a great deal 
of additional  information that is not directly pertinent to DNS traffic 
analysis  and thus unnecessarily increases the capture file size.”

NEW: “The PCAP [pcap] or PCAP-NG [pcapng] formats are typically used in 
practice for packet captures, but these file formats can contain a great deal 
of additional  information that is not directly pertinent to DNS traffic 
analysis  and thus unnecessarily increases the capture file size. Additionally 
these tools and format typically have no filter mechanism to selectively record 
only certain fields at capture time, requiring post-processing for 
anonymisation or pseudonymistaion of data to protect user privacy.

Section 4, bullet point 2:

OLD: “Different users will have different requirements
  for data to be available for analysis.  Users with minimal
  requirements should not have to pay the cost of recording full
  data, though this will limit the ability to perform certain
  kinds of data analysis 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-08.txt

[Sara Dickinson]

Hi All, 

This update attempts to address the issues raised in WGLC

- Add a new section on versioning
- Address issue with CDDL validation relating the Transport flags

We’ve also bitten the bullet (I say we but Jim stepped up heroically for this 
:-)) and converted the SVG pictures to glorious ACSII art as the RFC tools are 
not ready and we do not want to hold up progressing the draft. Review of these 
would be appreciated. 

Sara. 


> On 10 Aug 2018, at 16:27, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-08.txt
>   Pages   : 69
>   Date: 2018-08-10
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-08
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-08
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

[Sara Dickinson]

+1 for adoption and willing to review

Sara. 

> On 25 Jul 2018, at 04:31, Davey Song(宋林健)  wrote:
> 
> +1
>  
> DNS privacy is an important issue. I support this adoption. And I’m willing 
> to review it. 
>   <>
> Davey
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org ] 代表 
> Tim Wicinski
> 发送时间: 2018年7月25日 0:33
> 收件人: dnsop
> 主题: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis
>  
>  
> We discussed this and there appears to be support to adopt this, with
> the caveat of adding more content to the section on Operational 
> Considerations.
>  
>  
> This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis
>  
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/ 
> 
>  
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>  
> Please also indicate if you are willing to contribute text, review, etc.
>  
> This call for adoption ends: 9 August 2018
>  
> Thanks,
> tim wicinski
> DNSOP co-chair
>  
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Sara Dickinson]

I also support adoption of this draft - it is attempting to address a genuine 
impediment to deploying DNSSEC and I think this group is the right place to 
work on it.

As mentioned at the mic in Montreal, I’d like to see it additionally reflect 
how the proposals here feed into the process for moving vendors after 
deployment. 

Sara.

> On 18 Jul 2018, at 11:13, Yoshiro YONEYA  wrote:
> 
> I support this draft to be WG I-D.
> 
> -- 
> Yoshiro YONEYA 
> 
> On Fri, 6 Jul 2018 20:26:59 -0400 Tim Wicinski  wrote:
> 
>> We've had some interest in moving this document forward, and the chairs
>> wanted to kick off this Call for Adoption before Montreal so if there
>> are concerns there will be some meeting time to address.
>> 
>> This document is label as: Informational.  The document is attempting
>> to document operational deployment models on deploying DNSSEC signed
>> zones across multiple platforms.
>> 
>> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec
>> 
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/
>> 
>> Please review this draft to see if you think it is suitable for
>> adoption by DNSOP, and comments to the list, clearly stating your view.
>> The authors will be at the next meeting to address questions or concerns.
>> 
>> Please also indicate if you are willing to contribute text, review, etc.
>> 
>> This call for adoption ends: 20 July 2018
>> 
>> Thanks,
>> Tim
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] QNAME minimisation on the standards track?

[Sara Dickinson]

> On 17 Jul 2018, at 17:35, Paul Wouters  wrote:
> 
> On Tue, 17 Jul 2018, tjw ietf wrote:
> 
>> Subject: Re: [DNSOP] QNAME minimisation on the standards track?
>> I’d like to see a more fleshed out operational considerations section.
> 
> That would be good indeed. Especially with respect to broken DNS load
> balancers.
> 
> I have enabled it in Fedora from the start and did run into a few problem
> domains, and some people turning it off. But that happened less than I
> had expected. Red Hat did not yet enable this in RHEL7 but it is planned
> to be enabled in RHEL8.
> 
> But I do believe qname minimisation is an important privacy enhancing
> technology that we should strongly promote as a standards track
> document.

+1

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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Sara Dickinson]

Hi all, 

Two questions came up recently when writing the DNS Privacy BCP with respect to 
terminology (and on the dns-operations list):

1) What do folks think about adding a new definition to this document for a 
shortened term for DNS-over-TLS? Since  we now have DoH I’ve often taken to 
referring to DNS-over-TLS as DoT in talks and presentations. But this isn’t an 
acronym used in any standard and it is also potentially confused with meaning 
DNS-over-TCP  (and there is also a DOTS WG at IETF). DoTLS and DoTCP have also 
been proposed which work well in written form, but don’t sound as good, so we 
could consider DoT and DoTCP? Other ideas?

2) The second questions is if it is worth including DoH client/server 
definitions here and also updating the definition of 'Privacy-enabling DNS 
server’ from RFC8310 in this draft to include servers that implement DoH and/or 
DNS-over-TLS. I suspect having one term for such servers might make some of the 
anticipated DRUI work easier, but I realise including DoH could create 
dependancy problems  :-)

Regards

Sara. 


> On 22 Jun 2018, at 21:01, Suzanne Woolf  wrote:
> 
> Colleagues,
> 
> This begins the working group last call for 
> draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has 
> gotten significant feedback and the editors have worked hard to document 
> current terminology usage, both among practitioners and for broader 
> audiences; we’d like to advance it.
> 
> We’re seeking consensus to advance it to the IESG with an intended status of 
> Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the 
> earlier “DNS Terminology” document). 
> 
> If you support it, please say so. If you don’t, please say why.
> 
> The current version is at: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
> 
> Last Call will run for two weeks, closing on Friday July 6. This will allow 
> for discussion of any major outstanding issues at IETF 102.
> 
> 
> thanks,
> Suzanne, Tim, & Benno
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-07.txt

[Sara Dickinson]

Hi All, 

This update addresses the following issues:

* Resolve outstanding questions and TODOs
* Make RR RDATA optional
* Update matching diagram and explain skew
* Add count of discarded messages to block statistics
* Editorial clarifications and improvements

Regards

Sara. 

> On 8 May 2018, at 17:40, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-07.txt
>   Pages   : 64
>   Date: 2018-05-08
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-07
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Blog Post: DNS over TLS support in Android P Developer Preview

[Sara Dickinson]

> On 13 Apr 2018, at 20:49, Warren Kumari  wrote:
> 
> Hi all,
> 
> As Erik Kline and Ben Schwartz seem to be too modest to toot their own
> horn, I'll do it for them:
> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>  
> 

Yes - great work by those folks! Ben also gave a talk about this at the DNS 
Privacy workshop in February if you want to watch the video:

https://www.youtube.com/watch?v=9xO6kSgvtOQ=3=PL5i3urU7m33XR1GtR0UZWi4fdX01W2bOZ
 



> 
> Snippet from the above:
> "The Android P Developer Preview includes built-in support for DNS
> over TLS. We added a Private DNS mode to the Network & internet
> settings.
> 
> By default, devices automatically upgrade to DNS over TLS if a
> network's DNS server supports it. But users who don't want to use DNS
> over TLS can turn it off."
> 
> W
> (Also posted to dprive)
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-06.txt

[Sara Dickinson]

Hi All, 

This update makes a few minor updates based on the most recent feedback. 

* Correct BlockParameters type to map
* Make RR ttl optional
* Add storage flag indicating name normalisation
* Add storage parameter fields for sampling and anonymisation methods
* Editorial clarifications and improvements

Sara. 

> On 5 Mar 2018, at 19:24, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-06.txt
>   Pages   : 63
>   Date: 2018-03-05
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-06
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-05.txt

[Sara Dickinson]

Hi Folks, 

We have an update to draft which we hope captures all the comments to-date. 

- Make all data items in Q/R, QuerySignature and Malformed Message arrays 
optional
- Re-structure the FilePreamble and ConfigurationParameters into BlockParameters
- BlockParameters has separate Storage and Collection Parameters
- Storage Parameters includes information on what optional fields are present, 
and flags specifying anonymisation or sampling
- Addresses can now be stored as prefixes.
- Switch to using a variable sub-second timing granularity
- Add response bailiwick and query response type
- Add specifics of how to record malformed messages
- Add implementation guidance
- Improve terminology and naming consistency

There are still a number of ‘QUESTIONS’ in the draft that we would appreciate 
feedback on. 

Regards

Sara. 

> On 22 Feb 2018, at 12:27, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-05.txt
>   Pages   : 62
>   Date: 2018-02-22
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-05
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-04.txt

[Sara Dickinson]

Hi All, 

This is a very minor update (to avoid expiration), a more significant one is in 
the works.

Sara. 


> On 3 Jan 2018, at 17:02, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-04.txt
>   Pages   : 50
>   Date: 2018-01-03
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

[Sara Dickinson]

Hi All, 

Based on the discussions at IETF 99 and on the list this update to the draft 
makes a number of changes:

* The Title of the draft has been changed to ‘DNS Stateful Operations’ (DSO) to 
reflect the fact that the TLV format is not limited to being used for signalling
* The draft now updates RFC1035
* The term 'DSO session’ is used throughout for clarity
* A paragraph has been added to the Introduction to discuss the use of a new 
format
* Several terms in the Terminology section have been updated and some new ones 
added
* Clarified the use of the words timer and timeout throughout the document
* A short discussion section has been added with specific use cases
* The specific mention of QUIC has been removed, the text now just describe the 
properties of the transport used for DSO. 
* The text has been updated to specify that messages must be processed in the 
order they were sent (not received)
* A modifier Encrypted Padding TLV has been added to support padding of 
encrypted queries
* The text describing the behaviour of middle-boxes has been updated
* The set of RCODES defined in the document has been extended
* Responses to DSO messages are now optional: An Acknowledgement bit has been 
added to the DSO data format which specifies if the DSO message requires an 
acknowledgement response
* A section has been added to specify exactly what a client should to with the 
timers/timeouts when receiving a Keepalive TLV
* The section on Connection sharing is now consistent with RFC7766

Regards

Sara. 

> On 13 Sep 2017, at 10:28, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : DNS Stateful Operations
>Authors : Ray Bellis
>  Stuart Cheshire
>  John Dickinson
>  Sara Dickinson
>  Allison Mankin
>  Tom Pusateri
>   Filename: draft-ietf-dnsop-session-signal-04.txt
>   Pages   : 32
>   Date: 2017-09-13
> 
> Abstract:
>   This document defines a new DNS Stateful Operation OPCODE used to
>   communicate operations within persistent stateful sessions, expressed
>   using type-length-value (TLV) syntax, and defines an initial set of
>   TLVs used to manage session timeouts and termination.  This mechanism
>   is intended to reduce the overhead of existing "per-packet" signaling
>   mechanisms with "per-message" semantics as well as defining new
>   stateful operations not defined in EDNS(0).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[Sara Dickinson]

> On 25 May 2017, at 18:00, John Kristoff  wrote:
> 
> 
>> Section 2: I think it might be useful to include a section in section
>> 2 describing the fact that the lack of, or very limited
>> implementation of TCP also fed the perception that it was a security
>> risk.
> 
> The references
> 
>  Cheswick, W. and S. Bellovin book

I sadly don’t have a copy of that book to hand so I can’t comment on the 
content there…. 

>  
> in section 2.4 I think may largely sums up the general concern.
> Maybe the section 2.4 is not correctly titled or incompletely detailed
> to highlight your point.  Any specific text or additional references are
> welcome of course.

How about:

   “There are many in the DNS community who configure DNS over TCP services and 
expect DNS over TCP transactions
   to occur without interference. However there has also been a long held belief
   by some operators, particularly for security-related reasons,
   that DNS over TCP services should be purposely limited or not provided at 
all [CHES94], [DJBDNS].  
   A popular meme has also held the imagination of some that DNS over TCP is 
only ever used for zone
   transfers and is generally unnecessary otherwise, with filtering all
   DNS over TCP traffic even described as a best practice. 
   
   The position on restricting DNS over TCP had some justification given that 
historic implementations of DNS nameservers provided
   very little in the way of TCP connection management (for example see Section 
6.1.2 of [RFC7766] 
   for more details). However modern standards and implementations are moving 
to align with the more
   sophisticated TCP management techniques employed by, for example, HTTP(S) 
servers and load balancers. 

> 
>> And since it is stated as TCP related development should RFC2136 be
>> there (even though it is discussed earlier)?
> 
> Probably should be there.  Need I worry about section 6's length at
> all?  It could take up a significant portion of the document given the
> way this section is going.  Note, this section was added based on some
> earlier feedback that having this sort of list might be helpful.

If it gets too long then perhaps I could be moved to an Appendix? I think it is 
very useful for reference but as you say it should not necessarily dominate the 
document. 

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[Sara Dickinson]

> On 11 May 2017, at 11:57, tjw ietf  wrote:

> This starts a Call for Adoption for: draft-kristoff-dnsop-dns-tcp-requirements
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ 
> 
Hi, 

I’ve reviewed this draft and as stated previously support adoption as a 
companion document to RFC7766. 

Minor comments:

Section 2.2: I think the argument around DNSSEC can be bolstered by the fact 
that recent root ZSK and upcoming KSK rollovers involved large responses. 

Section 2: I think it might be useful to include a section in section 2 
describing the fact that the lack of, or very limited implementation of TCP 
also fed the perception that it was a security risk. 

Section 6.3  s/[RFC7766] is might be/[RFC7766] might be/

Should there be a section in Section 6 about RFC7858 (DNS-over-TLS)? And since 
it is stated as TCP related development should RFC2136 be there (even though it 
is discussed earlier)?

How about including a reference to 
https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ 
 ?

Regards

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

Re: [DNSOP] The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state "Candidate for WG Adoption"

[Sara Dickinson]

> On 6 Apr 2017, at 19:42, Bob Harold  wrote:
> 
> 
> On Tue, Mar 28, 2017 at 4:34 PM, IETF Secretariat 
> > 
> wrote:
> 
> The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in
> state
> Candidate for WG Adoption (entered by Tim Wicinski)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ 
> 
> 
> 
> I support adoption

+1

> and will review.

Me too. 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-01.txt

[Sara Dickinson]

Hi All, 

This update to the draft tries to address the recent comments:

* Many editorial improvements by Paul Hoffman

* Included discussion of malformed packet handling

* Improved Appendix C on Comparison of Binary Formats

* Now using C-DNS field names in the tables in section 8

* A handful of new fields included (CDDL updated)

* Timestamps now include optional picoseconds

* Added details of block statistics

Regards

Sara. 

> On 21 Feb 2017, at 11:36, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-01.txt
>   Pages   : 48
>   Date: 2017-02-21
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Soliciting feedback for draft-kristoff-dnsop-dns-tcp-requirements

[Sara Dickinson]

> On 21 Oct 2016, at 16:46, Paul Hoffman  wrote:
> 
> On 16 Oct 2016, at 8:22, John Kristoff wrote:
> 
>> If I could trouble you to consider reviewing this and provide any
>> comments you might have about it, that would be appreciated.  Thank you.
>> 
>>  DNS Transport over TCP - Operational Requirements
>>  
>> 
>> Abstract
>> 
>>   This document encourages the practice of permitting DNS messages to
>>   be carried over TCP on the Internet.  It also describes some of the
>>   consequences of this behavior and the potential operational issues
>>   that can arise when this best common practice is not applied.
> 
> The document is well-written and a fairly neutral history of TCP use in DNS, 
> but I don't see any of what I would call "requirements". Section 3 is a 
> discussion, not a list of requirements.
> 
> If this document has some concrete requirements (along with the history that 
> is there), I would support this as a WG document.

TL;DR

I think this document is useful and worthwhile, however I broadly agree with 
Paul that it needs more substance than it currently contains. I’d like to see 
it go further than saying ‘don’t turn TCP off for DNS’, and attempt to guide 
operators on how to offer robust DNS-over-TCP service, in which case I would 
support it being adopted and be willing to contribute. But it isn’t clear to me 
if that is really the intention of this document?

Regardless, some suggestions on additions to the document:

- I think the early sections are missing discussion of the historic, simplistic 
implementations (in both clients and servers) of TCP support that resulted in 
non-optimal performance of DNS-over-TCP. This increased the perception that 
DNS-over-TCP was inherently less performant then UDP and presented significant 
operation issues.

- I’d like to see the last two sentences of Section 2 broken out into their own 
section and include a brief discussion of RFC7858 since TCP support is a 
pre-requisite for DNS-over-TLS. 

- I think Section 3 could be expanded to also discuss operational guidance on 
TCP tuning for DNS - possibly referencing or reproducing parts of 
https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ 


- Similarly I think it would be helpful to see operational guidance building on 
the discussion in section 10 of RFC7766. 

- It might also be helpful to summarise the relevant current standards related 
to TCP features and their operational importance. This would be a basis for DNS 
operators to select implementations based on which combination of those 
features are available, since implementations are still evolving in terms of 
their TCP capabilities. 

Regards

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-00.txt

[Sara Dickinson]

Hi All, 

This update is just a name change (due to adoption) and the addition of several 
‘TODOs’ based on the comments so far. 

Regards

Sara. 

> On 6 Dec 2016, at 15:26, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>      Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-00.txt
>   Pages   : 38
>   Date: 2016-12-06
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport meta data.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] CBOR-DNS compression is 30% the size of gzip compressed PCAP

[Sara Dickinson]

> On 15 Nov 2016, at 14:59, George Michaelson  wrote:
> 
> Terry clarified, the 30% size compression is not from uncompressed,
> but is the comparision with compressed gzip pcap.
> 
> So, compressed DNS-CBOR is *significantly* smaller than pcap.gz

Yup - sorry if I wasn’t clear in the presentation. With a general purpose 
compression tool like xz:

- Compressed C-DNS is around 30% the size of the compressed PCAP.

-  It requires around an order of magnitude less CPU to compress the C-DNS file.

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

Re: [DNSOP] New Version Notification for draft-dickinson-dnsop-dns-capture-format-00.txt

[Sara Dickinson]

> On 1 Nov 2016, at 08:12, Jerry Lundström <je...@dns-oarc.net> wrote:
> 
> Hi Sara,
> 
> On 10/31/16 18:22, Sara Dickinson wrote:
>> https://github.com/dns-stats/draft-dns-capture-format 
>> <https://github.com/dns-stats/draft-dns-capture-format>

Hi Jerry, 

Thanks for the comments and the detailed review. 

> 
> An overall question, did you consider a CBOR extension tag (which does
> not require a RFC)?

Good question - not really at this stage but it something that could be 
considered (particularly if this draft moves towards adoption). 

My understanding of tags is that they are a useful convenience for labelling 
data items but not a necessity. 

> 
> The "file type id" content is not specified but in the CDDL it says
> "DNS-STAT", if any should it not be "C-DNS” ?

Yes, good spot :-)  Agreed it should be C-DNS if anything. 

> 
> "format version" exists but there is no indication which format this is.

Implicitly version 0, but will make this explicit in the next version. 

> 
> Description of "Block statistics" is missing.

Yup - will also add in next version. Here is a quick summary

total-packets   - Total packets received in the stream
total-pairs- Total number of matched DNS Q/R pairs 
written to the C-DNS file
unmatched_queries- Unmatched DNS queries  written to the C-DNS file
unmatched_responses   - Unmatched DNS queries  written to the C-DNS file
malformed-packets - Malformed DNS packets
non-dns-packets - Non-DNS packets in the packet stream
out-of-order-packets   - Number of packets delivered out of order from the 
capture library
missing-pairs  - Number or matched DNS Q/R pairs collected, but 
not written to C-DNS file
missing-packets - Number or received packets in the stream not 
written as PCAP
missing-non-dns - Number or malformed/non-DNS packets in the stream 
not written as PCAP

out-of-order-packets - this is a count of the number of times that a packet is 
received from the capture library where the timestamp on the packet is less 
than the timestamp on the previously received packet. There is a world of 
intrigue here when you go digging into the details of how/why this can happen….

The last 3 are somewhat application specific (all are optional). They are so 
that a collecting application can signal issues with overload where it was not 
able to output all the packets received in the the stream during the collection 
window for some reason. Such a collecting application could, for example, write 
out the malformed/non-DNS packets in PCAP format for later processing in 
parallel to writing the C-DNS data. 


> 
> "Timestamp" in "Block preamble map" is limited to microseconds, maybe
> add that each element within the array after the first is a /million to
> also allow nano/pico?

That seems reasonable, if it can be done in a flexible way where the additional 
resolution is only written when needed (i.e when not 0) so as to not increase 
file size unnecessarily. 

> 
> Same goes for "time-useconds" and "delay-useconds", maybe allow them to
> have a mixed type to either specify microseconds or a "Timestamp" offset
> (as array with [seconds,micro,pico...]).
> 
> About malformed and other data in the stream, would it not be possible
> to add optional "unrecognized-data" byte string to the appropriate
> objects and let the implementation decide?  This could also include padding.

We do want to come up with some mechanism to represent the malformed DNS 
packets where possible. That is one option to look at. 

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

[DNSOP] Fwd: New Version Notification for draft-dickinson-dnsop-dns-capture-format-00.txt

[Sara Dickinson]

Hi All, 

We have just published a new draft on a proposed format for DNS packet capture 
- please see below for details. We would very much appreciate feedback on the 
overall problem discussed here in addition to the details of the format 
proposed. 

Please note: There are three diagrams in this draft that have been included in 
the git repository at: 

https://github.com/dns-stats/draft-dns-capture-format 
<https://github.com/dns-stats/draft-dns-capture-format>

as .svg and .png files and referenced using URLs from within the text. The .png 
files are there because they look better when viewed directly on the GitHub 
website. We are very hopeful the new RFC format will arrive in time so that we 
never have to do these in ascii art :-) However if anyone objects strongly to 
this approach (for the initial review phase at least) then please let us know….

Also, to make the list aware, there is running code that implements this format 
to capture DNS traffic data and also convert it back to PCAP files that will be 
released Open Source in the near future. We will be in Seoul and are happy to 
discuss this in more detail there. 

Regards

Sara. 


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-dickinson-dnsop-dns-capture-format-00.txt
> Date: 31 October 2016 at 18:09:23 GMT
> To: "John Dickinson" <j...@sinodun.com>, "John Bond" <john.b...@icann.org>, 
> "Sara Dickinson" <s...@sinodun.com>, "Jim Hague" <j...@sinodun.com>, "Terry 
> Manderson" <terry.mander...@icann.org>
> 
> 
> A new version of I-D, draft-dickinson-dnsop-dns-capture-format-00.txt
> has been successfully submitted by Sara Dickinson and posted to the
> IETF repository.
> 
> Name: draft-dickinson-dnsop-dns-capture-format
> Revision: 00
> Title:C-DNS: A DNS Packet Capture Format
> Document date:2016-10-31
> Group:Individual Submission
> Pages:37
> URL:
> https://www.ietf.org/internet-drafts/draft-dickinson-dnsop-dns-capture-format-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-dickinson-dnsop-dns-capture-format/
> Htmlized:   
> https://tools.ietf.org/html/draft-dickinson-dnsop-dns-capture-format-00
> 
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage of large
>   packet captures of DNS traffic; it attempts to minimize the size of
>   such packet capture files but retain the full DNS message contents
>   along with the most useful transport meta data.  It is intended to
>   assist with the development of DNS traffic monitoring applications
>   and provide a more efficient data exchange format than alternatives
>   such as PCAP files.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

Re: [DNSOP] Possible issues with DNS over HTTP wire format draft

[Sara Dickinson]

> On 8 Aug 2016, at 14:41, Shane Kerr  wrote:
> 
> Hello,
> 
> As for a requirement for TLS... the document currently says that
> implementers SHOULD use TLS. My own feeling is that this should be
> enough; apparently the recommendation to require TLS was made in the
> HTTP/2 working group and rejected, so I am not sure that we need to
> re-visit the entire discussion around the DNS over HTTP protocol.
> 
> https://http2.github.io/faq/#does-http2-require-encryption
> 
> Note that I do not have a strong preference here. This is a working
> group document, so if there is consensus for requiring TLS then that's
> how it is.
> 
> 
> A final oversight that occurred to me is that there should be a privacy
> section. This is because since the DNS over HTTP serves as a DNS
> resolver that all of the privacy considerations of a normal DNS
> resolver apply, and should be mentioned (probably referencing RFC 7626).


I agree with this because one thing that hasn’t ever been clear to me with this 
mechanism is what the privacy expectations of the user should be. As I read the 
current draft a client should treat this from a privacy perspective with the 
same expectation as sending queries over UDP and TCP? I don’t think there is 
any intention to couple this to the Usage Profiles of Strict vs Opportunistic 
Privacy as described for DNS-over-(D)TLS, and no intention to re-use the 
authentication mechanisms described in draft-ietf-dprive-dtls-and-tls-profiles 
in Scenario 1? And the fact that TLS may be used is a separate consideration to 
any desire to explicitly provide privacy for the DNS client?

In some ways this feels like a missed opportunity for Scenario 1 but I 
appreciate wanting to limit the scope of this.

My main comment is that if my understanding is correct then I think the the 
distinction between encryption/authentication in the HTTP layer for the 
purposes of 'tunnelling’  and encrypting communication to provide privacy for 
the DNS client should be more clearly spelled out in the proposed Privacy 
section.

Sara.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-06.txt

[Sara Dickinson]

> On 22 Feb 2016, at 23:24, Mark Andrews  wrote:
> 
> 
> Strictly speaking the additional section can have anything the
> server feels is relevent including a OPT record (this in RFC 1034).
> Clients are expected to cope with anything added to the additional
> section.
> 
>   6. Using local data only, attempt to add other RRs which may be
>  useful to the additional section of the query.  Exit.
> 
> That said it is pointless to add a OPT record unless you know the
> client understands OPT.  Using a extended rcode would also be
> problematic as they require that the client understand OPT records
> which can't be determined unless you have see a OPT in the request.
> 
> Unknown EDNS options are expected to be ignored in both requests
> and replies so it is safe to add a unknown EDNS option to either.
> 
> This actually means you can add this option to any response but I
> would limit it to responses where there was a OPT record in the
> request.


Just to clarify, the draft already specifies that restriction, based on this 
text from RFC6891 (https://tools.ietf.org/html/rfc6891#section-7 
) :

  “Lack of presence of an OPT record in a request MUST be taken as an
   indication that the requestor does not implement any part of this
   specification and that the responder MUST NOT include an OPT record
   in its response.“

Sara.



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-06.txt

[Sara Dickinson]

> On 22 Feb 2016, at 18:41, Bob Harold  wrote:
> 
> I am not understanding one thing.
> 
>  3.3.2.  Sending Responses
> 
> Says that a server "that receives a query ... without the edns-tcp-keepalive 
> option ... MAY include the edns-tcp-keepalive option in the response"
> 
> But
> 
> 3.4.  TCP Session Management
> 
> Indicates that a server can only send the edns-tcp-keepalive option in an 
> answer if the client includes it in the request.


It is subtle, but is the difference between an EDNS0 OPT RR and a specific 
EDNS0 option:

- yes, the server can only send an EDNS0 OPT RR if the client includes one in 
the request but…
- as long as there was an EDNS0 OPT RR in the request, the server can send back 
the edns-tcp-keepalive option even there wasn’t one in the OPT RR in the 
request. 

Sara. 

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

Re: [DNSOP] draft-ietf-dnsop-edns-tcp-keepalive-05

[Sara Dickinson]

> On 26 Jan 2016, at 07:53, joel jaeggli  wrote:
> 
>> 
>> For DNS-over-DTLS-over-UDP, we should not need to negotiate the
>> client or server capability to send multiple DNS queries over the
>> same DTLS connection; the mere act of negotiating DTLS indicates the
>> ability to handle subsequent DNS queries using that same DTLS
>> connection.  The same might also be true of DNS-over-TLS-over-TCP, in
>> fact?  I mean, is there a client or a server that wants to use
>> DNS-over-TLS-over-TCP and _not_ also have the ability to keep their
>> TCP connection alive for later DNS queries over that same TLS
>> connection?  Perhaps for both DNS-over-TLS, and DNS-over-DTLS, the
>> semantics of edns-tcp-keepalive are implied?
> 
> that is an interesting reading. though I'd want to hear an implementor
> or two say they interpreted it that way.

The DNS-over-TLS draft 
(https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-05) discusses this 
explicitly in section 3.4:

“Whereas client and server implementations from the [RFC1035 
] era are
   known to have poor TCP connection management, this document
   stipulates that successful negotiation of TLS indicates the
   willingness of both parties to keep idle DNS connections open,
   independent of timeouts or other recommendations for DNS-over-TCP
   without TLS.  In other words, software implementing this protocol is
   assumed to support idle, persistent connections and be prepared to
   manage multiple, potentially long-lived TCP connections."

And then informationally references edns-tcp-keepalive and a mechanism that may 
be useful in signalling idle timeouts for long-lived TCP connections.

Sara.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-06.txt

[Sara Dickinson]

Hi All, 

This update addresses the comments from the IESG reviews:

- Introduction: Add reference to DNS-over-TLS
- Section 5: 's/it/the resolver/' and 's/fallback/retry/'
- Section 6.1.1: Make clear behaviour is 'at the time of writing', not a 
recommendation
- Section 6.2.1.1: Change SHOULD to MUST.
- Section 6.2.2: Clarify 'operational reasons' for zone transfers.
- Section 8: Re-word to remove reference to TCP segments.
- Section 9: Add sentence about use of TFO with DNS privacy solutions.

Regards

Sara. 


> On 15 Jan 2016, at 15:09, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
> 
>Title   : DNS Transport over TCP - Implementation Requirements
>Authors : John Dickinson
>      Sara Dickinson
>  Ray Bellis
>  Allison Mankin
>  Duane Wessels
>   Filename: draft-ietf-dnsop-5966bis-06.txt
>   Pages   : 21
>   Date: 2016-01-15
> 
> Abstract:
>   This document specifies the requirement for support of TCP as a
>   transport protocol for DNS implementations and provides guidelines
>   towards DNS-over-TCP performance on par with that of DNS-over-UDP.
>   This document obsoletes RFC5966 and therefore updates RFC1035 and
>   RFC1123.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-5966bis-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-5966bis-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

Re: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-edns-tcp-keepalive-04: (with COMMENT)

[Sara Dickinson]

> On 6 Jan 2016, at 07:57, Barry Leiba  wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-dnsop-edns-tcp-keepalive-04: No Objection
> 
> --
> COMMENT:
> --
> 
> -- Section 1 --
> 
>   Long-lived
>   TCP connections can result in lower request latency than the case
>   where UDP transport is used and truncated responses are received,
>   since clients that have fallen back to TCP transport in response to a
>   truncated response typically only uses the TCP session for a single
>   (request, response) pair, continuing with UDP transport for
>   subsequent queries.
> 
> This is a really long, awkward sentence, and it appears to have an error
> 
> in it that makes it unparseable.  

Point taken. I have re-worded it to make it clearer. 

>  But the use
> in 
> the abstract and at the top of page 4 are not.  I suggest "clients 
> commonly use TCP only for retries" in the abstract, and "received over
> UDP 
> with retries over TCP" on page 4.
> 

Yes, I think this is clearer. I have updated as suggested. 

Changes are in the -05 version published this morning. 

Regards

Sara. 

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

Re: [DNSOP] Martin Stiemerling's Yes on draft-ietf-dnsop-5966bis-05: (with COMMENT)

[Sara Dickinson]

> On 5 Jan 2016, at 22:11, Martin Stiemerling  wrote:
> 
> --
> COMMENT:
> --
> 
> One comment and request for clarification:
> 
> In the first paragraph of Section 8:
> "   DNS clients and servers SHOULD pass the two-octet length field, and
>   the message described by that length field, to the TCP layer at the
>   same time (e.g., in a single "write" system call) to make it more
>   likely that all the data will be transmitted in a single TCP segment.
>   This is both for reasons of efficiency and to avoid problems due to
>   some DNS server implementations behaving undesirably when processing
>   TCP segments (due to a lack of clarity in previous standards).  For
>   example, some DNS server implementations might abort a TCP session if
>   the first TCP segment does not contain both the length field and the
>   entire message.
> "
> 
> This paragraphs says that DNS servers process segments. This is slightly
> inaccurate, at least under the assumption that DNS clients and servers
> are user land processes. 
> Such a user land process does not see segments but data being read or
> written to the sockets. And such data might be one or multiple segments
> concatenated. 
> 
> I do understand the text, but I would like to propose a change (though
> the proposed text might not be perfect):
> 
>   This is both for reasons of efficiency and to avoid problems due to
>   some DNS server implementations behaving undesirably when reading
>   data from TCP  (due to a lack of clarity in previous standards).  For
>   example, some DNS server implementations might abort a TCP session if
>   the first data part read from TCP does not contain both the length
> field and the
>   entire message.

Yes, this is better. To be consistent with the rest of the wording in that 
section, I would propose minor tweaks:

 “This is both for reasons of efficiency and to avoid problems due to
  some DNS server implementations behaving undesirably when reading
  data from the TCP layer (due to a lack of clarity in previous standards).  For
  example, some DNS server implementations might abort a TCP session if
  the first “read" from the TCP layer does not contain both the length
  field and the entire message."

WDYT?

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

Re: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-5966bis-05: (with COMMENT)

[Sara Dickinson]

> On 6 Jan 2016, at 08:21, Barry Leiba  wrote:
> 
> -- Section 5 --
> 
>   This requirement is hereby relaxed.  Stub resolvers and recursive
>   resolvers MAY elect to send either TCP or UDP queries depending on
>   local operational reasons.  TCP MAY be used before sending any UDP
>   queries.  If it already has an open TCP connection to the server it
>   SHOULD reuse this connection.  In essence, TCP ought to be considered
>   a valid alternative transport to UDP, not purely a fallback option.
> 
> The "If it already has" in the fourth sentence was clear in the original
> 
> 5966 text, but doesn't work here: there's no clear antecedent to "it".  
> Please make it "If the resolver already has”.

Ack.

> 
> In the last sentence, I think we should say "not purely a retry option,"
> 
> as this isn't really "fallback" in the sense we usually use the term.

OK.

> 
> -- Section 6.1.1 --
> 
>   However it
>   is common practice for clients to close the TCP connection after
>   sending a single request
> 
> In the light of edns-tcp-keepalive, do we really want to say this?  It's
> 
> true, but it sounds like a recommendation.  Maybe we might say something
> 
> like, "Clients often close the TCP connection after sending a single 
> request, but see [draft-ietf-dnsop-edns-tcp-keepalive]." ?

Well, this ‘Current Practices” section was trying to document what happens 
today, and to my knowledge keepalive isn’t implemented in any production 
software yet. We do reference the keepalive draft in the ‘Recommendations: Idle 
Timeouts” section though.

Perhaps we could change this to “However, at the time of writing it is common 
practice...” ?

Sara. 

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

Re: [DNSOP] Martin Stiemerling's No Objection on draft-ietf-dnsop-edns-tcp-keepalive-04: (with COMMENT)

[Sara Dickinson]

> On 5 Jan 2016, at 22:29, Martin Stiemerling  wrote:
> 
> 
> Two comments for your considerations:
> 
> 1) Section 3.3.2 is talking about this "It is reasonable for this value
> to change [...] or in consideration of  intermediary behaviour (for
> example TCP middleboxes or NATs)."
> Can you please clarify how the DNS client or server is able to inspect
> the behaviour of intermediated devices and adapt its behaviour
> accordingly? This smells a bit like a half-baked idea which does not
> belong into a standards track document. 

I've checked with the other authors and we are fine with removing the statement 
about intermediary behaviour.

> 
> 2) Section 3.6. talks about using Multipath TCP. Please note that
> Multipath TCP is still experimental and has known security issues, which
> are dealt with right now. Further, I would recommend to move this to a
> non-normative appendix, noting that this is a potential future way
> forward, but that is has not yet been tested and deployed. This would
> also honor that RFC 6824 is listed in the informative part of the
> references.

This was picked up in an earlier review and in the -05 version the last 
sentence was reworded to be more suitable for an experimental RFC reference:

“It might be possible for
   anycast servers to avoid disruption due to topology changes by making
   use of TCP multipath [RFC6824] to anchor the server side of the TCP
   connection to an unambiguously-unicast address.”

Does this address your concerns sufficiently?

Regards

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

Re: [DNSOP] Gen-ART telechat review of draft-ietf-dnsop-edns-tcp-keepalive-04

[Sara Dickinson]

> On 4 Jan 2016, at 18:32, Brian E Carpenter  
> wrote:
> 
> On 04/01/2016 22:38, sara wrote:
>> 
>>> On 31 Dec 2015, at 22:11, Brian E Carpenter  
>>> wrote:
>>> 
>>> Still "Ready with issues" pending a new version.
>> 
>> Hi Brian, 
>> 
>> There are a couple of minor issues still to resolve from Jon Mitchell’s 
>> review. I can put a new version out on the Wed 6th regardless if that is 
>> helpful?
> 
> I would check with your AD. There have been times when the IESG got confused
> by new versions just before the telechat.
> 
>Brian

Hi Joel, 

I would like to publish an updated version of the 
draft-ietf-dnsop-edns-tcp-keepalive draft (which is scheduled for discussion in 
the Gen-ART tele chat on 7th) with a number of updates from both the Gen-ART 
and OPS-DIR review. There are a couple of minor issues outstanding but I think 
many of the updates are very useful. Any objection to publishing at this time - 
is it likely to confuse as Brian pointed out? 

Regards

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

Re: [DNSOP] Brian Haberman's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-04: (with DISCUSS)

[Sara Dickinson]

> On 4 Jan 2016, at 18:18, Brian Haberman  wrote:
> 
> --
> DISCUSS:
> --
> 
> I support the publication of this document, but I have a point I want to
> discuss to help with the clarity of the spec.
> 
> Section 3.2.1 says that clients send this option with the first query
> sent on a TCP connection and Section 3.2.2 says it should honor the
> timeout provided by the server and close the socket when appropriate.
> What is not discussed is how the client should manage the timer with
> respect to the reception of multiple query responses that may, or may
> not, include edns-tcp-keepalive option. Section 3.3.2 says the server MAY
> send the option, so it is up to the server to decide when to include the
> option and the corresponding timeout value. Should the client's timer
> simply reflect the value sent in the latest response? The smallest
> remaining time?
> 
> I think a few sentences on client timer management would be beneficial.

Hi, 

Thanks for the feedback. The intention in section 3.2.2 was that the client 
should update the timeout whenever receiving a new value in any response. Would 
it be enough to clarify by changing the last sentence in the second paragraph 
to:

  “It SHOULD honour the timeout received in that response (overriding any 
previous timeout) and
   initiate close of the connection before the timeout expires.”

Regards

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

Re: [DNSOP] OPS-DIR review of draft-ietf-dnsop-edns-tcp-keepalive-04

[Sara Dickinson]

> On 23 Dec 2015, at 13:30, Sara Dickinson <s...@sinodun.com> wrote:
>> 
>> [JM] Sorry, this is my fault on the confusion on the previous two
>> comments - I was actually still confused by section 3.2.1 (not 3.3.2)
>> paragraph 3, why a DNS client would first signal they support the EDNS
>> keepalive then later stop signaling that on the same connection rather
>> than just resetting the connection at some point.  This seems like odd
>> behavior by a client.
> 
> I think I understand the confusion now. 
> 
> One key problem this option is trying to solve is that most DNS servers today 
> have very poor TCP connection management and if clients simply started 
> keeping connections open they could exhaust the server resources easily. So 
> the keepalive exchange on the first query allows both parties to know that 
> the other end does support keepalive and so keeping the connection open is 
> OK. The design here is meant to be as lightweight as possible to achieve that 
> goal, and in fact earlier versions simply had the exchange of keepalive 
> options on the first query and not at all on subsequent ones. 
> 
> So, the lack of keepalive in subsequent queries isn’t a signal that the 
> client doesn’t support keepalive, or doesn’t want to keep the connection 
> open, it just isn’t required. 
> 
> The reason an option was added to allow clients to send the keepalive option 
> in a later query on the same connection so the client can check if the server 
> has changed (or is willing to change) the timeout it has associated with the 
> session.  Because of the semantics of EDNS0, DNS servers cannot send a 
> keepalive option with an updated timeout in a response unless the client 
> sends an EDNS0 option in the query. But we didn’t want the overhead of adding 
> the option to every message on the connection to achieve that. Hence the 
> discussion in section 3.4 about clients periodically resending the option. 


Just chasing off-list ahead of the IESG tele chat on Thursday :-)

Does this clarify the background enough?

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

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-5966bis-04.txt

[Sara Dickinson]

Hi All, 

A new version of draft-ietf-dnsop-5966bis is available. It addresses the 
comments raised in WGLC:

* Re-stated how messages received over TCP should be mapped to queries.
* Added wording to cover timeouts for server side behaviour for when receiving 
TCP messages.
* Added a sentence to the abstract stating this document obsoletes RFC5966.
* Moved reference to RFC6891 earlier in Discussion section.
* Several minor wording updates to improve clarity.

Regards

Sara. 

> On 3 Nov 2015, at 14:33, internet-dra...@ietf.org wrote:
> 
> 
> A new version of I-D, draft-ietf-dnsop-5966bis-04.txt
> has been successfully submitted by Sara Dickinson and posted to the
> IETF repository.
> 
> Name: draft-ietf-dnsop-5966bis
> Revision: 04
> Title:DNS Transport over TCP - Implementation Requirements
> Document date:2015-11-03
> Group:dnsop
> Pages:19
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-5966bis-04.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-5966bis-04
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-5966bis-04
> 
> Abstract:
>   This document specifies the requirement for support of TCP as a
>   transport protocol for DNS implementations and provides guidelines
>   towards DNS-over-TCP performance on par with that of DNS-over-UDP.
>   This document obsoletes RFC5966.

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

[Sara Dickinson]

> On 15 Oct 2015, at 18:00, 神明達哉  wrote:
> 
> I see your point.  But whether the updated notification from the
> server works relies on whether the client includes an OPT RR in
> subsequent queries, ambiguity on the latter can easily lead to
> interoperability problem.  So I thought this should be at least
> clearly documented and RFC2119 keywords are helpful exactly in such a
> situation.

That’s reasonable and so I do think extra text helps here. 

> 
> ...I incorrectly thought the client needs to keep including the
> edns-tcp-keepalive option.  I'm not sure if we can reasonably assume
> clients generally include an EDNS OPT RR even if they have no other
> particular reason to do so than the issue we're discussing here.  
> If we can assume that, the text can be loosened.  But we probably cannot
> rely on the current implementation behavior on this topic, so I think
> it's safer to at least mention it explicitly in some way.
> 

I certainly agree that the EDNS0 spec is full of subtleties :-)

>> 
>> If a client includes the edns-tcp-keepalive option in the first query, it 
>> SHOULD include an EDNS0 OPT RR periodically
>> in any further messages it sends during the TCP session.
>> This will increase the chance of the client being notified should the server 
>> modify the timeout associated with a session.
> 
> I'm fine with this.  Also, if the use of 'SHOULD' really triggers
> controversy on whether to be more specific about "periodically", I'm
> fine with avoiding an RFC2119 keyword, too.

Fair enough - I’ll add the above text to the document and the wording can be 
downgraded if necessary!

Thanks for all the feedback.

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

[DNSOP] Fwd: Working Group Last Call on draft-ietf-dnsop-5966bis

[Sara Dickinson]

> Begin forwarded message:
> 
> From: 神明達哉 <jin...@wide.ad.jp>
> Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis
> Date: 15 October 2015 01:52:09 BST
> To: Sara Dickinson <s...@sinodun.com>
> Cc: Joe Abley <jab...@hopcount.ca>, dnsop <dnsop@ietf.org>
> 
> At Wed, 14 Oct 2015 13:20:39 +0100,
> Sara Dickinson <s...@sinodun.com> wrote:
> 
> 
> I think the additional text for these sections has the same problem I
> pointed out before for the sending side of Section 8: a DNS server
> implementation usually cannot know which TCP segment contains what
> amount of data.  All it can know in practice is which amount of data a
> single "read" API call returns.  I suggest you rephrasing the text as
> we did for the sending side of Section 8.@@ -477,6 +477,12 @@

Point taken! How about the following:

@@ -477,6 +477,12 @@
   specified in [RFC1035].  Servers MAY use zero timeouts when
   experiencing heavy load or are under attack.

+   DNS messages delivered over TCP might arrive in multiple segments.  As
+   a result a DNS server that resets its idle timeout after each “read” system 
call
+   might be vulnerable to a "slow read attack."  For this
+   reason, servers SHOULD apply the idle timeout to the receipt of a
+   full DNS message, rather than to receipt of any part of a DNS message.
+

@@ -542,7 +549,18 @@
   problems due to some DNS servers being very sensitive to timeout
   conditions on receiving messages (they might abort a TCP session if
   the first TCP segment does not contain both the length field and the
-   entire message)
+   entire message).  Such behavior is certainly undesirable.  As
+   described in [6.2.3], servers SHOULD apply idle timeouts to the
+   receipt of a full message and MUST NOT close a connection simply
+   because the first “read” system call for a new message does 
+   not contain the entire message.

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

[Sara Dickinson]

> On 7 Oct 2015, at 18:17, 神明達哉  wrote:
> 
> 
> I've read the 03 version of draft.  It's very well written and I've
> not found any critical technical issues.  So I basically think it's
> ready to ship.
> 

Hi,

Many thanks for the review.

> I have a couple of minor comments, which the authors might want to
> address/discuss before advancing the draft:
> 
> 1. Section 3.2.1
> 
>   DNS clients MAY include the edns-tcp-keepalive option in the first
>   query sent to a server using TCP transport to signal their desire to
>   keep the connection open when idle.
> 
>  I wonder whether we want to explicitly say something about including
>  the edns-tcp-keepalive option in subsequent queries on the same TCP
>  connection.  
>  So it may be better to explicitly say, e.g., that clients MAY
>  include the option in subsequent queries

Yes, this will definately improve the document. The following has been added to 
Section 3.2.1:

DNS clients MAY include the edns-tcp-keepalive option in the first
query sent to a server using TCP transport to signal their desire to
keep the connection open when idle.
 
+   DNS clients MAY include the edns-tcp-keepalive option in subsequent
+   queries sent to a server using TCP transport to signal their
+   continued desire to keep the connection open when idle.

>  We might even want to use
>  a stronger requirement like "the client SHOULD occasionally include
>  the option in subsequent queries if it includes the option in the
>  first query”.

I’m not sure how prescriptive the document should be on this...

Would adding the following paragraph to Section 3.4 on TCP session management 
address you concerns?

attractive than a mechanism that establishes default persistence and
then uses a connection close signal (in a similar manner to HTTP 1.1
[RFC7320]).
 
+   Clients might choose to send the edns-tcp-keepalive option regularly
+   during a TCP session to increase the chance of being notified should
+   the server modify the timeout associated with a session.  The
+   algorithm for choosing when to do this is out of scope of this
+   document and is left up to the implementor and/or operator.


> 
> 2. Section 3.2.2
> 
>   A DNS client that receives a response that includes the edns-tcp-
>   keepalive option with a TIMEOUT value of 0 should send no more
>   queries on that connection and initiate closing the connection as
>   soon as it has received all outstanding responses.
> 
>  I wonder whether this 'should' may better be 'SHOULD’.  

Good catch, this is now a SHOULD. 

> 
> And, one minor editorial nit: In Section 5
> 
>   [...]  When a Nameserver
>   detects abusive behaviour, it SHOULD immediately close the TCP
>   connection and free the resources used.
> 
>  Perhaps s/Nameserver/nameserver/?  Or, it might even be "DNS server"
>  ('[Nn]ameserver' or 'name server' doesn't seem to be used anywhere
>  else in the document).

This is now 'DNS server’ which is consistent with the rest of the document. 

Regards

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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis

[Sara Dickinson]

> On 12 Oct 2015, at 11:57, Tony Finch  wrote:
> 
> Tim Wicinski  wrote:
>> 
>> This starts a Working Group Last Call for draft-ietf-dnsop-5966bis
> 
> I have re-read the draft and it looks good to me.

Thanks.

> 
> A couple of suggestions for section 7:
> 
>   For the avoidance of future doubt, this requirement is clarified.
>   Authoritative servers and recursive resolvers are RECOMMENDED to
>   support the sending of responses in parallel and/or out-of-order,
>   regardless of the transport protocol in use.
> 
> I suggest deleting "in parallel and/or" since sending parallel responses
> on a TCP query doesn't make sense, and even UDP responses have to be
> serialized at some level. Perhaps change the clause to "preparing
> responses in parallel and sending them out-of-order”.

Text updated - thanks.

Sara. 

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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis

[Sara Dickinson]

> On 9 Oct 2015, at 20:53, Joe Abley  wrote:

Joe, 

Thanks for the review. 

>  I made a few notes as I read through, but it would be entirely fine with me 
> if they were all ignored.

All your suggested rewordings improve the document and have been committed - 
thanks.

> 
> Section 8: is there benefit perhaps in including a matching SHOULD for the 
> desired server behaviour? The paragraph notes that servers may respond in an 
> unhelpful way if the message length and the message itself don't arrive in 
> the same segment, but doesn't specify in a normative way what we think of 
> that. Perhaps they SHOULD NOT do that?


That seems reasonable. Would the following additions (which go a little 
further) clarify this point enough?

Section 6.2.3  Idle Timeouts

@@ -477,6 +477,12 @@
specified in [RFC1035].  Servers MAY use zero timeouts when
experiencing heavy load or are under attack.
 
+   DNS messages delivered over TCP might arrive in multiple segments.  A
+   DNS server that resets its idle timeout after receiving a single
+   segment might be vulnerable to a "slow read attack."  For this
+   reason, servers SHOULD apply the idle timeout to the receipt of a
+   full DNS message, rather than to receipt of a TCP segment.
+


Section 8   TCP Message Field Lengths

@@ -542,7 +549,18 @@
problems due to some DNS servers being very sensitive to timeout
conditions on receiving messages (they might abort a TCP session if
the first TCP segment does not contain both the length field and the
-   entire message)
+   entire message).  Such behavior is certainly undesirable.  As
+   described in [6.2.3], servers SHOULD apply connection timeouts to the
+   receipt of a full message and MUST NOT close a connection simply
+   because the first segment does not contain the entire message.

Sara. 

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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis

[Sara Dickinson]

> On 12 Oct 2015, at 13:36, Stephane Bortzmeyer  wrote:
> 
> On Mon, Oct 12, 2015 at 01:09:38PM +0100,
> sara  wrote 
> a message of 107 lines which said:
> 
>> So under normal circumstances matching on just the Message ID should
>> be sufficient for TCP, which was the reason the QCLASS+QNAME+QTYPE
>> part was removed when changing the ‘must' here to ‘MUST' in the last
>> revision of this draft.
> 
> OK, but why adding the port number, useless for TCP?

It was meant to restrict the matching to messages on a single TCP connection, 
but it clearly just caused confusion. I think Tony’s suggested text works well. 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-03.txt

[Sara Dickinson]

Hi all, 

An -03 update to the 5966bis draft is now available: draft-ietf-dnsop-5966bis-03

This addresses the comments received since the -02 update:

* Replaced certain lower case RFC2119 keywords to improve clarity.
* Updated section 6.2.2 to recognise requirements for concurrent zone transfers.
* Changed 'client IP address' to 'client IP address or subnet' when discussing 
restrictions on TCP connections from clients.
* Added reference to edns-tcp-keepalive draft.
* Added wording to introduction to reference Appendix A and state TCP is a 
valid transport alternative for DNS.
* Improved description of CPNI-TCP as a general reference source on TCP 
security related RFCs.

We feel this document is now ready to progress and would like to request a 
Working Group Last Call on this version of the draft. 

Regards

Sara. 


> On 20 Sep 2015, at 13:59, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
> 
>Title   : DNS Transport over TCP - Implementation Requirements
>Authors : John Dickinson
>      Sara Dickinson
>  Ray Bellis
>  Allison Mankin
>  Duane Wessels
>   Filename: draft-ietf-dnsop-5966bis-03.txt
>   Pages   : 18
>   Date: 2015-09-20
> 
> Abstract:
>   This document specifies the requirement for support of TCP as a
>   transport protocol for DNS implementations and provides guidelines
>   towards DNS-over-TCP performance on par with that of DNS-over-UDP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-5966bis-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-5966bis-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-02.txt

[Sara Dickinson]

 On 3 Aug 2015, at 22:14, Wessels, Duane dwess...@verisign.com wrote:
 
 
 I offered to review this document during the WG meeting in Prague…

Hi Duane, 

Many thanks for the detailed review. They are all useful comments that will be 
added to the document.

 
 
 3.1.  Option Format
 
   The edns-tcp-keepalive option is encoded as follows:
 
1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---+---+
   ! OPTION-CODE   ! OPTION-LENGTH !
   +---+---+
   |TIMEOUT|
   +---+
 
   where:
 
   OPTION-CODE:   the EDNS0 option code assigned to edns-tcp-keepalive,
  [TBD]
 
   OPTION-LENGTH:   the value 0 if the TIMEOUT is omitted, the value 2
  if it is present;
 
 
   TIMEOUT:   an idle timeout value for the TCP connection, specified in
  units of 100 milliseconds, encoded in network byte order.
 
 
 The diagram above indicates TIMEOUT is a 32-bit value, which would make
 OPTION-LENGTH 4.
 
 I suspect it was really intended as a 16-bit value (OPTION-LENGTH 2), which
 means the max TIMEOUT is around 109 minutes?
 


Well spotted. The diagram is incorrect - the timeout is intended to be a 16-bit 
value as you describe. 

Regards

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

[DNSOP] Review of draft-wing-dprive-dnsodtls-01

[Sara Dickinson]

Hi, 

Here are some comments on the draft-wing-dprive-dnsodtls-01 draft (some of 
which echo comments at the mic from the recent working group meeting).


General comments:
---

1) My major comment is that I don’t think the current draft tackles the problem 
of truncation of answers in enough depth. DNS-over-DTLS, like UDP, will have to 
truncate answers if they exceed the pMTU. And since the packet includes the 
DTLS header the likelihood of truncation is increased for DNS-over-DTLS 
compared to UDP.  In the case of truncation one of two things must happen:
  i) Fallback to e.g. TLS (if available) which compromises performance compared 
to using a single protocol for privacy.
  ii) Fallback to unencrypted communication, which compromises privacy.

There is a brief discussion of a proposed shim layer to avoid this, but without 
a solution to this issue that eliminates the need for fallback I don’t believe 
the protocol can be deployed as a standalone solution for DNS privacy (it would 
have to deployed alongside e.g. TLS). Because of this limitation I think much 
more weight should be given to this issue and the feasibility of potential 
solutions.

2) I also think a fuller discussion of the difference between the initial TLS 
and DTLS handshake should be included since in the DTLS case an extra RTT is 
needed for the Hello Verification, without which the session resumption cannot 
occur in 1 round trip. Since DNS is a latency sensitive protocol this should be 
spelled out in order to ensure implementors fully understand this difference. 

3) Whilst I do not support using port 53 for DTLS as proposed in this document, 
I do think it may make sense to pursue DTLS on a different port should a new 
port be assigned as a result of the early port assignment request generated by 
draft-ietf-dprive-start-tls-for-dns-01 (as discussed in the WG meeting). 


Specific comments:
---

Terminology

- I wonder if a terminology section would be of use? For example, I see both 
the terms ‘DTLS session’ and  ‘DTLS security association’ used in the document 
and it would be helpful to clarify them (or just define one and use it 
consistently). 


Section 3.3: Downgrade attacks

- I think this section may benefit from adopting the language used in RFC7525 
e.g discussing strict vs opportunistic encryption. 

- I think it would help if the second sentence of the first paragraph could be 
re-written to either make clear that the behaviour is an implementation choice 
(e.g. use ‘might choose’ instead of ‘will’) or clarify is it part of the 
specification (e.g. use SHOULD/MAY instead of ‘will')?


Section 7: Performance Considerations

- (nit) Second paragraph s/QueryID/Query ID/ 

- From an implementation point of view I think DTLS probably has more 
characteristics in common with TCP/TLS than UDP, so detailing behaviours like 
connection re-use, query pipelining, idle-time, out-of-order responses (or 
their DTLS equivalents) will be of value.  For example:

-  I’d like to suggest the second paragraph includes some text similar to that 
in draft-ietf-dnsop-5966bis-02 which addresses message ID collisions:
“ When sending multiple queries over a DTLS security association clients MUST 
take care to avoid Message ID collisions. In other words, they MUST not
   re-use the DNS Message ID of an in-flight query.”
- Similarly, I also think some text clarifying that clients should sent 
multiple queries on a given security association without waiting for responses 
wouldn’t go a miss. 
- Third paragraph. Did you consider adding a statement to the effect “Clients 
SHOULD re-use security associations.” Is there any reason not to add this?
- I think it would be helpful to add some discussion of the expected lifetime 
of the UDP security associations. Also, it is unclear to me what happens in a 
‘normal’ tear down of the security association.

- Fourth paragraph 
   — I think it would be helpful to clarify for implementors that the DNS 
server implementation must be capable of determining the encoded size of the 
message (not the clear text size) before it is sent in order to evaluate if the 
TC=1 bit must be set. 
— I think your argument about the use of pMTU to reduce the need to switch 
to TCP is that a client can use the pMTU in a server selection algorithm? 

- You make the recommendation that root servers should not implement this due 
to additional load. I disagree with the NOT RECOMMENDED here as I think it is 
too prescriptive. I agree with dkg’s earlier comments that the authoritative 
server resource discussion would be improved by being more general. 


Section 8: Established session

- I’d like to suggest moving this entire section earlier to improve the 
readability of the document, perhaps after section 4?

- Again, I think a stronger/clearer recommendation (SHOULD?) about re-using 
DTLS sessions would be helpful here too

Section 9:

- Perhaps this section is better replaced 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

[Sara Dickinson]

 On 20 Jul 2015, at 12:19, Petr Spacek pspa...@redhat.com wrote:
 
 The -02 version of the draft makes a lot of sense to me, here are only two 
 nits:

Many thanks for the review. 

 On 20 Jul 2015, at 12:19, Petr Spacek pspa...@redhat.com wrote:
 
 Section 5 says:
 
 ... TCP should be considered a valid alternative transport to
   UDP, not purely a fallback option..
 
 To me it seems as the very very core of the draft. Personally I would add this
 to Introduction and even to Abstract to make it super clear. Now it is kind of
 buried.

Thanks - good point. 

 
 
 6.1.  Current practices
 Explicit reference to edns-tcp-keepalive could be good so it is easier to read
 and follow, especially if edns-tcp-keepalive gets finalized.

Yes, the only reason it wasn’t there is that the 5966bis-02 was ready when the 
status of the edns-tcp-keepalive draft was still a bit up in the air. Now 
keepalive has moved forward it makes sense to add the reference. 

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Sara Dickinson]

 On 16 Jul 2015, at 03:15, Paul Hoffman paul.hoff...@vpnc.org 
 mailto:paul.hoff...@vpnc.org wrote:
 
 On 15 Jul 2015, at 17:33, Andrew Sullivan wrote:
 
 Just on this issue, and speaking only for myself (but as one of the
 people behind this document), my view is that this WG has historically
 been one of the places where documents go to die, and I am unwilling
 to go through the exercise of proving again how great an enemy of the
 good the perfect can be.  I'd be much more inclined to remove the
 contentious definitions and publish that document than to try to get
 things perfect.

Firstly to say that I think this is a very worthy effort and the document will 
be of great value to the DNS community.  It should be published and I support 
the proposal that removing contentious definitions to get the draft published 
is the a best way to proceed.

 
 I agree and acknowledge that there remain some definitions in there
 that are contentious.
 
 Not only do you agree and acknowledge that, *so does the document*. 

I have to disagree that the document goes that far - the first sentence of the 
third paragraph in the introduction states:

“The definitions here are believed to be the consensus definition of
   the DNS community, both protocol developers and operators.”

and paragraph 5 

“In this document, where the consensus definition is the same as the
   one in an RFC, that RFC is quoted.  Where the consensus definition
   has changed somewhat, the RFC is mentioned but the new stand-alone
   definition is given.

so I don’t believe any definitions that are considered contentious should be in 
the document if this wording is to be retained.

 Based on the contention and lack of consensus for some of the definitions, 
 the Introduction now says:
 
 During the development of this document, it became clear that some 
 DNS-related terms are interpreted quite differently by different DNS experts. 
 Further, some terms that are defined in early DNS RFCs now have definitions 
 that are generally agreed to that are different from the original 
 definitions. Therefore, the authors intend to follow this document with a 
 substantial revision in the not-distant future. That revision will probably 
 have more in-depth discussion of some terms as well as new terms; it will 
 also update some of the RFCs with new definitions.


Since this paragraph appears after the first statement about consensus I read 
it as indicating the bis is likely to refine and extend the original document 
(fine) but not that readers should expect some definitions presented here to 
substantially change in a later revision. 

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