Implementation Status
This page summarizes the requirements of the LLMNR specification and the current status of the implementation.
Note: Any information in this page could be obsolete.
| Requirement | Implemented |
|---|---|
| Section 2 | |
| A host MAY be configured as a sender, but not a responder. | N/A |
| A host configured as a responder MUST act as a sender, if only to verify the uniqueness of names as described in Section 4. | Not yet |
| Section 2.1 | |
| LLMNR implementations SHOULD send UDP queries and responses only as large as are known to be permissible without causing fragmentation. | Maybe? |
| When in doubt, a maximum packet size of 512 octets SHOULD be used. | Not yet |
| LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 9194 octets …. | No? |
| Section 2.2 | |
| (No sender functions are currently implemented.) | |
| Section 2.3 | |
| An LLMNR response MUST be sent to the sender via unicast. | Yes |
| The SOA RR MUST NOT be the only RR that a responder has. | Yes |
| Responders MUST listen on UDP port 5355 on the link-scope multicast address(es) …, and on TCP port 5355 on the unicast address(es) …. | UDP-only |
| Responders MUST direct responses to the port from which the query was sent. | Yes |
| For queries received by UDP, the responder MUST take note of the source port and use that …. | Yes |
| Responses MUST always be sent from the port to which they were directed. | Yes |
| Responders MUST respond to LLMNR queries for names and addresses for which they are authoritative. | Only for a name |
| Responders MUST NOT respond to LLMNR queries for names for which they are not authoritative. | Yes |
| Responders MUST NOT respond using data from the LLMNR or DNS resolver cache. | Yes |
| If a responder is authoritative for a name, it MUST respond with RCODE=0 and an empty answer section, if the type of query does not match an RR that the responder has. | Yes |
| Section 2.4 | |
| (No unicast queries are currently supported.) |
