Skip to content
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

Bugfix/237 Resolver uses nameserver commented out in /etc/resolv.conf #238

Merged
merged 7 commits into from May 15, 2024

Conversation

wtoorop
Copy link
Member

@wtoorop wtoorop commented May 7, 2024

Fixed issue #237

This /etc/resolv.conf:
    # x

    # nameserver 8.8.8.8

Still configured 8.8.8.8 as nameserver, because the comment detection in `ldns_resolver_new_frm_fp_l()` didn't anticipate empty lines before the comment.
This fix removed all comment handling from `ldns_resolver_new_frm_fp_l()`. Instead a new function is introduced `ldns_fget_token_l_resolv_conf()` that skips comments that start with '#' and ';'. The old `ldns_fget_token_l()` (that is used for zonefiles too) still accepts only ';' for comments.
Copy link
Member

@wcawijngaards wcawijngaards left a comment

Choose a reason for hiding this comment

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

Looks okay from me. Should there perhaps be a comment that the new resolv file function expects a particular array size and ignores the limit argument when it is 0.

@grembo
Copy link

grembo commented May 8, 2024

Patch looks reasonable. I tested it for my limited use case and it works as expected.

@dag-erling
Copy link
Contributor

Are you planning to merge this any time soon?

@wtoorop
Copy link
Member Author

wtoorop commented May 13, 2024

Are you planning to merge this any time soon?

Yes, I will merge it with Wouter's recommendation to add the comment

@dag-erling
Copy link
Contributor

I don't think you fully appreciate the seriousness of this issue...

resolver.c Outdated
@@ -761,6 +761,8 @@ ldns_resolver_new_frm_fp(ldns_resolver **res, FILE *fp)
return ldns_resolver_new_frm_fp_l(res, fp, NULL);
}

ssize_t ldns_fget_token_l_resolv_conf(FILE *f, char *token, const char *delim,
size_t limit, int *line_nr);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please move this prototype to <ldns/parse.h>.

@AlexanderBand
Copy link
Member

AlexanderBand commented May 15, 2024

I don't think you fully appreciate the seriousness of this issue...

To manage expections around this free, open-source project, I'd like to note that unlike projects with production-grade support such as NSD and Unbound, work on ldns is done on a best-effort basis; for example in the context of a research project or an IETF Hackathon. We explicitly mention this in the development vision for the project.

@dag-erling
Copy link
Contributor

To manage expections around this free, open-source project, [...]

You may want to consider your audience before you start handing out life lessons.

@grembo
Copy link

grembo commented May 15, 2024

@AlexanderBand Just to make it clear: Your work on ldns is much appreciated.

I don't think you fully appreciate the seriousness of this issue...

To manage expections around this free, open-source project, I'd like to note that unlike projects with production-grade support such as NSD and Unbound, work on ldns is done on a best-effort basis; for example in the context of a research project or an IETF Hackathon. We explicitly mention this in the development vision for the project.

Maybe it would make sense to clarify the development vision, as the way it is currently written (quoting in full, emphasis is mine)

In principle we only perform basic maintenance and bug fixes on ldns, and will only consider development of new functionality on ad-hoc basis. This could for example be for a research project or an IETF Hackathon. We do not strive for ldns to be a comprehensive library that supports every (emerging) standard.

makes it sound (to me) like you would actually do bug fixes outside of research projects and IETF Hackathons. Using commented out parts of the configuration can have dire consequences, hence the sense of urgency.

@AlexanderBand
Copy link
Member

Yes, we do bug fixes on ldns. Still, we're managing many projects with very limited resources. In the context of all reposnsibilities, ldns will not get the highest priority. I'm respectfully asking for your patience and understanding.

Including a doxygen comment stating the limitations
@wtoorop wtoorop merged commit 5000a56 into develop May 15, 2024
1 of 2 checks passed
@wtoorop wtoorop deleted the bugfix/237 branch May 15, 2024 11:26
@grembo
Copy link

grembo commented May 15, 2024

@wtoorop & @AlexanderBand Thank you!

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.

None yet

5 participants