I also haven't fully groked this to be fair, but my understanding is: (1) Alice and Bob both connect to coordination server (2) Alice sets Bob's endpoint to b

I also haven't fully groked this to be fair, but my understanding is: (1) Alice and Bob both connect to coordination server (2) Alice sets Bob's endpoint to bob_ip:bob_port (3) Bob sets Alice's endpoint to alice_ip:alice_port (4) Both try to ping each other, which makes both of them originate outbound packets from the wireguard socket. IF Alice and Bob have the same public IP:port pair in their NAT with each other as they do with the coordination server (which turns out to be true in tests on my EdgeRouter X NAT, but certainly isn't true 100% of the time), then I believe this process will result in a working connection. If you're asking how Bob & Alice know that the information in the coordination server has changed and that they need to reconfig their endpoints, then I'm not sure. Perhaps they could just re-query the coordination server on a timeout or whenever their connection went down. I agree - using DNS as a transport seems orthogonal to the NAT punching process, and maybe too clever. If you're going to need to write custom endpoint code either way, I don't see a huge advantage. If wireguard supported DNS-based endpoint information by default (automatically re-resolving IP and detecting port from SRV), then it'd make a lot more sense.