Ceph

Example usage:

In mDNS-SD (https://datatracker.ietf.org/doc/html/rfc6763#section-4.1) you first query the PTR record for the service that you are interested in. Using Google's Chromecast service "_googlecast._tcp" as an example:

# systemd-resolve --type=PTR _googlecast._tcp.local
_googlecast._tcp.local IN PTR Chromecast-uuid1redacted._googlecast._tcp.local -- link: enp3s0f0
_googlecast._tcp.local IN PTR Chromecast-uuid2redacted._googlecast._tcp.local -- link: enp3s0f0
_googlecast._tcp.local IN PTR Chromecast-uuid3redacted._googlecast._tcp.local -- link: enp3s0f0
_googlecast._tcp.local IN PTR Chromecast-uuid4redacted._googlecast._tcp.local -- link: enp3s0f0

-- Information acquired via protocol mDNS/IPv4 in 1.6ms.
-- Data is authenticated: no

Then, you query one specific record returned by the PTR record for the specific details of that host.

# systemd-resolve --type=SRV Chromecast-uuid1redacted._googlecast._tcp.local

Chromecast-uuid1redacted._googlecast._tcp.local IN SRV 0 0 8009 somehostname.local -- link: enp3s0f0

8009 would be the port, and "hostname.local" would be the mDNS resolvable hostname.

Then resolve the hostname as normal:

# systemd-resolve somehostname.local

Using the "ceph-mon" service:

Configure your local mDNS broadcaster to advertise the ceph-mon service. In this case, i'm using systemd, but other implementations exist.

mimir /etc/systemd/dnssd # cat ceph-mon.dnssd
[Service]
Name=%H
Type=_ceph-mon._tcp
Port=3300

Then on any machine with an mDNS resolver, you can query for the ceph-mon service.

# systemd-resolve --type=PTR _ceph-mon._tcp.local
_ceph-mon._tcp.local IN PTR mimir._ceph-mon._tcp.local      -- link: enp3s0f0

-- Information acquired via protocol mDNS/IPv4 in 61.3ms.
-- Data is authenticated: no

# systemd-resolve --type=SRV mimir._ceph-mon._tcp.local
mimir._ceph-mon._tcp.local IN SRV 0 0 3300 mimir.local      -- link: enp3s0f0

-- Information acquired via protocol mDNS/IPv4 in 127.5ms.
-- Data is authenticated: no

# systemd-resolve --type=A mimir.local
mimir.local IN A 10.0.0.2                                   -- link: enp3s0f0

-- Information acquired via protocol mDNS/IPv4 in 204.4ms.
-- Data is authenticated: no

As a final example,

if your /etc/resolv.conf file is pointing to a DNS server that understands how to deal with mDNS, such as systemd-resolved's 127.0.0.53 hosted DNS server, then you can use tools like nslookup and dig normally. As such, this SHOULD allow for ceph, via the code in DNSResolver::resolve_srv_hosts to work-as is, as long as a PTR record search is conducted as well.

# cat /etc/resolv.conf
nameserver 127.0.0.53

# nslookup -query=ptr _ceph-mon._tcp.local
Server:    127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
_ceph-mon._tcp.local    name = mimir._ceph-mon._tcp.local.

# nslookup -query=srv mimir._ceph-mon._tcp.local
Server:    127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
mimir._ceph-mon._tcp.local    service = 0 0 3300 mimir.local.

# nslookup -query=a mimir.local
Server:    127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:    mimir.local
Address: 10.0.0.2

Or with dig

# dig -t ptr _ceph-mon._tcp.local

; <<>> DiG 9.16.15 <<>> -t ptr _ceph-mon._tcp.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40951
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_ceph-mon._tcp.local.            IN    PTR

;; ANSWER SECTION:
_ceph-mon._tcp.local.    120    IN    PTR    mimir._ceph-mon._tcp.local.

;; Query time: 172 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue May 18 18:18:46 CDT 2021
;; MSG SIZE  rcvd: 69

# dig -t v mimir._ceph-mon._tcp.local

; <<>> DiG 9.16.15 <<>> -t srv mimir._ceph-mon._tcp.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11492
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mimir._ceph-mon._tcp.local.    IN    SRV

;; ANSWER SECTION:
mimir._ceph-mon._tcp.local. 120IN    SRV    0 0 3300 mimir.local.

;; Query time: 149 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue May 18 18:19:19 CDT 2021
;; MSG SIZE  rcvd: 86

# dig -t A mimir.local

; <<>> DiG 9.16.15 <<>> -t A mimir.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39243
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;mimir.local.                        IN    A

;; ANSWER SECTION:
mimir.local.            120    IN    A    10.0.0.2

;; Query time: 157 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue May 18 18:19:37 CDT 2021
;; MSG SIZE  rcvd: 56

So while it wouldn't be perfect to require a DNS server that understands mDNS-SD (https://datatracker.ietf.org/doc/html/rfc6763#section-4.1), personally I'm willing to deal with it, specifically because it does make the patch to the ceph Mon query easier to implement, by allowing the use of the existing DNSResolver::resolve_srv_hosts function with the addition of a DNSResolver::resolve_ptr_records for mDNS resolution.