On 16/06/19 09:59, Simon Forster wrote:
A very quick check from an iPad showed the host resolving fine from a couple of
different recursives. The local one:
Shared from ISC Dig for iOS
; <<>> DiG 9.13.3 <<>> @192.168.0.10 +dnssec +noqr +multiline
federate-secure.glbaa.barclays.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11792
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 9, ADDITIONAL: 12
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;federate-secure.glbaa.barclays.com. IN A
;; ANSWER SECTION:
federate-secure.glbaa.barclays.com. 30 IN A 157.83.96.50
;; AUTHORITY SECTION:
barclays.com. 440 IN NS ns2.barcap.com.
barclays.com. 440 IN NS a1-71.akam.net.
barclays.com. 440 IN NS a18-65.akam.net.
barclays.com. 440 IN NS ns3.barcap.com.
barclays.com. 440 IN NS a10-66.akam.net.
barclays.com. 440 IN NS a9-66.akam.net.
barclays.com. 440 IN NS ns7.barcap.com.
barclays.com. 440 IN NS a11-67.akam.net.
barclays.com. 440 IN NS a12-64.akam.net.
;; ADDITIONAL SECTION:
ns2.barcap.com. 300 IN A 141.228.196.129
ns3.barcap.com. 282 IN A 146.127.235.2
ns7.barcap.com. 300 IN A 141.228.129.129
a1-71.akam.net. 440 IN A 193.108.91.71
a1-71.akam.net. 440 IN AAAA 2600:1401:2::47
a9-66.akam.net. 440 IN A 184.85.248.66
a9-66.akam.net. 440 IN AAAA 2a02:26f0:117::42
a10-66.akam.net. 440 IN A 96.7.50.66
a11-67.akam.net. 440 IN A 84.53.139.67
a12-64.akam.net. 440 IN A 184.26.160.64
a18-65.akam.net. 440 IN A 95.101.36.65
;; Query time: 21 msec
;; SERVER: 192.168.0.10#53(192.168.0.10)
;; WHEN: Sun Jun 16 09:51:44 BST 2019
;; MSG SIZE rcvd: 472
I guess proper troubleshooting would involve checking what each of the
authoriatatives say. But it’s Sunday and the dogs need a walk.
Thank you for taking the time to look into it. It is possible that I
don't understand the DNS protocol sufficiently, but shouldn't every
subdomain level return a valid NS record?
dig @8.8.8.8 in NS glbaa.barclays.com
; <<>> DiG 9.11.2 <<>> @8.8.8.8 in NS glbaa.barclays.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10986
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;glbaa.barclays.com. IN NS
;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jun 16 11:19:30 BST 2019
;; MSG SIZE rcvd: 47
And yet Google's DNS does manage to solve the full
federate-secure.glbaa.barclays.com somehow
Is something amiss in the Barclays DNS config, and somehow Google
servers manage to cope with it?
:-)
Simon
On 16 Jun 2019, at 09:43, Sebastian Arcus <s.ar...@open-t.co.uk> wrote:
I have discovered Friday that the following domain used by Barclays bank in UK
doesn't resolve properly - but only on some of my servers running Bind:
federate-secure.glbaa.barclays.com
It works on a server with v9.12.3, but it fails on a server with v9.11.0 and
another one with v9.14.2. However, I don't think that the Bind version has
anything to do with it. All servers are recursive servers.
It also resolves fine if I point to Google dns servers.
I've ran tests on the domain above using the MX Toolbox dns checker
(mxtoolbox.com), and it fails with the following errors:
3 ns22.barclays.net 157.83.102.246 TIMED-OUT 518 ms , rcode=NO_DATA
3 ns21.barclays.com 157.83.102.245 TIMED-OUT 509 ms , rcode=NO_DATA
3 ns23.barclays.com 157.83.126.245 TIMED-OUT 504 ms , rcode=NO_DATA
3 ns24.barclays.net 157.83.126.246 TIMED-OUT 517 ms , rcode=NO_DATA
I've had to temporarily disable and bypass the local Bind instance on this
server and point to Google dns, as users couldn't use online banking from
Barclays because of the issue above.
Does anybody have any idea why would it work on some servers and with Google
dns, but not on other servers with Bind? Also, would someone mind trying to
resolve the above domain at their end and see if they get the same errors
please.
Any suggestions appreciated. Thank you.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
