TL;DR - UDP is being blocked by the NACL rule. The response you receive from nc is deceptive and I believe, but haven't confirmed, that the 2.01s time is a timeout.
Netcat is stating it sent a packet, which it did. But your NACL is acting as a firewall at Layer 3/4 for the subnet that your EC2 instance is attached to. The packet is being sent from the host but the NACL is blocking it (and dropping it). Because you're using the -z flag, it immediately drops the connection and there is a two-second timeout associated with it. I'm assuming the two seconds is the time out because it's always the return value. (I don't have time to run this down in the source code)
I recreated your NACL in a VPC, and experienced the same result as above including the exact "received" value. But when I try a lookup against that site using dig it times out when the Deny is in place.
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 1.1.1.1:53.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
[root@ip-10-99-0-198 centos]# dig +short @1.1.1.1 www.google.com
;; connection timed out; no servers could be reached
When the Deny is not in place the dig works as expected.
The last tell is if you run an nmap scan on that UDP port you'll get an "open|filtered" response.
Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered.
References
AWS VPC Network ACLs
ncat Man Page
nmap UDP Scan
