UDP is by definition a connection-less protocol. By definition, at the system level, the sender cares only about sending, and not acknowledging reception. So into what touches the sender, as long it was able to dispatch the UDP packet, it was successful.
There are no guarantees whatsoever the receiver will receive all those packets, because of possible congestion/errors, or in the order they were sent, because of multiple factors, including multiple path routing, and varying degrees of congestion.
The buffer has also limited sizes, and if the packets overrun the buffer, they will be lost too.
To answer at your answer, dealing with a protocol that is not oriented to the connection, looking at a packet drop conter of 0, at the system level, done only in one side of the connection, either the sender or the receiver, or even at both sides, does not tell the whole picture.
So, whilst the stats reflect dropped packets from buffers, they won't account for all packets lost in transmission.
You may want to look at the number of packets send and received in addition to that, in both sizes.
Going to upper layer, namely at the application level, namely DNS or NTP, for instance, there can be additional controls to get more meaningful stats of the service.
From UDP - Wikipedia
UDP uses a simple connectionless transmission model with a minimum of
protocol mechanism. It has no handshaking dialogues, and thus exposes
the user's program to any unreliability of the underlying network
protocol. There is no guarantee of delivery, ordering, or duplicate
protection. UDP provides checksums for data integrity, and port
numbers for addressing different functions at the source and
destination of the datagram.
Relate thread in stack overflow How to monitor Linux UDP buffer available space?