I have seen that Sky Broadband Consumer service has an intercept layer for all DNS queries which can result in stale data problems when servers change IP addresses. Also DNS queries pointed towards nonexistent DNS server will still succeed but may provide old or incorrect data.
Using the Google dig tool on
https://toolbox.googleapps.com/apps/dig/
Gives the correct result but the local Sky Broadband command line equivalent look up that is supposed to be using Goggle DNS server ....
% dig @8.8.8.8 domainname.com MX
Gives a stale out of date answer hours after the result should have changed.
Given a non-existant DNS server with an address similar to Googles connection is not possible
% ping 8.8.8.99
PING 8.8.8.99 (8.8.8.99): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
but DNS look up succeeds
% date; dig @8.8.8.99 apple.com MX
Mon 2 May 2022 14:29:38 BST
; <<>> DiG 9.10.6 <<>> @8.8.8.99 apple.com MX
; (1 server found)
;; global options: +cmd
......snip;; ANSWER SECTION:
apple.com. 3600 IN MX 10 rn-mailsvcp-ppex-lapp15.apple.com.
apple.com. 3600 IN MX 10 rn-mailsvcp-ppex-lapp24.apple.com.
apple.com. 3600 IN MX 10 rn-mailsvcp-ppex-lapp34.apple.com.
apple.com. 3600 IN MX 10 rn-mailsvcp-ppex-lapp35.apple.com.
apple.com. 3600 IN MX 10 rn-mailsvcp-ppex-lapp44.apple.com.
apple.com. 3600 IN MX 10 rn-mailsvcp-ppex-lapp45.apple.com.
apple.com. 3600 IN MX 10 ma1-aaemail-dr-lapp01.apple.com.
.......
Gets you an answer. How is this possible or correct ????
This has the follow on implications :
1) DNS lookup results can be stale or incorrect hours after a change at source.
2) Changing the DNS settings on your PC/Device makes no difference as the "Sky Results" are used in any case.
3) All DNS lookups can be recorded / traced at the ISP level.
4) Time to live should be set low on domains that are going to change, then reset after the change has propagated to a longer time, to avoid excessive lookups. This would also avoid any excuse by Sky for keeping stale data when no-one else does.
5) DNS interception by Sky Broadband could be considered a man-in-the middle compromise of the correct functioning of the DNS system.
6) Of the 6 failures ( lasting over 5 minutes ) of Sky consumer broadband that I have experienced and investigated over the last few years, 3 have been wire to the house failures and 3 have been DNS service failures. The DNS service was designed to be failure resilient by using recursive lookups to higher domains but if all queries are intercepted by an intermediary and that intermediary has a problem the robustness of DNS is compromised.
Only solutions are to use external tools to check against Sky DNS results. Or use a VPN. Not sure if other consumer ISPs have this configuration. A colleague doing the exact same look ups on another ISP server did not see the delay in the domain data being updated.
