Can't access a particular subdomain of gouv.qc.ca

Hi everyone,

I can’t access siaf.gouv.qc.ca when using 1.1.1.1. It works perfectly with other DNS or cellular.

It’s quite annoying as this is a governmental agency website.

Following the indications on this page(https://community.cloudflare.com/t/have-problems-with-1-1-1-1-read-me-first/15902), here’s what I’m finding:

❯ nslookup siaf.gouv.qc.ca 8.8.8.8 
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	siaf.gouv.qc.ca
Address: 173.242.179.134


~ 
❯ nslookup siaf.gouv.qc.ca        
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
*** Can't find siaf.gouv.qc.ca: No answer


~ 
❯ dig siaf.gouv.qc.cq @1.1.1.1

; <<>> DiG 9.10.6 <<>> siaf.gouv.qc.cq @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55221
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;siaf.gouv.qc.cq.		IN	A

;; AUTHORITY SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2022101700 1800 900 604800 86400

;; Query time: 29 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 17 09:32:01 EDT 2022
;; MSG SIZE  rcvd: 119


~ 
❯ dig siaf.gouv.qc.cq @8.8.8.8

; <<>> DiG 9.10.6 <<>> siaf.gouv.qc.cq @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31570
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;siaf.gouv.qc.cq.		IN	A

;; AUTHORITY SECTION:
.			86080	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2022101700 1800 900 604800 86400

;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct 17 09:32:19 EDT 2022
;; MSG SIZE  rcvd: 119

and

❯ dig +short CHAOS TXT id.server @1.1.1.1
dig +short CHAOS TXT id.server @1.0.0.1
"YUL"
"YUL"

Here’s also the debugging URL https://1.1.1.1/help#eyJpc0NmIjoiWWVzIiwiaXNEb3QiOiJObyIsImlzRG9oIjoiWWVzIiwicmVzb2x2ZXJJcC0xLjEuMS4xIjoiWWVzIiwicmVzb2x2ZXJJcC0xLjAuMC4xIjoiWWVzIiwicmVzb2x2ZXJJcC0yNjA2OjQ3MDA6NDcwMDo6MTExMSI6Ik5vIiwicmVzb2x2ZXJJcC0yNjA2OjQ3MDA6NDcwMDo6MTAwMSI6Ik5vIiwiZGF0YWNlbnRlckxvY2F0aW9uIjoiWVVMIiwiaXNXYXJwIjoiTm8iLCJpc3BOYW1lIjoiQ2xvdWRmbGFyZSIsImlzcEFzbiI6IjEzMzM1In0=

And the DNSviz

Other subdomains for gouv.qc.ca do work fine.

Any idea what could be happening? And how to fix it?

Thanks in advance,

tl;dr: They need to fix their DNS.

If you can get through to their hostmaster or someone on their technical team feel free to point them to this post, or copy any information from here as appropriate.


When you ask for information about siaf.gouv.qc.ca we get three authoritative servers which all give the same answer, a delegation to the next set of servers, so this is good so far:

dns3.gouv.qc.ca. / dns1.gouv.qc.ca. / dns2.gouv.qc.ca.)

Zone TTL Record IN Value
siaf.gouv.qc.ca. 14400 NS IN dns1.gouv.qc.ca.
siaf.gouv.qc.ca. 14400 NS IN dns1.msp.gouv.qc.ca.

The next step is to ask those servers:

dns1.msp.gouv.qc.ca

Zone TTL Record IN Value
siaf.gouv.qc.ca. 3600 IN A 173.242.179.134
siaf.gouv.qc.ca. 14400 IN NS dns1.msp.gouv.qc.ca.
siaf.gouv.qc.ca. 14400 IN NS dns1.gouv.qc.ca.

Here we get a good answer, the A record we want, plus the NS records (which can be ignored here).

dns1.gouv.qc.ca.

Zone TTL Record IN Value
siaf.gouv.qc.ca. 14400 IN NS dns1.msp.gouv.qc.ca.
siaf.gouv.qc.ca. 14400 IN NS dns1.gouv.qc.ca.

This is a misconfiguration, there are only NS records but no actual answer which will get recognized as a bad delegation – We’ve been told to ask this server, but instead of giving an answer it just gives us NS records which is a lame delegation or a horizontal referral.

It will be luck which gets returned, but as the real result is cached longer than the error result, once a resolver grabs the valid answer it’ll hold on to it for a while, so this configuration will appear to work more often than not, but it’ll be inconsistent.

The fix is to have the zone added to dns1.gouv.qc.ca. so that it can provide the requested information.

Yes and no. Yes, they should fix their DNS at qc.ca, but if Cloudflare is the only public DNS that does not resolve this domain, Cloudflare should also check it out themselves why:

[email protected] (Google)
173.242.179.134
[email protected] (AdGuard (CY))
173.242.179.134
[email protected] (AT&T (US))
173.242.179.134
[email protected] (Cloudflare)

[email protected] (Comodo (US))
173.242.179.134
[email protected] (Google)
173.242.179.134
[email protected] (HiNet (TW))
173.242.179.134
[email protected] (OpenDNS)
173.242.179.134
[email protected] (Quad9)
173.242.179.134
[email protected] (Securolytics (CA))
173.242.179.134
[email protected] (UUNET (CH))
173.242.179.134
[email protected] (UUNET (DE))
173.242.179.134
[email protected] (UUNET (UK))
173.242.179.134
[email protected] (UUNET (US))
173.242.179.134
[email protected] (Verisign (US))
173.242.179.134
[email protected] (Yandex (RU))
173.242.179.134

If they have a general DNS issue, then it should not matter if others may accept a broken configuration or not. A broken configuration is broken and needs to be fixed, not “worked around”.

Cloudflare has an extensive retry mechanism, more extensive than Google’s (who only retries 1 time max), so I don’t understand why this wouldn’t be caught by Cloudflare.

The actual issue still appears to be with the domain however.

Because the domain is broken. It will resolve intermittently (and once it does resolve, thanks to TTLs it’ll tend to continue to resolve for a while). As of this moment Cloudflare (SEA) is resolving it, Comodo is not, and I think it was OpenDNS that also wasn’t resolving it last time I looked – But again, it is intermittent, across widely distributed anycast networks.

Alice: "I dunno, ask Bob or Charles, they work there."
me: "Hey Bob, what time does the bar close?"
Bob: "I dunno. Ask Bob."
me: "Hey Bob, what time does the bar close?"
Bob: "I dunno. Ask Bob."
me: "Hey Bob, what time does the bar close?"
Bob: "I dunno. Ask Bob."
<...>

At some point, you need to sit Bob down and give him the hours, or stop sending people to Bob with this question.

Hi everyone,

Thanks for your insights (particularly @thedaveCA’s—TIL!)

I forwarded this thread to the contact email of the agency. Got a half-automated answer saying “if you’re having trouble accessing the site, please call XXX”. Unsure if my report will actually be handled or if change will result from this.

Is there a workaround for this that I can implement on my end?

I do agree with you that it’s not best practice to work around a root issue that should be addressed—but at the same time, it’s quite inconvenient to not be able to access a site on my network (as I use 1.1.1.1 on all devices).

Thanks,

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.