You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
_ftp._tcp.local: type PTR, class IN, ftp.luthien.local
Name: _ftp._tcp.local
Type: PTR (12) (domain name PoinTeR)
.000 0000 0000 0001 = Class: IN (0x0001)
0... .... .... .... = Cache flush: False
Time to live: 120 (2 minutes)
Data length: 14
Domain Name: ftp.luthien.local
where _ftp._tcp.local points to ftp.luthien.local.
The problem is that avahi-browse (or any other mDNS browser) can't follow those PTR resource records so those services can't be discovered using those tools. It's still possible to resolve the services directly since their SRV and TXT resource records are advertised too but there is no link between _ftp._tcp.local and Troglobit FTP Server._ftp._tcp.local anywhere.
The result of this PTR lookup for the name "<Service>.<Domain>" is a
set of zero or more PTR records giving Service Instance Names of the
form:
Service Instance Name = <Instance> . <Service> . <Domain>
The <Service> portion of the Service Instance Name consists of a pair
of DNS labels, following the convention already established for SRV
records [RFC2782]. The first label of the pair is an underscore
character followed by the Service Name [RFC6335]. The Service Name
identifies what the service does and what application protocol it
uses to do it. The second label is either "_tcp" (for application
protocols that run over TCP) or "_udp" (for all others).
The text was updated successfully, but these errors were encountered:
I'm not sure what to do though. It makes it possible to test things like avahi/avahi@93b1436 so from that perspective I think it's great that it's possible to send PTR RRs like that. I'm not sure it should be included in the examples though. It could be that they are copied verbatim and end up being advertised by various devices like for example avahi/avahi#251. Those avahi bugs were fixed so it isn't that bad anymore but still.
The first two examples at https://github.com/troglobit/mdnsd?tab=readme-ov-file#service-records come with
and it leads to PTR resource records like
_ftp._tcp.local: type PTR, class IN, ftp.luthien.local Name: _ftp._tcp.local Type: PTR (12) (domain name PoinTeR) .000 0000 0000 0001 = Class: IN (0x0001) 0... .... .... .... = Cache flush: False Time to live: 120 (2 minutes) Data length: 14 Domain Name: ftp.luthien.local
where
_ftp._tcp.local
points toftp.luthien.local
.The problem is that
avahi-browse
(or any other mDNS browser) can't follow those PTR resource records so those services can't be discovered using those tools. It's still possible to resolve the services directly since their SRV and TXT resource records are advertised too but there is no link between_ftp._tcp.local
andTroglobit FTP Server._ftp._tcp.local
anywhere.According to https://datatracker.ietf.org/doc/html/rfc6763#section-4.1
where
<Service>
should follow https://datatracker.ietf.org/doc/html/rfc6763#section-7The text was updated successfully, but these errors were encountered: