dspruell-i01
commented
7 months ago Occurrence today:
% as-lookup 185.119.196.207
185.119.196.207 Error in lookup from service cymru for IP 185.119.196.207 (origin_data response: v=spf1 mx -all)When I look at DNS resolution activity on the host encountering this, I see the unexpected response coming back from the DNS resolver:
tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
00:00:00.000000 xx:xx:xx:xx:xx:4e > xx:xx:xx:xx:xx:32, ethertype IPv4 (0x0800), length 96: (tos 0x0, ttl 64, id 14587, offset 0, flags [none], proto UDP (17), length 82)
x.x.6.24.62927 > 9.9.9.9.53: [udp sum ok] 50030+ TXT? 207.196.119.185.origin.asn.cymru.com. (54)
00:00:00.032499 xx:xx:xx:xx:xx:32 > xx:xx:xx:xx:xx:4e, ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 59, id 62824, offset 0, flags [none], proto UDP (17), length 126)
9.9.9.9.53 > x.x.6.24.62927: [udp sum ok] 50030 NXDomain q: TXT? 207.196.119.185.origin.asn.cymru.com. 0/1/0 ns: asn.cymru.com. [13m14s] SOA ns1.asn.cymru.com. noc.cymru.com. 1707872446 1800 900 86400 900 (98)
00:00:00.001135 xx:xx:xx:xx:xx:4e > xx:xx:xx:xx:xx:32, ethertype IPv4 (0x0800), length 116: (tos 0x0, ttl 64, id 41609, offset 0, flags [none], proto UDP (17), length 102)
x.x.6.24.65313 > 9.9.9.9.53: [udp sum ok] 6715+ TXT? 207.196.119.185.origin.asn.cymru.com.example.net. (74)
00:00:00.039696 xx:xx:xx:xx:xx:32 > xx:xx:xx:xx:xx:4e, ethertype IPv4 (0x0800), length 143: (tos 0x0, ttl 59, id 62840, offset 0, flags [none], proto UDP (17), length 129)
9.9.9.9.53 > x.x.6.24.65313: [udp sum ok] 6715 q: TXT? 207.196.119.185.origin.asn.cymru.com.example.net. 1/0/0 207.196.119.185.origin.asn.cymru.com.example.net. [1h58m15s] TXT "v=spf1 mx -all" (101)The last couple of packets show what seems to be happening: the query returned no answer, and so the stub resolver on the client retried the query with a suffix configured on the client (shown here as "example.net"), which resulted in the TXT SPF record for that domain suffix being returned as the answer.
It's not clear why in some cases the response for the query in Team Cymru's zone results in no response (perhaps NXDOMAIN), and it's not clear if this only occurs with Quad9 resolvers when it occurs; it appears that querying other DNS resolvers does result in a proper answer.
Sometimes, lookups of IP addresses using Team Cymru's service results in an error; examples:
There appears to be inconsistency to the behavior; as noted above, two lookups involving the IP 37.128.207.56 were inconsistent, returning IP-BGP data the first time but resulting in the error the second time.
To further complicate things, sometimes after messing around with resolutions against caching resolvers manually, something changes and IP-BGP data resolves cleanly: