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
According to [[https://datatracker.ietf.org/doc/html/rfc6762#section-6.7|Section 6.7 of the RFC]], if the query was sent not from port 5353, the responder MUST respond over unicast and, most importantly, to the same port that the query was sent from.
This is what currently prevents
dig -p 5353 @224.0.0.251
from working, since dig is expecting the response on the random port it sent its query from, but umdns, contrary to the specifiation, always sends to port 5353.
The text was updated successfully, but these errors were encountered:
I made a patch (untested!) that will ensure the response goes to the right address/port.
However, there are additional requirements that, IIUC, are currently not satisfied:
This unicast response MUST be a
conventional unicast response as would be generated by a conventional
Unicast DNS server; for example, it MUST repeat the query ID and the
question given in the query message. In addition, the cache-flush
bit described in Section 10.2, "Announcements to Flush Outdated Cache
Entries", MUST NOT be set in legacy unicast responses.
kirelagin:
According to [[https://datatracker.ietf.org/doc/html/rfc6762#section-6.7|Section 6.7 of the RFC]], if the query was sent not from port 5353, the responder MUST respond over unicast and, most importantly, to the same port that the query was sent from.
This is what currently prevents
dig -p 5353 @224.0.0.251
from working, since dig is expecting the response on the random port it sent its query from, but umdns, contrary to the specifiation, always sends to port 5353.
The text was updated successfully, but these errors were encountered: