I may be able to answer my own question: If let (datagrams, error) = await flow.readDatagrams() returns no error and no datagrams (i.e. an empty array) I assume the flow should get closed. If I don't close the flow upon a read with empty datagrams (and empty error) I get an endless read loop resulting in high CPU usage, so I assume that the flow should get closed in that case. For most flows this results in a similar behaviour to just calling readDatagrams once, because consecutive calls would result in returning empty Datagrams, but I reckon for some flows it is important to continue reading. @DTS Engineer if closing the flow upon not receiving datagrams is not correct please let me know how to handle the end of lifecycle differently.

This post has been very helpful in understanding the lifecycle of the flows in NEDNSProxyProvider. I had the same issue, that I did not continuously handle datagrams but only open, read, write, close for each flow. I have one follow up question: How does the lifecycle of NEAppProxyFlow end? More specifically, is there any indicator to check on the flow to take a decision to close the flow (like a 0 byte) without an error on closeReadWithError and closeWriteWithError, or should these functions really only be used in error cases?

I dug through some more code and docs; here's some findings: Tech note TN3151: Choosing the right networking API | Apple Developer Documentation still mentions that dns_util is the way to go for handling DNS outside of the system resolver It may be possible to use the NIO based NIODns client https://github.com/orlandos-nl/DNSClient - it includes message decoding but I feel using NIODns is a bit of an overkill for my network extension (at least for now) Given that the tech notes mention to use dns_parse_packet in dns_util I assume it should still be supported. Eskimo, if you come across this post it would be great to get your 2 cents for what is recommended for my use-case.