starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #551] code size #234

New issue

Closed

opened 2026-03-07 22:55:43 +03:00 by kerem · 5 comments

kerem commented

2026-03-07 22:55:43 +03:00

Owner

Originally created by @aep on GitHub (Aug 22, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/551

any chance to make idna and url optional dependencies? it's fairly large

Originally created by @aep on GitHub (Aug 22, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/551 any chance to make idna and url optional dependencies? it's fairly large

kerem

2026-03-07 22:55:43 +03:00

closed this issue
added the
perf

crate:proto

easy
labels

kerem commented

2026-03-07 22:55:59 +03:00

Author

Owner

@bluejekyll commented on GitHub (Aug 23, 2018):

I think we could do this. It would mean losing some validation and conversion of international names, and limit us to ascii only name interfaces. I believe it's only in place during Name parsing and Name conversion to Strings.

Basically we could default it to on, and make it optional, then feature flag off the methods that require it.

I think we'd lose these methods when it's not enabled:

https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/label.rs#L45
https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/label.rs#L139
https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/name.rs#L412

And we'd need to limit the Display implementation to remove the condition on internationalization:

https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/label.rs#L218-L238

And then make this struct feature flagged off as well:

https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/name.rs#L736

I think that's all the places where IDNA is in use.

@bluejekyll commented on GitHub (Aug 23, 2018): I think we could do this. It would mean losing some validation and conversion of international names, and limit us to ascii only name interfaces. I believe it's only in place during Name parsing and Name conversion to Strings. Basically we could default it to on, and make it optional, then feature flag off the methods that require it. I think we'd lose these methods when it's not enabled: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/label.rs#L45 https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/label.rs#L139 https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/name.rs#L412 And we'd need to limit the Display implementation to remove the condition on internationalization: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/label.rs#L218-L238 And then make this struct feature flagged off as well: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/name.rs#L736 I think that's all the places where IDNA is in use.

kerem commented

2026-03-07 22:56:05 +03:00

Author

Owner

@aep commented on GitHub (Nov 21, 2018):

thanks so much. i'm rewriting carrier now to replace tokio with mio.

Any chance to put only the dns parser into a separate crate?
trust-dns-proto depends on tokio unfortunately

@aep commented on GitHub (Nov 21, 2018): thanks so much. i'm rewriting carrier now to replace tokio with mio. Any chance to put only the dns parser into a separate crate? trust-dns-proto depends on tokio unfortunately

kerem commented

2026-03-07 22:56:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 22, 2018):

Any chance to put only the dns parser into a separate crate?

I’ve considered it in the past, but haven’t had a need to do so. The project already has so many crates! For some reason I hesitate to add more...

@bluejekyll commented on GitHub (Nov 22, 2018): > Any chance to put only the dns parser into a separate crate? I’ve considered it in the past, but haven’t had a need to do so. The project already has so many crates! For some reason I hesitate to add more...

kerem commented

2026-03-07 22:56:15 +03:00

Author

Owner

@aep commented on GitHub (Jan 5, 2019):

no longer relevant, i wrote my own dns. should we close?

@aep commented on GitHub (Jan 5, 2019): no longer relevant, i wrote my own dns. should we close?

kerem commented

2026-03-07 22:56:20 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 6, 2019):

Eventually I want to rework the library to be generic over futures based implementations, but yes, this we can close.

@bluejekyll commented on GitHub (Jan 6, 2019): Eventually I want to rework the library to be generic over futures based implementations, but yes, this we can close.

kerem referenced this issue

2026-03-15 22:21:51 +03:00

[GH-ISSUE #234] [Server] Please add support for CAA records #406

kerem referenced this issue

2026-03-16 02:01:04 +03:00

[PR #280] [MERGED] Support for CAA Resource Record Type #1336