Returning odd DNS packets since May 25

I seem to be getting RFC violating packets back from 1.1.1.1 and 1.0.0.1 about once every 10 requests or so. I’ve tested this against other name servers and in other datacenters and had no such issue. The request is for aol . com MX

For debugging, here is the data structure of the return:

DNS: Sending query for aol . com type MX to 1.0.0.1
DNS: Reading socket query
array(6) {
[“id”]=>
int(47695)
[“qdcount”]=>
int(1)
[“ancount”]=>
int(1)
[“nscount”]=>
int(0)
[“arcount”]=>
int(0)
[“decoded”]=>
array(8) {
[“rcode”]=>
int(0)
[“z”]=>
int(0)
[“ra”]=>
int(1)
[“rd”]=>
int(1)
[“tc”]=>
int(0)
[“aa”]=>
int(0)
[“opcode”]=>
int(0)
[“type”]=>
int(1)
}
}
array(1) {
[0]=>
array(5) {
[“header”]=>
array(4) {
[“type”]=>
int(867)
[“class”]=>
int(28525)
[“ttl”]=>
int(3840)
[“length”]=>
int(256)
}
[“typeid”]=>
bool(false)
[“data”]=>
string(0) “”
[“host”]=>
string(7) “aol . com”
[“extras”]=>
array(0) {
}
}
}

The record type of 867 and class of 28525 shouldn’t be possible. The offending record always seems to be the same. This all started happening on Saturday May 25. No packet loss is occuring between the host and Cloudflare. SYD and SJC have the same issue.

Hi @james139, can you still see the issue? I was not able to reproduce it, but we rolled back a version of our dns library that seems to have issue with compression, it’s possibly related but not sure if it could confuse your message parser like this.

Awesome, it looks like it’s working now post rollback

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