Talk:Multicast DNS
| This is the talk page for discussing improvements to the Multicast DNS article. This is not a forum for general discussion of the article's subject. |
Article policies
|
| Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||
| |||||||||||||||||||||
broadcast / multicast
[edit]Is it possible that this article uses broadcast and multicast synonymously? From my understanding mDNS only uses broadcast, not multicast. --InvliD (talk) 02:00, 10 October 2013 (UTC)
- mDNS uses IP multicast. I have removed "broadcast" from the article. ~KvnG 14:36, 11 October 2013 (UTC)
Hex view
[edit]Putting this here as a note that it would be sensible to do a hex editor type view with ASCII to the left, as otherwise it makes the dumps of example communicatons needlessly impenetrable. I don't quite have time to fix this now, however, and I don't know the best way to do it anyway. --2001:470:1F09:28F:0:0:0:3 (talk) 01:21, 5 October 2015 (UTC)
source
[edit]is implemented by the Apple Bonjour and Linux nss-mdns services. Is there source for the latter? — Preceding unsigned comment added by 108.171.135.184 (talk) 20:54, 26 May 2016 (UTC)
QNAME inaccuracy
[edit]In the "Queries" section, the following statement is made: "The list is terminated by a single null-byte..." This is not necessarily true since the list may be terminated by a byte with the two high-order bits set to signal an indirect pointer. Nathan Osman (talk) 01:57, 18 February 2017 (UTC)
- Nathan Osman, I have added a note. Do you have a source for this? Domain Name System does not have this level of detail. ~Kvng (talk) 20:07, 10 September 2021 (UTC)
- Someone previously removed the entire section and then someone else restored it. Honestly, I agree with whoever blew it away. Trying to replicate whole sections of RFC in Wikipedia seems inappropriate to me. Perhaps a brief summary and a pointer to the authoritative source. As you say, other similar articles have nowhere near this level of detail. EVhotrodder (talk) 20:25, 10 September 2021 (UTC)
Detailed dissection
[edit]I have removed the following packet dissection from the end of the article. I don't think it is of particular help to most readers. ~Kvng (talk) 17:28, 13 May 2020 (UTC)
Example
[edit]Trying to ping the appletv.local host would cause an mDNS client computer to multicast the following UDP packet:
00 00 Transaction ID 00 00 Flags 00 01 Number of questions 00 00 Number of answers 00 00 Number of authority resource records 00 00 Number of additional resource records 07 61 70 70 6c 65 74 76 "appletv" 05 6c 6f 63 61 6c "local" 00 Terminator 00 01 Type (A record) 00 01 Class
The appletv.local host would respond by multicasting its mDNS response packet. For example:
00 00 84 00 00 00 00 01 00 00 00 02 07 61 70 70 6c 65 74 76 05 6c 6f 63 61 6c 00 00 01 80 01 00 00 78 00 00 04 99 6d 07 5a c0 0c 00 1c 80 01 00 00 78 00 00 10 fe 80 00 00 00 00 00 00 02 23 32 ff fe b1 21 52 c0 0c 00 2f 80 01 00 00 78 00 00 08 c0 0c 00 04 40 00 00 08
In its header, the non-zero fields are the Flags word (84 00), the ANCOUNT word (00 01), and the ARCOUNT word (00 02). The data again begin with the FQDN (hex 07 61 70 70 6c 65 74 76 05 6c 6f 63 61 6c 00 for appletv.local), followed by that host's DNS information:
- the A/IPv4 address type code (hex 00 01),
- the IPv4 class code (hex 80 01),
- the IPv4 TTL (hex 00 00 78 00 for 30720 seconds),
- the IPv4 length (hex 00 04),
- the four IPv4 address bytes (hex 99 6D 07 5A, or 153.109.7.90 in dotted-decimal notation),
- the FQDN offset (hex C0 0C for byte 12),
- the AAAA/IPv6 address type code (hex 00 1C),
- the IPv6 class code (hex 80 01),
- the IPv6 TTL (again hex 00 00 78 00),
- the IPv6 length (hex 00 10),
- the 16 IPv6 address bytes (hex FE 80 00 00 00 00 00 00 02 23 32 FF FE B1 21 52),
- the FQDN offset (hex C0 0C for byte 12),
- the NSEC type code (hex 00 2F),
- the NSEC class code (hex 80 01),
- the NSEC TTL (again hex 00 00 78 00),
- the NSEC length (hex 00 08, for an 8-byte name section record), and
- the 8 NSEC block and bitmap bytes (hex C0 0C 00 04 40 00 00 08)
Where is mDNS?
[edit]The article doesn't seem to specify who owns client and server mDNS software and processes, where they run, and whether they have any settings, properties, or logs. Is mDNS hosted locally or remotely? Does it follow any standards? Is mDNS routinely used by client OSs such as Linux, Windows, MacOS, and mobile devices? Or are they part of an optional generic or proprietary feature? How, exactly, does mDNS contrast with the better-known DNS system on the World Wide Web? Who uses mDNS and why? Can such details be added to the generalities already given in the article? David Spector (talk) 14:55, 13 June 2021 (UTC)
- @David spector: I can answer most of those questions for you, but I'm not sure that it's worth spending too much time on them in this article, since they're relatively general questions, and the answers don't apply particularly more to mDNS than to other similar protocols. But, if you or anyone else wants to, you're welcome to use any of the following to augment the article proper. So, to address your questions:
- mDNS is a peer-to-peer protocol, so although the guts are implemented as independent client and network-bound service, they're typically bundled together in any software a user would install or configure. There are both open-source and closed-source implementations. Notable closed-source implementations are those by Apple and Microsoft, which are bundled in MacOS, iOS, and Windows.
- The mDNS transponder runs in association with discoverable services connected to local-area networks. For instance, a network-attached laser printer would run an mDNS transponder such that it could be discovered by devices which want to print to it. A laptop would run an mDNS transponder to indicate that file-sharing, or screen-sharing services were available on it. Other devices, with human users or code which needs to find a service, would use the client side to discover any services available on the LAN or within a defined multicast domain.
- At a very low level, below the level a normal user would have access to, yes, certainly. Users (or site administrators) generally name devices and services, and those names get passed down into mDNS transponder configuration, but that's indirect; it's not done by users editing a conf file with vi. Likewise, logging might be done within the OS, but is not likely to be visible to a user unless debug flags have been set, for instance.
- Locally only. That's the point.
- Yes, that's the topic of this article, and what the vast majority of the word-count is dedicated to. Those are IETF standards (and informational documents).
- Yes. When they want to print, or share files, for instance.
- I'm not sure I understand the question well enough to give you a satisfying answer, but you're welcome to clarify it. mDNS is included in the operating system of everything that's likely to need to use it. It's an intentionally very simple protocol, and its value comes entirely from its ubiquity and interoperability, so making it optional or adding proprietary features would be relatively self-defeating.
- mDNS is a subset of the family of DNS protocols. The World Wide Web is the set of interconnected Internet-reachable HTTP servers; there's no direct connection between the two, but the DNS is used, in essentially every instance, to discover HTTP servers. That's mDNS when the HTTP server is, for instance, the configuration mechanism for an IoT device on the LAN.
- You do, and people like you, because they want to print, or set the temperature on their thermostat, or whatever.
- Sure; bearing in mind that past readers have not thought it necessary, you're very welcome to. I'm sure many of us would be happy to help. Bill Woodcock (talk) 19:34, 13 June 2021 (UTC)