3 ms·

I always end up on this page every time I need to write a DNS parser (which happens way more often than I'd like)

by bhaney 2y ago

daneel_w 2y ago
How many times have you reinvented your own wheel by now?
- bhaney 2y ago
  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.
olowe 2y ago
Do you mean the binary message format or something higher level? I’ve got a little DNS client/server library in Go [1], and I’m curious whether there’s a minimal subset of the binary format I could handle myself so my library only depends on the Go standard library. Any tips? [1]: https://pkg.go.dev/olowe.co/dns https://pkg.go.dev/olowe.co/dns
- bhaney 2y ago
  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.

I always end up on this page every time I need to write a DNS parser (which happens way more often than I'd like)

by bhaney 2y ago

I always end up on this page every time I need to write a DNS parser (which happens way more often than I'd like)

daneel_w 2y ago

How many times have you reinvented your own wheel by now?

bhaney 2y ago
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.

olowe 2y ago

Do you mean the binary message format or something higher level? I’ve got a little DNS client/server library in Go [1], and I’m curious whether there’s a minimal subset of the binary format I could handle myself so my library only depends on the Go standard library. Any tips? [1]: https://pkg.go.dev/olowe.co/dns https://pkg.go.dev/olowe.co/dns

bhaney 2y ago
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.