Development Update #1803

Here are some DNS-OARC development highlights from the past months. These updates are sent out on a bi-monthly basis and the previous updates can be found on our Medium page.

dnsjit

dnsjit is a combination of parts taken from dsc, dnscap, drool, and put together around Lua to create a script-based engine for easy capturing, parsing and statistics gathering of DNS messages while also providing facilities for replaying DNS traffic.

The development for this tool is rapidly progressing, pulling in code from all the other tools and helper libraries I’ve created over the years, simplifying the code and trying not to spend to much time optimizing things (it’s hard when it’s fun).

Currently working on features that greatly increase performance such as:

  • parsing PCAP files myself and using mmap() (x3.5 read performance)
  • using Lua coroutines for custom Lua filters (x4+ throughput)
  • simplifying client code (udp x2.9 send single-thread, x1.15 multi-thread)

Besides IO, the bottleneck is still passing data to other threads since it requires making a copy of the data to give it away, but I am working on ideas for this problem.

No More Fatty Extensions For You, DNS!

Bert Hubert (PowerDNS) held a very interesting talk at IETF101 during the first DNSOP session, about the increasing complexity of the DNS protocol, how this effects implementations, the disconnect between DNS rfc authors, implementors and operators, and much more.

The full talk and especially the Q&A is well worth the time to watch!

Some of the promising outcomes, in my opinion, of this talk and the
discussions afterwards on the DNSOP mailing list are:

Related to this, there was an announcement by PowerDNS, NLNet Labs, CZ.NIC and ISC at OARC28 (video) about removing the many workarounds for EDNS0 that has been plaguing the code (press-releases by PowerDNS, CZ.NIC).

CBOR DNS Stream (CDS) Call for Interest?

This idea developed some time ago while learning CBOR and reading the early drafts of C-DNS which did not do name compression or malformed DNS.

My take on this was a bit different from C-DNS but managed to hit the same “compression” rates, it’s not really compression but more a restructure of the protocol to optimize it.

To understand the difference let’s first look at C-DNS (very simplified); It works by taking common pieces of information, such as FQDN, IP addresses, queries, responses, and putting it in tables. Then it makes references to those entries for each query and/or response it sees.

CDS works kinda the same way but is meant to be streamed. The same common pieces of information are also put into tables but they are limited to the N last pieces seen. The DNS wire-format is transformed into a highly CBOR optimized version of it and the pieces of information are replaced by a reference to when it was last seen. For example, a query will put the QNAME into this table and the response QNAME will reference to it with -1.

CDS also preserves the name compression and any DNS wire-format it can not understand.

Currently CDS is available in dnscap if you compile it yourself and enable this experimental output. There is also a CDS parser written in Python in dnscap’s contrib directory.

If you find this interesting in any form, want me to continue the development or stop (?), are already using it (?), or have any questions or other feedback, please let me know!

Cheers,
Jerry (at) dns-oarc.net
https://twitter.com/lundstromjerry

Domain Name System Operations Analysis and Research Center

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store