Feature #50869
openSupport MON discovery over mDNS / DNS-SD
0%
Description
Similar to how MONs can be discovered by querying the SRV record for "ceph-mon" in the MonMap::init_with_dns_srv() function, being able to query for the MONs via mDNS / DNS-SD, such as Bonjour, or Avahi, would be a nice option.
Updated by Michael Jones almost 3 years ago
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
Updated by Michael Jones almost 3 years ago
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
Updated by Michael Jones almost 3 years ago
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.