This type of service discovery relies on DNS to gather data. It works by defining a list of domain names that will be queried regularly to obtain targets. The name servers that are used for resolution are looked up in /etc/resolv.conf. This discovery integration, besides supporting A and AAAA DNS records, is also able to query SRV records, which also provide the port for the service:

~$ dig SRV hey.service.example.inet
...
;; QUESTION SECTION:
;hey.service.example.inet. IN SRV

;; ANSWER SECTION:
hey.service.example.inet. 0 IN SRV 1 1 8080 server01.node.example.inet.

;; ADDITIONAL SECTION:
server01.node.example.inet. 0 IN A 192.168.42.11
server01.node.example.inet. 0 IN TXT "squad=purple"
...

We can see that, by querying the SRV record for hey.service.example.inet in this example, we get the service location server01.node.example.inet and port 8080. We also get the A record with the service IP address and a TXT record with some metadata.

The following snippet illustrates a sample scrape configuration using this DNS service discovery integration. It does this by using the domain hey.service.example.inet from before:

scrape_configs:
  - job_name: 'dns_sd'
    dns_sd_configs:
      - names:
        - hey.service.example.inet

The returned SRV records will be converted into new targets. Prometheus doesn't support the advanced DNS-SD specified in RFC 6763, which allows metadata to be transmitted in associated TXT records (as seen in the dig command previously). This means that only the service address and port can be discovered using this method. We can see what discovered labels are available in the following screenshot:

From all the discovery integrations, this is the one with the lowest amount of provided metadata. Adding to that, using DNS for service discovery is hard to get right – planning for slow convergence, considering several different cache layers that may or may not respect record TTLs, among other concerns. This should only be considered for advanced cases.