zooqueen
66369c5a2d
Nine packages failed. Eight of them for one reason: `go test ./...` ran without
the tags the Makefile ships with (GOTAGS = grpcnotrace metrics), and
luxfi/metric is `//go:build !metrics` — every counter, gauge and histogram is a
no-op unless that tag is set. So metrics, metrics/vars and the kubernetes
object counters were all asserting on numbers that could never move:
RequestCount was not incremented. Before: 0.000000, After: 0.000000
The shipping binary does set it, so this was never a production defect — but a
gate that builds something other than what ships cannot see one either.
The rest were real, and none of them are about metrics:
test/metric_naming_test.go declared a local `type metric` while importing
the package named metric, which every other file here imports too. The
local type is the newcomer; renamed it visitor, for the ast.Visitor it is.
Its BuildFQName call went back to prometheus, which is whose name format is
under test — luxfi/metric has no three-part equivalent, only
AppendNamespace(namespace, name).
Three %q verbs applied to numbers — an MX preference, an Rcode, a SOA
serial. Newer vet rejects them, and `go test` runs vet, so three packages
failed to build without ever reaching a test.
TestImportOrdering walked operator/, which is its own module
(github.com/hanzoai/dns-operator) and imports no coredns, so the
std -> coredns -> 3rd shape it checks for has no middle group to find.
Skipped like pb/ and vendor/ already are, for the same reason.
Eight of the nine pass now. The ninth is test/, where seven metrics
integration tests scrape /metrics and find nothing — the counters record but
are not exposed. That is the other half of the luxfi/metric migration and
wants its own change.
dns64
Name
dns64 - enables DNS64 IPv6 transition mechanism.
Description
The dns64 plugin will when asked for a domain's AAAA records, but only finds A records, synthesizes the AAAA records from the A records.
The synthesis is only performed if the query came in via IPv6.
This translation is for IPv6-only networks that have NAT64.
Syntax
dns64 [PREFIX]
- PREFIX defines a custom prefix instead of the default
64:ff9b::/96.
Or use this slightly longer form with more options:
dns64 [PREFIX] {
[translate_all]
prefix PREFIX
[allow_ipv4]
}
prefixspecifies any local IPv6 prefix to use, instead of the well known prefix (64:ff9b::/96)translate_alltranslates all queries, including responses that have AAAA results.allow_ipv4Allow translating queries if they come in over IPv4, default is IPv6 only translation.
Examples
Translate with the default well known prefix. Applies to all queries (if they came in over IPv6).
. {
dns64
}
Use a custom prefix.
. {
dns64 64:1337::/96
}
Or
. {
dns64 {
prefix 64:1337::/96
}
}
Enable translation even if an existing AAAA record is present.
. {
dns64 {
translate_all
}
}
Apply translation even to the requests which arrived over IPv4 network. Warning, the allow_ipv4 feature will apply
translations to requests coming from dual-stack clients. This means that a request for a client that sends an AAAA
that would normal result in an NXDOMAIN would get a translated result.
This may cause unwanted IPv6 dns64 traffic when a dualstack client would normally use the result of an A record request.
. {
dns64 {
allow_ipv4
}
}
Metrics
If monitoring is enabled (via the prometheus plugin) then the following metrics are exported:
coredns_dns64_requests_translated_total{server}- counter of DNS requests translated
The server label is explained in the prometheus plugin documentation.
Bugs
Not all features required by DNS64 are implemented, only basic AAAA synthesis.
- Support "mapping of separate IPv4 ranges to separate IPv6 prefixes"
- Resolve PTR records
- Make resolver DNSSEC aware. See: RFC 6147 Section 3
See Also
See RFC 6147 for more information on the DNS64 mechanism.