Yeah, I mean the binary message format. It's not particularly complicated to parse if you don't care to handle all the custom logic for each RRTYPE. You parse a fixed size header, one section with a couple fields, and up to three more sections that all have the same format. The most annoying part of the core format to implement is probably message compression, but it's fairly straightforward too as long as you're keeping the entire original message around for the duration of the parsing. I'd say just skim RFC 1035 section 4 and take a crack at it. It's a fun exercise if nothing else.

Oh plenty of times. The biggest problem is that when I'm reinventing the wheel, I don't want my design to be constrained by existing axles, so naturally I have to reinvent those too, and so on and so forth.

At this point I have this tangled web of custom IoT devices (motion sensors, lightbulbs, smart plugs, thermostat, etc) that I build and write all the firmware and orchestration software for. I have them all do autoconf and service discovery via mDNS, and the state of DNS parsing libraries in that space isn't amazing. I've run into multiple libraries now that actually error out or crash on completely valid and in-the-wild edge cases (usually involving some combination of message compression and zero-length fields), and it's often easier to just write a new parser that only bothers to handle the parts I care about rather than fixing a much larger parser so it doesn't crash.