Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[Robert Edmonds <[e-mail]>]

Tim Wicinski wrote:
> All
> 
> Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in 2014, and
> has had 10 revisions since then.
> 
> https://datatracker.ietf.org/doc/draft-dulaunoy-dnsop-passive-dns-cof/
> 
> Note that the format is now fixed, and there are several implementations.
> 
> We had asked DNSOP (in the poll we held)to help us assess the level of interest
> in it, and the responses  largely put it moderately high  ("Adopt, but not
> now"). It would be helpful to find out if this is still the case, as things
> have progressed since then: the format is now widely used, and so the format
> itself is basically fixed. As an example, the format is being used within the
> US government agencies for event logging and incident response[0].
> 
> 
> One of two things could happen:
> 
> 1: DNSOP decides that they are really interested, adopts and improves the
> justification / operational / supporting text, and the draft gets published as
> an IETF RFC; or
> 
> 
> 2: DNSOP says "No thanks, but we don't actively object". In which case the ISE
> (and Warren!) has a much easier time explaining why it's being published as an
> RFC on the Independent stream. . We will also ask for a DNS Directorate review.
> 
> 
> Feedback Welcome
> 
> tim
> 
> [0]: Because the draft had expired, and the USG cannot (realistically) point at
> expired IDs, they had to copy and paste it into an internal document: https://
> www.whitehouse.gov/wp-content/uploads/2021/08/
> M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf
>  Page 15 is the table where they defined the Passive DNS Log fields.

I originally developed one of the implementations named in this draft
[1] and if I recall correctly it did not occur to me that the API I was
developing should ever be standardized, let alone the underlying data
model being used to generate API responses, which I don't think this I-D
has ever touched on. E.g., the 'rdata' field may return a string or an
array of strings; if you have an array of length 1, does this mean a
resource record or a resource record set is being represented? Well, it
probably depends on which API endpoint on which implementation is being
called; but this spec is presented as a document format rather than as
specification for an entire API. I would guess there is substantially
more variation in the kinds of API endpoints that are supported by the
various passive DNS API implementations than there is in the output
formats generated by those endpoints which makes it less tractable to
come up with a consensus specification for the endpoints as well.

So, it seems a bit odd to me to try to put a particular narrowly scoped
idiosyncratic consensus format used by a few particular API services
through the RFC process. There are many kinds of databases, API
services, and formats that do not have RFC documents describing them.
For instance, the pcap savefile format is widely used and presumably a
lot of governments buy a lot of products that support the pcap format,
and as far as I can tell the canonical specification for that format is
a file in a particular Git repository [2] maintained by a group of open
source contributors. Why isn't that approach feasible for this
particular use case, which is much more of a niche use case than packet
capture in general?

[1] Some of the early API documentation is on the Wayback Machine:
https://web.archive.org/web/20130904190535/https://api.dnsdb.info/

[2] https://www.tcpdump.org/manpages/pcap-savefile.5.html,
https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-savefile.manfile.in

-- 
Robert Edmonds