736a2d58ae
* feat(metrics): add source wrapper metrics for invalid and deduplicated endpoints Add GaugeVecMetric.Reset() to clear stale label combinations between cycles. Introduce invalidEndpoints and deduplicatedEndpoints gauge vectors in the source wrappers package, partitioned by record_type and source_type. The dedup source wrapper now tracks rejected (invalid) and de-duplicated endpoints per collection cycle. Update the metrics documentation and bump the known metrics count. Signed-off-by: Seena Fallah <seenafallah@gmail.com> * feat(source): add PTR source wrapper for automatic reverse DNS Implement ptrSource, a source wrapper that generates PTR endpoints from A/AAAA records. The wrapper supports: - Global default via WithCreatePTR (maps to --create-ptr flag) - Per-endpoint override via record-type provider-specific property - Grouping multiple hostnames sharing an IP into a single PTR endpoint - Skipping wildcard DNS names Add WithPTRSupported and WithCreatePTR options to the wrapper Config and wire the PTR wrapper into the WrapSources chain when PTR is in managed-record-types. Signed-off-by: Seena Fallah <seenafallah@gmail.com> * feat(config): add --create-ptr flag and deprecate --rfc2136-create-ptr Add the generic --create-ptr boolean flag to Config, enabling automatic PTR record creation for any provider. Add IsPTRSupported() helper that checks whether PTR is included in --managed-record-types. Add validation: --create-ptr (or legacy --rfc2136-create-ptr) now requires PTR in --managed-record-types, preventing misconfiguration. Mark --rfc2136-create-ptr as deprecated in the flag description. Signed-off-by: Seena Fallah <seenafallah@gmail.com> * refactor(rfc2136): remove inline PTR logic in favor of PTR source wrapper Remove the createPTR field, AddReverseRecord, RemoveReverseRecord, and GenerateReverseRecord methods from the rfc2136 provider. PTR record generation is now handled generically by the PTR source wrapper before records reach the provider. Update the PTR creation test to supply pre-generated PTR endpoints (simulating what the source wrapper produces) instead of relying on the provider to create them internally. Signed-off-by: Seena Fallah <seenafallah@gmail.com> * feat(controller): wire PTR source wrapper into buildSource Pass the top-level Config to buildSource so it can read IsPTRSupported() and the CreatePTR / RFC2136CreatePTR flags. When PTR is in managed-record-types, the PTR source wrapper is installed in the wrapper chain with the combined create-ptr default. Signed-off-by: Seena Fallah <seenafallah@gmail.com> * chore(pdns): remove stale comment and fix whitespace Remove an outdated comment about a single-target-per-tuple assumption that no longer applies. Signed-off-by: Seena Fallah <seenafallah@gmail.com> * docs: add PTR records documentation and update existing guides Add docs/advanced/ptr-records.md covering the --create-ptr flag, per-resource annotation overrides, prerequisites, and usage examples. Update: - annotations.md: document record-type annotation - flags.md: add --create-ptr, mark --rfc2136-create-ptr as deprecated - tutorials/rfc2136.md: point to generic --create-ptr flag - contributing/source-wrappers.md: add PTR wrapper to the chain - mkdocs.yml: add PTR Records navigation entry Signed-off-by: Seena Fallah <seenafallah@gmail.com> * feat(rfc2136)!: remove rfc2136-create-ptr in favor of create-ptr Signed-off-by: Seena Fallah <seenafallah@gmail.com> --------- Signed-off-by: Seena Fallah <seenafallah@gmail.com>
1.4 KiB
Pod Source
The pod source creates DNS entries based on Pod resources.
Pods not running with host networking
By default, the pod source will consider the pods that aren't running with host networking enabled. You can override this behavior by using the --ignore-non-host-network-pods option to ignore non host networking pods.
Using a default domain for pods
By default, the pod source will look into the pod annotations to find the FQDN associated with a pod. You can also use the option --pod-source-domain=example.org to build the FQDN of the pods. The pod named "test-pod" will then be registered as "test-pod.example.org".
Configuration for registering all pods with their associated PTR record
A use case where combining these options can be pertinent is when you are running on-premise Kubernetes clusters without SNAT enabled for the pod network. You might want to register all the pods in the DNS with their associated PTR record so that the source of some traffic outside of the cluster can be rapidly associated with a workload using the "nslookup" or "dig" command on the pod IP. This can be particularly useful if you are running a large number of Kubernetes clusters.
You will then use the following mix of options:
--domain-filter=example.org--domain-filter=10.0.0.in-addr.arpa--source=pod--pod-source-domain=example.org--create-ptr--rfc2136-zone=example.org--rfc2136-zone=10.0.0.in-addr.arpa