Camect DNS Issue?

[Yoonoo]

Looks like starting sometime today (Feb 11 2026), I'm no longer able to access my Camect instance using local URL https://*********.l.home.camect.com . The DNS comes back as not found so this is preventing local integrations from working.

DNS Delegation Chain:
- camect.com → ns-cloud-c1.googledomains.com (and c2, c3, c4)
- home.camect.com → ns-cloud-e1.googledomains.com (and e2, e3, e4)
- l.home.camect.com → dns.home.camect.com (35.202.229.234)

Result: No A or AAAA records were returned for *********.l.home.camect.com. The authoritative server at 35.202.229.234 has no address records for this hostname. This was
  confirmed by querying both the authoritative nameserver directly and Google Public DNS (8.8.8.8).

[Fester Adams]

A "me too" on this one...

[Fester Adams]

Just tried a re-boot of the Camect and that seemed to fix the could not connect problem.

On Wednesday, February 11, 2026 at 6:28:35 PM UTC-5 Yoonoo wrote:

[Arup Mukherjee]

Can you guys share what you're using that relies on *.l.home.camect.com?  At times we're sometimes seeing unreasonably high numbers of resolution requests for some of these hostnames, and are wondering if there can be a legit use case that accounts for it.  Thanks! 

[Matt Burgoon]

For camect: Yeah, it seems as though the server for dns.home.camect.com sometimes becomes unresponsive, IP is currently 35.202.229.234. This IP doesn't seem to be responding to DNS at times, right now I'm sending packets but getting nothing back.

--
You received this message because you are subscribed to the Google Groups "Camect User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@camect.com.
To view this discussion visit https://groups.google.com/a/camect.com/d/msgid/forum/34b394e1-9ee8-40da-92e7-523109e1db9cn%40camect.com.

[Yoonoo]

I'm using the URL to set the operation mode from my local Hubitat instance, so that it changes when I arm/disarm my security system:

debugCamect Connect: sendCommand: Endpoint: https://*********.l.home.camect.com:443 PATH: /api/SetOperationMode PARAMS: [Mode:HOME]
errorerror: java.net.UnknownHostException:  *********.l.home.camect.com: No address associated with hostname [uri:https://*********.l.home.camect.com:443, path:/api/SetOperationMode, headers:[Authorization:Basic *************************==], contentType:application/json, query:[Mode:HOME]]

[CamectArup]

I doubt that it's unresponsive, but rather it's sometimes returning an empty result? When that happens, you can force your hub to update the cloud by restarting, and the need to do this will be removed in a future update. 

However, if your application can use camect.local (which requires mdns support and that you have no more than one camect hub on the network) you're better off using it as it has no external dependencies on our cloud. 

If you cannot use camect.local, let us know what you're using with l.home.camect.com.  As I mentioned, some people are running applications that make unreasonable numbers of resolution requests, and we are trying to understand what is going on with those. We also need to know what legit usage the service is getting. The case that Yoonoo mentioned (hubitat integration) is a perfectly fine use case although camect.local would still be recommended if it works. 

[Arup Mukherjee]

When were you doing it, and can you still reproduce the problem? Also, have you checked to see if it starts responding if you restart your hub? 

[Matt Burgoon]

Interesting. This service sends an "what is your current ip?" query over the connection that the hub makes when receiving a dns request?

In short, rebooted the hub, I get back a dns response now (though only UDP, when dig tries tcp that times out, guessing this dns server only supports udp.)

temporal(schwartz):~$ dig +notcp -t any xxxxx.l.home.camect.com @35.202.229.234

xxxxxx.l.home.camect.com. 60 IN      A       10.1.1.15

I'm sure you guys know how to make this more resilient, so I won't barrage you with any ideas.