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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
