Cloudflare DNS blocking parler.com

I’m getting numerous complains from our users that 1.1.1.1 does not resolve on parler.com.

Can I get an official reason for this? Is Cloudflare DNS blocking parler.com? Resolves fine on 8.8.8.8, 75.75.75.75, etc.

I second the request for a reason, I’ve not been able to resolve parler.com through cloudflare DNS for 3 days now.

This is an issue with parler’s DNSSec: DNSSec Issue with Parler - #4 by mvavrusa

1 Like

I don’t understand. I’m not using DNSSec. My users are not using DNSSec. They are simply sending queries for an A record for parler.com and getting back an error when the same query to Goog dns 8.8.8.8 works. It’s that simple.

That being said, it’s working again. But why is this intermittent in the first place for non DNSSec queries?

If you are the NS administrator for this website your server is responding incorrectly to requests from servers which do DNSSEC validation.

Yes they are. Cloudflare’s 1.1.1.1 is a DNSSEC validating resolver.

The linked article @Judge posted shows exactly why they are getting an error when the authoritative DNS server is unable to serve a valid query.

I’d review the logs on the authoritative DNS server to determine why it’s truncating the responses.

My DNSSec knowledge is limited, so apologies of I’m not grasping the kerfuffle on DNSSec being wonky.

I’m looking at this from the inside out. Why is that GooG and everyone else is able to resolve on this query but not 1.1.1.1? I expect parity with “the rest of the world” here, sans some reason to block.

It’s not being blocked. The server sends a truncated response to the initial UDP based query which necessitates the query be done again over TCP and then refuses / times out when the request is performed over TCP.

That’s the outside in view. The inside out view would necessitate reviewing your DNS / firewall server logs to determine why it is refusing TCP connections on port 53.

Thanks for bearing with me while we ramp up on this DNSSec issue, or so it may be.

Allow me if you will, to play devils advocate, and I’m sure other readers will appreciate it.

  • Why then, can Goog, Comcast, Cox, etc return a usable response, while CF cannot?
  • Why then, is it now working, or it may be intermittent?

Cloudflare is a DNSSEC validating resolver. Most other resolvers are not. Of the resolvers that are, some take various level of stringency with their approach to interpreting failure / adding exceptions. Per the other thread we’ve tried to reach out to the contact email for the domain as specified in the SOA, so you might review your mail.

As to why it now works but didn’t previously… again, you should probably review your DNS server’s logs. I could speculate as to any number of reasons this can occur. It isn’t uncommon. But your logs should tell you exactly why.

The issue here isn’t one of DNSSEC per se. It is that the question asked via UDP returns a response requires asking again via TCP. That subsequent TCP query is refused.

Loads fine for me, what’s the error code your getting?

Ok - That is a breakaway from “Judge’s” response. Right now, it’s difficult to troubleshoot retroactively as it is now working. But now that the car is in the shop, it is not making that noise.

I guess we will keep an eye on it and try to catch it in the act.

Thanks for your input.

Because they are probably not using DNSSec but simple DNS queries to do DNS resolution.

  • Google supports DNSSec.
  • A faulty or incomplete DNSSec config should not cause a non-DNSSec (simple DNS) query to fail, or do you think it should?