plugin/dns64: new configuration directive to break IPV4 name resolution

[p-weston]

I have a small patch to plugin/dns64 which adds a break_ipv4_names directive. Would you want a PR for it?

It returns NXDOMAIN for all A requests, except for those generated by the dns64 plugin itself for the purpose of building a AAAA record.

I have found that on ipv6 only nodes this fixes several packages that would otherwise fail due to only trying one address, or stubbornly using up their retries on ipv4 addresses. Ideally these packages would all be fixed, but a single change working around so many different problems has been very useful. I believe some packages have deliberately chosen to prefer v4 addresses as a workaround for badly configured v6 networks.

I haven't written any documentation for it, but note it is against the RFC, and will break anything like email SPF record validation which sometimes needs to explicitly resolve a name to an ipv4 address.

[chrisohaver]

Thanks for sharing! In a nutshell, how did you solve it? Earmarking the A lookups originating from the dns64 plugin?

[p-weston]

Yes. Before the A lookup in DoDNS64 I create a new context with:
ctx = context.WithValue(ctx, BreakIPv4NamesKey{}, 1)
and at the top of ServeDNS return NXDOMAIN for anything matching
d.BreakIPv4Names && req.QType() == dns.TypeA && req.QClass() == dns.ClassINET && ctx.Value(BreakIPv4NamesKey{}) == nil

I was concerned different results for the same lookup would be broken by the cache plugin, but it seems to work, so I haven't looked into how.

[chrisohaver]

I create a new context

OK - So you're not directly earmarking the request itself, but using the context. In CoreDNS, this approach may be better implemented using CoreDNS's "metadata" (which under the hood is just a [string]string map saved in the context). But using the existing metadata would make the information available to other plugins. Other plugins might also want to know if a request is coming from "itself" (via an Upstreamer implementation).

I was concerned different results for the same lookup would be broken by the cache plugin .

It should be causing issues. If you are creating an NXDOMAIN response without an SOA record in the Authority section of the response, then it won't be cached (and thus won't spoil dns64's lookups). Strictly speaking though, an NXDOMAIN response without the SOA is non-compliant to DNS RFC. Regardless, even if the response isn't cached it still means that a client that making a lookup of an A record that was already synthesized by the dns64 plugin would not receive an NXDOMAIN as intended.

Taking a more general-use approach, I'm thinking something along the lines of:

• in upstream.Lookup, create a new copy of the context with the metadata only containing a single value (e.g. named "upstream/origin") to indicate the origin of the query is coredns itself and save to a new context. This probably would need a modification to Metadata to preserve any pre-existing metadata values when processing a new request.
• Other plugins, could then access this information using the existing metadata interface. e.g. the log plugin could log the value. or the view plugin could route traffic based on the value.

Regarding the view plugin example above: The view plugin could use the new metadata to route traffic originating from coredns itself to a separate server block. This would allow you emulate the proposed "ipv4 name breaking" function in the configuration using two server blocks, one that only accepts queries originating from coredns itself, and a second that blocks all A queries.

# this server block defines a view that only processes queries originating from coredns
. {
  view origin-coredns {
    expr metadata('upstream/origin') == 'coredns'
  }
  cache
  forward . /etc/resolv.conf
}

# this server block processes all other queries
. {
  template IN A . {
      rcode NXDOMAIN
      authority "{{ .Zone }} 60 IN SOA {{ .Zone }} {{ .Zone }} (1 60 60 60 60)"
  }
  cache
  dns64
  forward . /etc/resolv.conf
}

Granted, this is clearly much more verbose than something purpose built (e.g. hard coded into dns64).
Note: It avoids the cache contention issue, by keeping separate caches.

Regarding the NXDOMAIN response: Returning NXDOMAIN might cause issues with resolver domain searches in certain situations (allowing searches to continue when they should otherwise have stopped).

[p-weston]

Thanks, good points. I will try returning the real A query with the A records stripped out, and see how things react.