New component: DNS Query receiver

[stampflit]

The purpose and use-cases of the new component

The DNS query receiver is used to collect latency and error metrics about a DNS server. This receiver doesn't ingest observability data from an external source, but rather repeatedly performs DNS queries itself to produce the desired data.

This proposal is inspired by the existing Telegraf DNS Query Input Plugin

Example configuration for the component

receivers:
  dnsquery:
    # A list of DNS servers to monitor
    servers:
      - "8.8.8.8"
      - "1.1.1.1"
    # A list of DNS queries that should be performed
    queries:
      - domain: "example.com" # Domain or subdomain to query
        record_type: "A" # Record Type
    # Query timeout
    timeout: "2s"
    # Collection interval
    collection_interval: 30s

Telemetry data types supported

metrics

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am a member of the OpenTelemetry organization.
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

No response

Sponsor (optional)

No response

Additional context

I don't have a code owner or a sponsor. I'm opening this issue to see whether there is interest in general to have such a receiver and if so, to find a sponsor.

There are few similar use cases that come to mind for such a component:

• Monitoring the status of a DNS server
• Monitoring whether a certain server can still reach a DNS server (commonly done as a connectivity check)
• Using DNS latencies, error rates as an indicator of networking infrastructure wellbeing

The latter two points are also covered by httpcheckreceiver, though the complexity of modern http is much higher compared with traditional DNS.

[atoulme]

Can you detail the metrics you would create with this? Names and attributes in particular.

[stampflit]

Can you detail the metrics you would create with this? Names and attributes in particular.

I don't have strong opinions on this and haven't invested much time in this yet, so I'm open to input. I'd do it similar to telegraf's dns query plugin / the httpcheckreceiver.

Here is a first draft:

dns_query.duration

Unit	Metric Type	Value Type
ms	Gauge	Int

attributes

Name	Description	Values
domain	domain as specified in query	Str
record_type	record_type as specified in query	Str
server	resolved ip / name, if applicable	Str
result	success, error or timeout	Str

dns_query.status

Unit	Metric Type	Value Type
1	Sum	Int

1 if the check resulted in error or timeout, otherwise 0.

attributes

Name	Description	Values
domain	domain as specified in query	Str
record_type	record_type as specified in query	Str
server	resolved ip / name, if applicable	Str
result	success, error or timeout	Str
rcode	rcode string representation1	Str

For rcode we could also use int type and just stick with the int representation ²

I can put some more effort into this, especially if this it is decided that we want go forward with this proposal becoming a receiver.

The format also depends how extensive we want to make this receiver. This is a rather minimalistic version.

Footnotes

1. https://github.com/miekg/dns/blob/v1.1.62/edns.go#L769 ↩

2. https://github.com/miekg/dns/blob/v1.1.62/types.go#L128 ↩

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[stampflit]

I'm still interested in developing this. What do I need to do to drive this forward?