There is no mention of the various options available to the resolver in resolv.conf(5). A common option is "edns0" and grepping the source shows there are others that should be documented as well: /* search for and process individual options */ printf(";; res_setoptions(\"%s\", \"%s\")..\n", options, source); statp->options |= RES_NOTLDQUERY; statp->options |= RES_USE_INET6; statp->options |= RES_INSECURE1; statp->options |= RES_INSECURE2; statp->options |= RES_ROTATE; statp->options |= RES_NOCHECKNAME; statp->options |= RES_USE_EDNS0; statp->options |= RES_USE_DNAME; statp->options |= RES_NO_NIBBLE2; statp->options &= statp->options &= ~RES_INIT;
Here's the edns0 options from the NetBSD man page. The other missing options are documented there as well. Since a fresh FreeBSD installation includes the line, options edns0 It would be best to at least include this one, edns0 attach OPT pseudo-RR for ENDS0 extension specified in RFC 2671, to inform DNS server of our receive buffer size. The option will allow DNS servers to take advantage of non- default receive buffer size, and to send larger replies. DNS query packets with EDNS0 extension is not compatible with non-EDNS0 DNS servers. The option must be used only when all the DNS servers listed in nameserver lines are able to handle EDNS0 extension.
Any progress on this one? Todya I tried to find what edns0 means in man resolv.conf and found nothing. Quick web search takes me to this PR. I am on FreeBSD 11.2.
Created attachment 228042 [details] resolver(5) / resolv.conf(5) patch Document available options. Not all options in resolver(3) are exposed as options in resolv.conf.
@Mark Felder Are you able to commit Felix's patch?
Is anyone taking care of this issue? I stumbled over it today and find it very disturbing, that a simple documentary issue takes over six years to be fixed ... MfG oh
I just opened a review for it here: https://reviews.freebsd.org/D37096
Re: <https://reviews.freebsd.org/D37086>, the 'patch' keyword (above) can/should be removed. Bug 227147 will gain a hint of: * how to seek bug reports where an attachment is definitely a patch. bcr@ would you like to make yourself the assignee? Also, add the URL of the review to the See also: field. Thanks. (In reply to O. Hartmann from comment #5) This Bugzilla includes more than a thousand non-resolved reports that use the (deprecated) patch keyword. For each such report that is relatively old, there might be any number of reasons for lack of progress. I think, it'll be useful to discuss generally – without singling out this bug 206165 – can I suggest the freebsd-questions mailing list? Or IRC, if you prefer: aim for the #bugs channel. Thanks.
> … add the URL of the review to the See also: field. … For clarity, I mean: * your D37096 * not my D37086
Re: comment #7 > aim for the #bugs channel. Correcting myself: the #freebsd-bugs channel. Apologies for the noise.