Unable to connect to screwfix.com (dns issue)

[#1]

Unless Plusnet have suddenly fixed it, I am suffering from exactly the same problem and seem to have found a simple solution:

On the Hub One go to Advanced Settings -> Broadband -> Dynamic DNS

Toggle the Dynamic DNS switch.

Done.

[#2]

@breslaw - that should have absolutely zero bearing on things. DynamicDNS is a service that alows you to connect to your router/network from the Internet using a hostname that periodically updates so it always points to your broadband IP address (useful for those without static IPs).

It doesn't do anything to change the way your connected devices or router perform DNS lookups.

I suspect your observation is a coincidence.

[#3]

Could someone else with the problem try it. I'm not usually a lucky person 😉

[#4]

@bobpullen I think you're right. After a couple of hours of working, the Screwfix website has gone again. How strange.

[#5]

@bobpullen I've had a response from Screwfix regarding this issue that I raised with them

---

Our IT Team have advised that the issue has been investigated further but there is nothing that can be done from our side to resolve the Plusnet problem.  If Screwfix were to make any updates that have been suggested, it would impact site performance for other customers.

We can only advise that it is a DNS handling error of Plusnet.  Please refer to the Plusnet help pages, regarding resolutions that are advised.

---

and they just refer to this thread which I'd mentioned to them in the first place. So Screwfix are of no help.

IMHO, that's a load of rubbish. Why they've got 20 IP's listed for a single website, god only knows. Have they not heard of a Load Balancer?

Next option.

Does the HubTwo support DNS over TCP? - Given there appears to be no movement in fixing the underlying issue with the firmware, how do we go about getting a HubTwo as a replacement for the inadequate HubOne?

[#6]

Has anyone managed to resolve this issue 

[#7]

I have had emails from Plusnet saying that it is a Screwfix problem and emails from Scewfix saying that they are not changing their system just to placate a few Plusnet users and that it is a Plusnet problem so the short answer to your question is....NO!

[#8]

@daza2001 & @OHIODAN - there are workarounds detailed in previous posts to this thread.

In short (ish): -

1. Enable Plusnet Safeguard, navigate to 'Block Categories', unblock all categories and then save the changes. Reboot your hub once done, or...

2. Configure alternative DNS servers directly on the device you're having problems accessing the site from. You can use public DNS servers like Google's (8.8.8.8 & 8.8.4.4), Cloudflare's (1.1.1.1 & 1.0.0.1) or alternative Plusnet addresses (213.120.234.38 & 213.120.234.42). Instructions for doing this depend on the device you're using, or...

3. I can try making the above change directly on your router. This should work, however it will cause a brief disconect/reconnect to your service and in the unlikely event something unexpected happens, you may need to factory reset your hub to restore service (you really shouldn't, but I'm just covering my own back).

The problem is a combination of different things: -

• The Screwfix website sometimes returns a very large volume of DNS records. Whilst Screwfix are not strictly 'doing anything wrong', it does mean that certain DNS servers/router combos will return a response that is too large for the traditional method of resolving websites to work (this bit is within Screwfix's control)
  
  
• The 'certain DNS servers' referred to above are servers that return some additional information when a device asks them for the location of a website. This is a configuration choice and again, can't really be considered as 'doing anything wrong'. Plusnet's primary DNS servers are configured like this (this bit is within Plusnet's control).
  
  
• When the traditional method of resolving websites cannot be used (beacuse the DNS reply is too big), there is a 'failback' mechanism that DNS clients can use. This is an extended feature of DNS that is not supported by some older routers/modems. This could be seen as 'doing something wrong', but it wasn't particularly unusual years ago (this bit is partially within Plusnet's control but ultimate responsibiity sits with the router vendor)

When all three of the above are true, then it's likely a visitor will have difficulty accessing Screwfix's site. Even if Plusnet 'fix' the bits within their control, it stands to reason that there are other ISP/DNS/router combinations out there that will result in the same thing. Because of this, it could be argued that Screwfix would be wise to reduce the volume of DNS records configured for their site.

[#9]

I've configured my mobile devices to use the custom dns addresses and my Windows devices don't have the problem so I'm alright but who changed what? Not me. My router is one I've always used and it's running the same firmware as always. So did Plusnet or Screwfix make changes/updates/upgrades?
Also, if I wanted to resolve this through a router change which router is Plusnet supplying that definitely works with this recent change or can be modified to comply?

[#10]

Thank you for the update and the comprehensive explanation. I am currently laying on a sun bed in Lanzarote in about 27C . However that puts me about 1200 miles from my router. Luckily I don’t think I will be needing Screwfix in the next few days so will take another look at it when I get home. Thanks again!

[#11]

It is however ironic that I can instantly open up the Screwfix website from my iPhone on a beach using the hotel Wi-Fi when I am over 1200 miles away on a volcanic island in the middle of the ocean but not from my home in the New Forest!!

[#12]

---

@confusedasasnak wrote:
... who changed what? Not me. My router is one I've always used and it's running the same firmware as always. So did Plusnet or Screwfix make changes/updates/upgrades?

---

I suspect Screwfic made a DNS record change. We haven't changed the bits under our control as far as I'm aware.

[#13]

@bobpullen I was able to test this out the other day from a friends that uses TalkTalk, that worked fine.

Output from the dig command:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +noedns www.screwfix.com @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55033
;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.screwfix.com. IN A

;; ANSWER SECTION:
www.screwfix.com. 131 IN CNAME 1467314084df01340a26123dfe2baf36.yottaa.net.
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.123
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.125
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.126
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.88
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.92
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.23
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.181
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.182
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.87
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.177
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.179
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.178
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.91
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.89
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.18
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.90
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.180
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.122
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.124
1467314084df01340a26123dfe2baf36.yottaa.net. 131 IN A 165.254.56.93

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Nov 18 18:57:30 GMT 2022
;; MSG SIZE rcvd: 411

 As you can see no AUTHORITY records are returned and consequently the response is well under the limit of a DNS UDP response. It all fits into a single UDP packet as seen in the tcpdump output:

10:33:45.933512 IP (tos 0x0, ttl 64, id 13616, offset 0, flags [none], proto UDP (17), length 62)
192.168.1.7.43276 > 192.168.1.1.domain: [udp sum ok] 31492+ A? www.screwfix.com. (34)
10:33:45.936626 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 439)
192.168.1.1.domain > 192.168.1.7.43276: [udp sum ok] 31492 q: A? www.screwfix.com. 21/0/0 www.screwfix.com. [8s] CNAME 1467314084df01340a26123dfe2baf36.yottaa.net., 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.18, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.91, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.180, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.178, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.89, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.23, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.124, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.126, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.125, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.88, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.87, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.179, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.177, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.123, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.182, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.122, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.181, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.93, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.92, 1467314084df01340a26123dfe2baf36.yottaa.net. [8s] A 165.254.56.90 (411)

so if you implemented the the "minimal-responses" as I suggested 2 weeks ago this would resolve the issue. And the DNS response would be no different to what TalkTalk provides or Google for that matter in terms of having no AUTHORITY record(s).

There's absolutely no need to be returning the AUTHORITY records in response to a DNS client request.

With this in place it then won't overflow the UDP packet limit requiring a TCP DNS lookup which the PlusNet router does not support.

It's a simple fix that doesn't require messing around with end users settings and changing them one by one.

---

@bobpullen wrote:

---

@confusedasasnak wrote:
... who changed what? Not me. My router is one I've always used and it's running the same firmware as always. So did Plusnet or Screwfix make changes/updates/upgrades?

---

I suspect Screwfic made a DNS record change. We haven't changed the bits under our control as far as I'm aware.

---

And highlighter an issue in the PlusNet supplied router - that it's running really old and outdated firmware that doesn't support DNS over TCP, which is required when the DNS response is over a certain size.

[#14]

@alitster - I appreciate the input, however am fully aware of your suggestions as a potential solution.

At this stage, I have nothing to add beyond what I wrote at the end of this post i.e. we are considering options.

There is other stuff happening in the background that influences a decision. I'm not really prepared to go into detail, suffice to say that you're missing certain parts of the picture.

My point also remains that even if Plusnet make allocations, there is still the potential for other router/ISP/DNS combos to present this problem. That's a quandry for Screwfix's hostmasters though.

[#15]

I've discovered that my in-laws are having the same problem.

My F-i-L initially suspected it was a cunning ploy by my M-i-L to cut down on his tool purchasing habit, but she's not that technically savvy.

I've set his laptop to use Cloudflare's DNS for now, so he can satisfy his addiction that way at least.

@bobpullen Could you make that change directly on their router, if I let you have their username? Or does the request need to come from their account?