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

[Richard Gibson]

Thank you so much for the changes, I am confident that this format is 
now in a state where my organization could build on top of it to suit 
our needs. I have a handful of remaining comments below, mostly 
describing ways in which that process could be made more straightforward 
and standardized.


* Section 6.2.1 and 7.5.3.4: At minimum, RR field "ttl" should be 
optional in order to accommodate aggregation of resolver responses in 
which that field is decremented over time. But probably "rdata-index" 
should be optional as well.


* Section 7.1: Negative integer map keys are concise, but they come with 
the potential for interoperability-hostile collisions. I think the 
document should encourage restricting their use to tightly-controlled 
closed systems, and then additionally propose a particular namespacing 
pattern (e.g., "{namespaceName}-{keyName}") for use of 
implementation-specific /string/ keys in other cases. Further, it should 
explicitly reserve positive integer keys for future standardized 
extensions to the C-DNS format.


* Section 7.4.1: Why is BlockParameters an array instead of a map?

* Section 7.4.1.1: StorageParameters fields "opcodes" and "rrtypes" 
could be defined better... are they values /recorded/ (i.e., that were 
actually observed) or values that are /recordable/ (i.e., that the 
collection application was looking for)? And shouldn't they be optional 
(in either case, but *especially* the latter, lest implementations write 
out every possible rrtype value).


* Section 7.5.3: It's very good that the BlockTables "ip-address" items 
can be truncated by prefix length, but we have actually run into cases 
that call for /variable/ truncation (i.e., more precision in some 
subnets than in others), especially true given that a single table holds 
both client and server address data. What would you think about 
representing addresses not as direct byte strings, but rather as 
variable-length arrays or maps—index 0 encoding the prefix as a byte 
string, and optional index 1 (when present) encoding a prefix-length 
override? Or, if the extra size per address is too much, at least 
allowing such representations via polymorphism (byte string for default 
prefix-length, array/map for non-default)?


* Section 7.5.3.2: QueryResponseSignature field "qr-transport-flags" 
seems to reserve 1 bit /each/ for UDP, TCP, TLS, and DTLS, but it seems 
to me that UDP is mutually exclusive with TCP and that TLS is mutually 
exclusive with DTLS. Couldn't that data be represented in two bits (one 
in which 0 ⇒ UDP and 1 ⇒ TCP, the other in which 0 ⇒ plain-text and 1 ⇒ 
TLS)?



On 02/22/2018 07:31 AM, Sara Dickinson wrote:

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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat_=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=S0pguE4aKgWT-7tOAVBInPr7s58myqhSmv9WtwMzeNA=522TfZMUJHLQox2FWFORwOQXhrlqwp36X9Ty1v54YeI=

There are also htmlized versions available at:

[DNSOP] dnsop - Requested sessions have been scheduled for IETF 101

["IETF Secretariat"]

Dear Tim Wicinski,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

dnsop Session 1 (2:00:00)
Tuesday, Afternoon Session II 1550-1820
Room Name: Sandringham size: 300
-
dnsop Session 2 (1:00:00)
Thursday, Afternoon Session III 1810-1910
Room Name: Sandringham size: 300
-



Request Information:


-
Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski

Number of Sessions: 2
Length of Session(s):  2 Hours, 1 Hour
Number of Attendees: 160
Conflicts to Avoid: 
 First Priority: dhc homenet dnssd dprive doh
 Second Priority: v6ops intarea trans acme
 Third Priority: 6man grow opsarea opsawg saag sidr


People who must be present:
  Suzanne Woolf
  Warren Kumari
  Tim Wicinski

Resources Requested:

Special Requests:
  If either session is slotted for Friday, please make it the second 1 hour 
session. thanks
-

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

Re: [DNSOP] Updated KSK Sentinel document

[Paul Hoffman]

On 12 Feb 2018, at 12:28, Warren Kumari wrote:


I also updated my demo implementation
(http://www.ksk-test.net) to use this naming scheme.


I would very much like to see draft-ietf-dnsop-kskroll-sentinel move 
forward, but was concerned that the result might be something where an 
end-user might not be able to reliably test the resolver they were using 
for it. Warren's Javascript code from that page uses the idea that an 
image that could not be loaded would have a height of zero:


  if (img_invalid.height === 0) {invalid = false;}
  if (img_is_ta.height === 0) {is_ta = false;}
  if (img_not_ta.height === 0) {not_ta = false;}

That seems to work for some browsers, but I worried that some browsers 
might implement something different for their Javascript. (This is not 
to knock Warren's code: he admitted it was a quick hack.)


After some investigation, I have a different method that should work in 
all browsers that follow the HTML and Javascript standards. It does not 
rely on any non-standard assumptions in the client-side Javascript.


In the  of an HTML document, first include something like this:
   var collected_names = [];
... to create a global variable that holds a list. Then include:
   src="http://kskroll-sentinel-is-ta-4f66.example.com/is-ta.js";>
   src="http://kskroll-sentinel-not-ta-4f66.example.com/not-ta.js";>

   http://invalid.example.com/invalid.js";>
The files that are attempted to be retrieved have one line of code, 
different for each file:

   collected_names.push("is_ta");
  or
   collected_names.push("not_ta");
  or
   collected_names.push("invalid");
The result is that the collected_names list now contains an entry for 
each of the domains where the .js file was fetchable. The Javascript (in 
yet another