momosh

@dmitry-markin @elenaf9 I've left a draft PR that tries to tackle this. So far it's working, but I would love to add more unit test to confirm this new flow....

Hey, yes, I saw it, and @ErakhtinB, thank you for this fix. @elenaf9 While #6096 is an elegant, low-risk patch that resolves the immediate `Identify` symptoms—and could be merged quickly...

@jxs @thomaseizinger Hey guys, can I help with the UDS, if that one is still needed?

@jxs and done! ✅ > hi [@momoshell](https://github.com/momoshell) thanks for the interest... My pleasure! Since I've been using this library in production for a few years now, it's only natural to...

Hey hey, thank you for your responses. After reviewing the proposed changes, I realized something. It might be better not to filter out peers with large TTLs. A more effective...

On the other hand, we're still not solving the essence of this problem. And it seems to me that there might be issues while decoding the `MdnsPacket::new_from_bytes`. But I guess...

> Can you expand on that? Why would a non-malicious peer set a TTL that is large enough to cause an overflow? My initial reaction is that the mDNS protocol...

This is turning into more of a design decision than we expected. We’re seeing two possible paths here: - Discard everything due to an overly aggressive TTL. - Cap the...

> We are using [hickory_proto::Message::from_vec](https://docs.rs/hickory-proto/latest/hickory_proto/op/message/struct.Message.html#method.from_vec) to decode a received packages, so this would be something to discuss at the upstream [hickory-dns](https://github.com/hickory-dns/hickory-dns) repo. Exactly, and this package is still in its...

@dariusc93 @elenaf9 hey hey guys, how should we proceed with this one?