Ultimately, a comment on this page[1] about Comcast's "SecurityEdge" product helped me, after beating my head against the wall for more than 12 hours over this. I logged into my Comcast Business account, went to my internet service tab, scrolled to the bottom, and disabled the SecurityEdge product that had magically been enabled overnight. Suddenly all of my DNS is working perfectly again. I wasn't doing anything wrong after all. Comcast was. Sigh.
Turns out their SecurityEdge product intercepts ALL DNS requests, even those made directly to authoritative servers, and inserts their own responses, which results in the “pretty nonsensical answers from what should be authoritative servers” that you mentioned. There are not enough curse words in the tongues of man and elf… Thanks for looking at it. Sorry for wasting anyone’s time, but hopefully this mailing list history will help someone in the future. [1] https://community.spiceworks.com/t/comcast-hijacking-dns-request-to-opendns/1016813/2 > On Dec 28, 2024, at 8:31 PM, Doug Freed via Pdns-users > <pdns-users@mailman.powerdns.com> wrote: > >> Here is the PowerDNS Recursor 5.1.3 fail trace for a failed lookup of >> `askubuntu.com`: >> https://gist.github.com/beamerblvd/d8fa24bdf1037e2a670f8e331b7e4905 > > Your trace log is showing some pretty nonsensical answers from what > should be authoritative servers. For one, it queried the root > nameservers for "askubuntu.com A" and got askubuntu.com's delegation, > not com's delegation. Further down, it queried some Cloudflare > nameservers that should be authoritative for askubuntu.com, and > instead got various referrals, some back to com and one back to > askubuntu.com (aka "horizontal referral"). There's a clue as to why > this is happening in your dig output against what should be > authoritative nameservers: > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > > This is missing the aa flag, meaning the response isn't actually from > the nameserver authoritative for the zone, and has the ra flag, > meaning the response is coming from a recursor. The first immediate > thought is that you configured a firewall to capture outbound DNS > queries and redirect them to your recursor, and you failed to exempt > your recursor's own queries from this redirection, so you're just > looping the recursor back on itself. Another possibility is that a > network provider upstream of your network is doing this redirection, > but this is unlikely as Comcast does not do this as far as I know, and > beyond Comcast would be transit providers that definitely don't do > this. > >> The `OPT=15` line with some kind of signature plus `delegation com` is >> interesting. It's not happening on every domain that's failing to resolve, >> so it might be a red herring (and it changes ... like running that same >> query again resulted in `OPT=15: 00 16 64 65 6c 65 67 61 74 69 6f 6e 20 61 >> 73 6b 75 62 75 6e 74 75 2e 63 6f 6d ("..delegation askubuntu.com")`). > > EDNS code 15 is Extended DNS Errors, defined in RFC 8914: > https://datatracker.ietf.org/doc/html/rfc8914 . 0016 is the error code > in hex, which is 22 in decimal, and is defined in the RFC as "No > Reachable Authority" meaning no authoritative nameservers could be > reached at some point in the recursion process, and the text after it > is recursor telling you where it was in the recursion process when it > hit that error. > > Hope this helps you figure out what's going on. > > -Doug > _______________________________________________ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com > https://mailman.powerdns.com/mailman/listinfo/pdns-users _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
