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.

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 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.