@pacoxu: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

The KEP about it is https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/504-configurable-pod-dns#proposal
/cc @MrHohn @thockin @bowei
for the author and approvers of the KEP kubernetes/enhancements#504.

• options that are an OS-dependent list of (name, value) options. These values
  are NOT expected to be generally portable across platforms. For containers that
  use /etc/resolv.conf style configuration, these correspond to the parameters
  passed to the option lines. Options will override if their names coincide,
  i.e, if the DnsPolicy sets ndots:5 and ndots:1 appears in the Spec,
  then the final value will be ndots:1.

Thanks @pacoxu . Let's paste how golang parse the config for your references. https://github.com/golang/go/blob/master/src/net/dnsconfig_unix.go#L39-L140

Thanks @pacoxu . Let's paste how golang parse the config for your references. https://github.com/golang/go/blob/master/src/net/dnsconfig_unix.go#L39-L140

I think we don't need to validate the option or do some aliases merging or further meaning parsing.
As the test case shows, in kubelet, we just parse

options ndots:1 attempts:3
options single-request rotate use-vc"

to an array like {"ndots:1", "attempts:3", "single-request", "rotate", "use-vc"}.

This is enough in this case.

• Options will override if their names coincide,
  i.e, if the DnsPolicy sets ndots:5 and ndots:1 appears in the Spec,
  then the final value will be ndots:1.

/lgtm

It can be argued that is not a bug, just a known limitation of current implementation, since it seems that is working as documented.
This change seems to be backwards compatible
/assign @thockin

I still can't find any spec that says how this is SUPPOSED to work. I commented more on the issue #112323

Absent a real user who is really impacted by this, my inclination is to (again) do nothing. The risk of breakage is non-zero. The reward is zero (nobody is complaining, IIUC).

OK, as per the issue #112323 I guess I do not see why we should BREAK it.

Who owns this approve? @khenidak? @aojea?

/approve

Since seems to be valid to have multiple lines with options in a resolv.conf but is not documented how to interpret them, we now merge those options giving preference to the latest entries, making the options field consistent inside the pods, avoiding issues if muslc/libc/... do not agree on the interpretation of the multiline configuration.

I do not know if this should be backported, the references to the kubernetes implementation mentions that only the last option line will be used, so we can argue that it was working as expected on the initial design.

@pacoxu I suggest to add a more detailed release note

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aojea, pacoxu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

I changed the release note like below.

kubelet: when there are multi option lines in /etc/resolv.conf, merge all options into one line in a pod with the Default DNS policy.

Many thanks to @pacoxu @aojea @thockin !

/lgtm