Gateway DNS Bug?

share.nearpod.com is being blocked.

nearpod.com works fine.

I have created a Custom Allow rule for share.nearpod.com and it’s still being blocked:


The domain resolves using your DoH subdomain and no queries for that domain today other than my test in your logs both of which return an Allow decision. However the target of that record is blocked and so there may be scenarios where the lookup of that target fails as its TTL is shorter than the original record queried. When that happens the explicit query for the blocked record will fail.

1 Like

I’m not using DoH. I’m using IPv4 DNS.

What is the “target of that record?”

Every location has a DoH subdomain associated with it and that is what I used to test.

curl -H 'accept: application/dns-json' 'https://doh-sub-domain.cloudflare-gateway.com/dns-query?name=share.nearpod.com&type=A

If you’re going to set a super restrictive DNS policy it’s useful to be able to understand/troubleshoot how and why a request might fail. DNS can be devilishly complex. You can run the previous command or use another tool to determine the target in this instance.

You mean the CNAME record (custom.bnc.lt) correct?

When a DNS resolver encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name.

If CNAME will always be used in place of the original name, why does share.nearpod.com have both A and CNAME records?

share.nearpod.com is a CNAME record. It points to A records. Ultimately for the simplified purposes of this example the query for a DNS record needs to resolve to an IP address to determine where traffic is supposed to be routed. Any CNAME is ultimately going to resolve to an A record as A records map a host name to an IP address.

Each record has its own associated TTL and the DNS resolver keeps track of record → value for the associated TTL. When a record expires* it queries again to determine the current value(s) for the record.

DNS is simple until it isn’t; the number of corner cases and unexpected or unintended consequences to resolution with a broad number of record types and varied implementations of standards by application and OS is non-trivial.

* nothing in DNS is quite that simple, but close enough for this example.

Here’s another one:

mqtt.rach.io is being blocked even though I have created a Custom Allow for rach.io

The CNAME record for mqtt.rach.io URI is:

a3bmbcwe3hybwy.iot.us-west-2.amazonaws.com

which is listed as Technology so I don’t understand why it’s blocked.

api.rach.io is a URI that is being blocked that doesn’t have a CNAME record.

If I create a Block of the io TLD and create an Allow of rach.io, shouldn’t every subdomain of rach.io be Allowed?

All of your requests for that domain which up until and including 16:03:32 CST were blocked. After that all requests were allowed. So, working as expected?

Where is that blocked? In the last 24 hours your logs show 0 instances of that hostname being blocked. How have you determined that CNAME target is being blocked?

Ya, something is squirrely.

api.rach.io and mqtt.rach.io were both being blocked even though I had created an Allow rule for rach.io.

I created an Allow rule for each subdomain and the requests were no longer blocked. I removed the subdomain Allow rules and the requests are no longer blocked…

I’ve had a rule permitting rach.io for at least two weeks. mqtt.rach.io and api.rach.io were blocked regardless. This evening I made a non-related modification to my policy and mqtt.rach.io and api.rach.io are now being allowed…until Gateway decides to inexplicably start blocking them again.

mqtt.rach.io is still being blocked so I created a DNS (New) rule to allow rach.io and deleted the legacy rule.

Will report back.