Skip to content

add std.dns #3877

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 46 commits into from
Closed

add std.dns #3877

wants to merge 46 commits into from

Conversation

lun-4
Copy link
Contributor

@lun-4 lun-4 commented Dec 9, 2019

based off zigdig

closes #2541

TODO:

  • add DNSRData.size() support for v4 and v6 addresse
  • add serialization of v4 and v6 addresses
  • get a known good packet without pointers to test serialization with

lun-4 added 25 commits December 1, 2019 12:31
 - strToType -> DNSType.fromStr
 - toDNSName -> DNSName.fromString
 - remove classToStr and typeToStr, use tagName builtin
 - remove Header.init
 - add test for DNSType.fromStr
 - fix DNSName.size
 - fix Packet.init
 - make tests use new functions
 - fix str to type test
since DNSName.serialize exists, we don't need helper functions for this
 - make Resource serializable
 - remove LabelComponentTag
 - add asserts when serializing
 - rdata: remove opaque parameter from parseRData
 - add Resource methods to Packet
 - rename parseRData to deserializeRData
@frmdstryr
Copy link
Contributor

Can this do async dns resoultion? (eg like https://github.com/c-ares/c-ares)

@lun-4
Copy link
Contributor Author

lun-4 commented Dec 10, 2019

Domain resolution is not in the scope of std.dns, this implements the structs and serialization/deserialization of them. That would go into std.net.getAddressList (which was implemented in a sync manner, see #3538 )

 - rdata: remove unused function
 - dns.test: make callers give the wanted base64 buffer
 - dns: fix addAditional() incrementing the wrong header field
 - dns: add test for size() methods on DNSName and Resource
 - dns: add a "good enough" generated packet to prevent regressions
@lun-4 lun-4 marked this pull request as ready for review December 10, 2019 21:15
@jayschwa
Copy link
Contributor

Perhaps it should go under std.net.dns?

Copy link
Member

@andrewrk andrewrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for pressing forward on one of the most important parts of the std lib. This pull request is very welcome.

Networking in the std lib is something that must necessarily be given extra scrutiny, so just as a heads up, networking contributions will probably see an unusually high amount of review feedback. I have a round of review feedback for you to look at here.

A couple more things:

  • I agree with @jayschwa about std.net.dns vs std.dns.

  • 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.

I also would tend to favor going about this in the other direction: writing the dns resolution code first, and then smoothing out the the data types and exposing them as an API.

I believe some of these types are relevant to the existing getAddressInfo that you noted; it would be a good test of these data types and enums if the existing dns resolution code was updated to use them.

Cheers @lun-4, thanks again for working on this.

lib/std/dns.zig Outdated
// QTYPE only, but merging under DNSType
// for nicer API

// TODO: add them back, maybe?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make this comment explain what's going on here a bit more, with the commented out items? I don't know much about this topic, so this looks confusing to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are some DNS packet types that weren't relevant to getting a "resolver from domain to ip" working back when I first wrote it. I'll add support for those types for completeness, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to #2524 ?

lib/std/dns.zig Outdated
pub const ResourceList = std.ArrayList(Resource);
const InError = std.io.SliceInStream.Error;
pub const DNSDeserializer = std.io.Deserializer(.Big, .Bit, InError);
pub const DNSError = error{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, for naming things, take the full namespace name into account:

std.dns.DNSError

So you can leave off DNS here and in other places in this file, since it's implied by being inside the dns.zig file. More idiomatic would be:

std.dns.Error

lib/std/dns.zig Outdated
/// Keep in mind DNSName's are not singularly deserializeable, as the names
/// could be pointers to different bytes in the packet.
/// (RFC1035, section 4.1.4 Message Compression)
pub const DNSName = struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this type, the labels field can point to allocated memory. One thing that API users will be wondering is, "what's the plan for managing this memory?" Generally, the documentation for a type which holds references to heap memory should explain the memory-management strategy that it is participating in. For example, is the memory fully expected to be handled by the user of the API? That's fine, but users need to know that, especially in the docs for the functions that allocate heap memory. Is the type capable of cleaning up its own memory? Then it probably needs a deinit() method.

@fengb fengb mentioned this pull request Jan 28, 2020
10 tasks
@andrewrk
Copy link
Member

I'm closing since this hasn't seen any progress for over a month. You are absolutely welcome to re-open this when it's ready for another round of reviews - I'm just putting the ball back in your court. 🏀

@andrewrk andrewrk closed this Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DNS packet struct
6 participants