In the examples above I used the +norecurse flag, if I don’t I get a warning telling me that recursion is not supported by the server. I assume this is intentional? However, no recursion should be required to answer the queries in this case.
And, finally, what is the significance of the line saying
The reverse lookup fails because the corresponding domain isn’t delegated to Desec. That’s a Vodafone IP address and a reverse lookup goes to a nameserver operated by Vodafone, not Desec. The Desec nameserver doesn’t know about the subdomain of in-addr.arpa that has the PTR record for that address and refuses to answer queries for which it isn’t authoritative.
Recursion is usually not enabled on authoritative nameservers because these servers know the data for which they are authoritative and you’re not supposed to ask them about anything for which they would have to ask other servers.
Regarding the badcookie response: That’s part of the DNS cookie protocol which is defined in RFC 7873. DNS cookies are a way for DNS clients and servers to reduce the risk and impact of “offpath” attacks, where an attacker spoofs IP addresses.
One big problem for DNS server operators are amplification attacks where an attacker sends a small query that has a big response, but spoofs the source address: The query appears to come from the victim and the server sends the big response to the victim. This way an attacker can avoid appearing in logs, because the queries appear to come from the victim and the unsolicited waste traffic flooding the victim comes from the DNS server. The attack only uses a small amount of the attackers own bandwidth to cause lots of traffic from the DNS server to the victim. Since amplification attacks are easy to do with DNSSEC, because the cryptographic material makes for some big responses, mitigation of these risks is particularly important for operators of DNS servers which offer DNSSEC.
This is an easy attack because DNS usually uses UDP, which has no builtin session mechanism. DNS cookies add a lightweight method to ensure that the client got the response from the server it wanted to talk to and that the server received the query from a client that has received at least one message from the server before. The latter works by sending a server cookie which depends on the client IP address in a response to the client, which the client then sends with its next query. An attacker can’t do that because the responses are sent to the victim’s IP address, so the attacker doesn’t see them.
Obviously the first query can’t contain a server cookie because the server had no chance to send one. If the client appears to support DNS cookies (because it sent a client cookie), the server operator can choose to respond to the query normally with some other precautions, or as in the case of the Desec servers, refuse to answer. In the latter case, the server tells the client that it needs to retry and send further queries with the server cookie that comes with that refusal message. The BADCOOKIE line tells you that that’s what’s happening. It’s DNS cookies working as intended.