Using sockburp to debug ns(n)cd

In the last weeks, PicNoir and I finally found the time to squash some of the remaining bugs in the nsncd host lookup support .

For the detailed report on the fun involved in that, head over to PicNoir’s blog post .

This blogpost is about the little tool developed to help debugging, sockburp , which can send requests to two backends, compare responses, and do recordings for mismatches.

Its name is inspired by Burp Suite , and the fact it operates on Unix sockets.

The nscd socket protocol is a binary request-response protocol ¹.

The client(s) sending requests (binaries linked against glibc and using the NSS- related functions) are however very picky, and have certain non-obvious assumptions about responses in edge-cases that we didn’t fully meet yet.

It gets quite messy to stare at and compare outputs from two sockdump runs, one with glibc-nscd, and one with nsncd.

sockburp can provide the nscd socket itself, and then dispatch requests to both glibc (A) and nsncd (B) ². The answer from (A) is returned, but in case the answer from (B) differs, the request and the two different responses are logged in a PCAP file.

You can run it on your machine in the background, and inspect the differences it found after some hours of normal usage.

The PCAP file uses the interface index and name fields to record the sockets, as well as the data sent over the wire, so it becomes easy to compare responses:

We didn’t end up writing a Wireshark dissector for the protocol yet (which would allow seeing request types and responses as additional fields), as the packets were quite small and easy to parse manually, but it certainly would be possible.

sockburp itself is not specific to the protocol being used, so this probably is gonna be useful for many different scenarios as well, like implementing the nix-daemon protocol in Tvix .

I hope you find this useful!