Malformed Nameserver response AAAA records

I am experiencing problems with some of cloudflares DNS servers with AAAA queries for certain domains. An IPv4 lookup works properly (A query) but IPv6 lookup does not work correctly. All tools report malformed message packets (less than the 16 bytes required by the RFC) or fail.
Does anyone else experiencing similar problems? Is it a problem of the DNS entry not properly being validated or even a bug in the DNS software (e.g. not correctly handling "0"s in the IPv6)? Does anyone know what DNS software cloudflare is using for its nameservers?

See examples here: domain: jiong.lanameservers: dan.ns.cloudflare.com and kay.ns.cloudflare.com - Pastebin.com

What’s not working correctly? There’s no AAAA record for those hosts and none is returned.

It does return an answer (see dig response, ANSWER: 1) but the data length is set to 0. If there was no record there should be no answer. (expected behavior can be seen with dig foo.com AAAA @dan.ns.cloudflare.com). So it seems to me that there might be an entry but something is going wrong somewhere.

There other examples of non-cloudflare nameservers also responding with malformed responses but with data length > 0. Maybe this helps in this context:

dig 8l7jko1.work AAAA @ns1.faxdns.net
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.10.6 <<>> 8l7jko1.work AAAA @ns1.faxdns.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42303
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; WARNING: Message has 32 extra bytes at end

;; QUESTION SECTION:
;8l7jko1.work. IN AAAA

;; Query time: 269 msec
;; SERVER: 47.74.31.16#53(47.74.31.16)
;; WHEN: Tue Jun 15 15:55:57 CEST 2021
;; MSG SIZE rcvd: 86

I can’t get an AAAA record from anywhere. So I’m not sure what this has to do with Cloudflare, as that domain’s authoritative name servers are at faxdns.net

That is exactly the problem that you can’t get any AAAA record from anywhere since the response is malformed and it gets discarded by any “normal” DNS tool (both the response from cloudflare and the “external” example from faxdns.net).
BUT: if you look at the raw DNS response packet*, you see that the DNS server actually sends a response containing an ANSWER section, but that this ANSWER section is corrupted. So, what I want to find out is WHY it is corrupted! Is it a problem in the software of the DNS service? Is it a malformed entry in the database/zone file? The fact that there is an ANSWER section in the response tells me either that there must be an AAAA entry for these domains or that the DNS service has a bug. Either way, I want to find the source of the anomaly.

  • you can inspect the raw DNS packet e.g. with the proposed dig command using a tool like wireshark to record the network traffic. DNS packet format is explained here: Domain Name System - Wikipedia and specified for AAA records here: rfc3596

@cs-cf any more ideas after my recent clarifications of the problem? Or does the cloudflare DNS tech team have some explanation?

I have no issues retrieving AAAA records when they exist for my zones when testing despite additional packets on failure being reported by dig. I don’t own any of the hosts in question in this thread and can’t comment on whether or not AAAA records exist for those hosts or not. If you’re a zone owner for one of those domains and know for a fact there’s an AAAA record not being returned. you should open a support ticket for your zone.

1 Like

I am not a owner of any of those domains either, otherwise I guess I would not be asking these questions but change the entry or open a ticket.
I stumbled on these anomalies in the cloudflare DNS service as part of my research in cyber security. As a malformed DNS response which does not conform the RFC in my eyes clearly points out that there is something wrong with either the DNS entry of the given domain or with the DNS service itself, I wanted to point out the problem to the Cloudflare team and help find the problem behind it and improve their data or service.
I hope the cloudflare team acknowledges this and is also willing to see “behind this anomaly”?

I appreciate the feedback, but how have you determined the response is not RFC compliant? What RFC is the response violating?

I’ve passed it along to the DNS team to review however.

1 Like

Thanks for passing it along!
As mentioned above, the response contains an answer section with record type AAAA and according to rfc3596 the data in this case must be 128 bits and thus the data length must be 16 (which is 0 in the case of the example I provide).

@cs-cf do you have any news from the DNS team?

@cs-cf any news? just asking before the topic would be closed

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.