IANA's List of Domain Name System (DNS) Parameters | Hacker News Reader

IANA's List of Domain Name System (DNS) Parameters

iana.org

Those happy days when we distributed the equivalent of password files in the DNS via the IN HS (HESIOD) type. (Kerberos)

And then Sun went feral on Yellow pages/NIS and we all stopped loving each other anyway and now.. it's a lot more fragmented.

There are many deprecated RRtypes. "lets put it in the DNS" is a bit of a meme.

(use of past tense invites somebody to point out you can still run the code if you walk back in e.g. NetBSD sources but you might find widespread support for these RRtypes missing from a lot of things)

"Let's build a DNS parser that's spec compliant" is something that only insane people would say. I dare to argue it's an impossible task at this point. Having to read dozens of RFCs just to find out what's been deprecated and what's been added is really not a good way to implement code and tests :D

Especially with the typical problems that come with naive implementations that cannot deal with malformed truncated packets or pointer loops (stack overflows/buffer overflows) in compressed packets.

And I am not even scratching DNS cookies or newer DNS record types here, which as you said is another deep rabbit hole.

> "Let's build a DNS parser that's spec compliant" is something that only insane people would say. I dare to argue it's an impossible task at this point.

Having worked on a toy RFC1035 DNS parser from scratch (I had written a DNS server once before, but I wouldn't even consider it a toy server) over the last few months[0], I can agree that it would be a very hard task to write a fully spec compliant DNS parser, but not that it would be anywhere near impossible. Documentation is scarce, but if you look hard enough it can be found. Finding out whats been deprecated does require reading a lot of RFCs but the IETF Datatracker site makes it easy to find any of those update RFCs and errata.

While I didn't implement parsers for that many individual RR types a lot of them could be reused, since many RR types share the same format. Also if you are just writing a recursive resolver then you don't really need to actually parse every kind of RR type, you can just blindly forward most of them. Dealing with malformed/truncated packets is a pain to figure out, but not that hard to do, in my opinion, once you think over all the possible ways a packet could be malformed.

Seeing how Ladybird[1] has basically proven the "Building a browser from scratch is impossible" crowd wrong, I'm sure that some project could come around and do the same for DNS.

[0] https://github.com/PotentialStyx/dns-server

[1] https://ladybird.org/

I wrote a DNS parser [1], and I gave up trying to decode every RR type. I've mostly stuck to the non-crypto records, and while I have support for a number of obsolete and experimental record types, it was easy to parse them as a lot of RRs share the same format.

[1] https://github.com/spc476/SPCDNS

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)

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

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.

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

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.

Reply on news.ycombinator.com