DNS packet struct

[daurnimator]

Eventually we're going to need a DNS client in the standard library. Although the networking piece(s) should wait for #1778, we can still write a DNS packet type now.

It should:

• Use a packed struct to represent a DNS packet header
• Have non-extern enums for section/class/type
• Include definitions/parsers for various types
• Have constructors for common packet types

Consider cribbing from https://github.com/wahern/dns/blob/6cefd43f522f67680632309d4c221142c3798b71/src/dns.h#L354

[lun-4]

I implemented a zig DNS client library last couple of days, can PR it if this gets accepted (even though it's basically my first try at writing a library, so I can't ensure it's up to standard library's code quality).

https://github.com/lnyaa/zigdig/blob/eb026b7e40c12e1040cae858bb4c79339a00748c/src/packet.zig

[GoWind]

Hi, I noticed that the referred PR has been closed. Although I am new to Zig, I would like to work on this and try to raise a PR. I read @andrewrk's comments on this and would like to understand what is missing/required.

I would like to see an attempt at DNS resolution API without heap memory allocation. I think it is possible and desirable. So merging of this pull request will be blocking on that attempt, whether it is done by you, me, or someone else.

Does it mean that you want the APIs , ideally to not take an allocator as argument and try as much as possible to use only the stack to create temporary storage / variables ?
Also, is the focus be on implementing something like gethostbyname via pure Zig ? Or is the initial requirement to implement a subset of the DNS client linked above , such a the resolver ?

[lun-4]

Does it mean that you want the APIs , ideally to not take an allocator as argument and try as much as possible to use only the stack to create temporary storage / variables ?

That's the idea. I rewrote my dns library afterwards, and was able to make serialization work without allocation, but couldn't get deserialization to work mostly because of DNS name pointers.

Also, is the focus be on implementing something like gethostbyname via pure Zig ?

Yeah! See the musl port in std.net.getAddressList

[GoWind]

Thanks. Apologies in advance if I am asking really silly questions, but I just want to clarify some doubts I have

It looks like the Issue/related was started with the motivation to write a DNS packer serializer/deserializer, but looking at the comments, the goals has been changed to provide the DNS resolution (basically the resolver interface in the linked DNS header file). Did I get this right ?

What would be the ideal end for this issue to be considered done: An implementation of getAddressList in pure Zig ? Currently, getAddressList makes use the C library's (I presume) getAddrInfo and we want to provide this (getAddrInfo) via std.dns , or, would it be something like the DNS's resolver interface ?

[lun-4]

Apologies for not answering in almost a year.

I got myself back on track on my library and was able to refactor algorithms to remove recursion in the library, but it's not up to replacing the internal resolver implementation in std.net.getAddressList yet (lun-4/zigdig#4). The current getAddressList DNS resolver is ported from musl libc, and that is used when building on Linux (using libc when available/necessary), so to answer your question, almost yes, it's already in Zig, we just need to turn the internal implementation into something more Zig-like rather than C-like, but I could be wrong.

[dantecatalfamo]

I also have a DNS implementation in zig that might be useful for this https://github.com/dantecatalfamo/zig-dns

[lun-4]

I missed to give an update in all this time, so, to not leave the issue in a vacuum of information, I was able to implement a dns API in February that does not need to allocate on the simplest case which is an getAddrInfo-style function (note how ctx does not have anything related to allocation). I don't know when I'll get around to creating a PR for a second round of reviews, but I felt an update was necessary.