Re: Query failed (timed out)
Chris Thompson wrote: > > Don't hold your breath. Indeed, I put those Barclays nameservers in our noedns list on 2017-07-14 (tho I have also not really tried to get them fixed, despite Barclays being our bank) Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: Northeast veering southeast later, 5 to 7, perhaps gale 8 later. Rough or very rough. Rain or showers. Good, occasionally moderate. ___ 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
Re: Query failed (timed out)
On Nov 7 2019, Wilfred Sarmiento via bind-users wrote: Hope this issue will reach Barclays Domain admin. Don't hold your breath. The problem with these Barclays servers was already being discussed on bind-users back in June, see the thread starting at https://lists.isc.org/pipermail/bind-users/2019-June/101930.html -- Chris Thompson Email: c...@cam.ac.uk ___ 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
Re: Query failed (timed out)
Thank you Ondrej.
Hope this issue will reach Barclays Domain admin.
Thank you all for the help and advise.
On Wed, 6 Nov 2019, 18:50 Ondřej Surý wrote:
> Hi Wilfred,
>
> BIND is not broken as Mark already pointed out, so we have no plan on
> fixing this.
>
> The DNS load-balancers (most probably) that Barclays has deployed need to
> be
> fixed to be RFC compliant.
>
> Not to mention that dropping the queries is always **BAD** as it opens a
> bigger
> window to spoofing attacks for off-path attacker.
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 6 Nov 2019, at 09:18, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> >
> > Hi Mark,
> >
> > The workaround works very well, i also got the same response from Daniel
> of Switch.
> >
> > Thank you very much!
> > Wil
> >
> >
> > On Wed, Nov 6, 2019 at 3:52 PM Mark Andrews wrote:
> > The DNS servers for federate-secure.glbaa.barclays.com are *broken*
> which
> > is what federate.secure.barclays.com points to. They do not respond to
> > queries with EDNS options present and named sends a DNS COOKIE EDNS
> option
> > by default.
> >
> > You can work around this by specifying
> >
> > server 157.83.102.245 { send-cookie no; };
> >
> > and similarly for all the other IP addresses of the GLB but the real fix
> > is for Barclays to deploy RFC compliant DNS servers. Their servers
> nominally
> > support EDNS and unknown EDNS options are supposed to be ignored, not
> cause
> > the query to be dropped.
> >
> > % dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> >
> > ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
> > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;federate-secure.glbaa.barclays.com. IN A
> >
> > ;; ANSWER SECTION:
> > federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
> >
> > ;; Query time: 356 msec
> > ;; SERVER: 157.83.102.245#53(157.83.102.245)
> > ;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
> > ;; MSG SIZE rcvd: 79
> >
> > % dig federate-secure.glbaa.barclays.com @157.83.102.245
> >
> > ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com @157.83.102.245
> > ;; global options: +cmd
> > ;; connection timed out; no servers could be reached
> >
> > [beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com
> +nocookie @157.83.102.245
> >
> > ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
> > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;federate-secure.glbaa.barclays.com. IN A
> >
> > ;; ANSWER SECTION:
> > federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
> >
> > ;; Query time: 383 msec
> > ;; SERVER: 157.83.102.245#53(157.83.102.245)
> > ;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
> > ;; MSG SIZE rcvd: 79
> >
> > %
> >
> >
> > > On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> > >
> > > Hi Bind Users,
> > >
> > > Anyone have a similar issue we are encountering with the subdomain of
> Barclays.com specifically federate.secure.barclays.com
> > > Our cache server could not resolve the said subdomain, but was able to
> resolve their root domain barclays.com and any other known domains.
> > > Debug just showed below little details of logs.
> > > That subdomain was resolvable using Google DNS and other OpenDNS.
> > >
> > > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com):
Re: Query failed (timed out)
Hi Wilfred,
BIND is not broken as Mark already pointed out, so we have no plan on fixing
this.
The DNS load-balancers (most probably) that Barclays has deployed need to be
fixed to be RFC compliant.
Not to mention that dropping the queries is always **BAD** as it opens a bigger
window to spoofing attacks for off-path attacker.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 6 Nov 2019, at 09:18, Wilfred Sarmiento via bind-users
> wrote:
>
> Hi Mark,
>
> The workaround works very well, i also got the same response from Daniel of
> Switch.
>
> Thank you very much!
> Wil
>
>
> On Wed, Nov 6, 2019 at 3:52 PM Mark Andrews wrote:
> The DNS servers for federate-secure.glbaa.barclays.com are *broken* which
> is what federate.secure.barclays.com points to. They do not respond to
> queries with EDNS options present and named sends a DNS COOKIE EDNS option
> by default.
>
> You can work around this by specifying
>
> server 157.83.102.245 { send-cookie no; };
>
> and similarly for all the other IP addresses of the GLB but the real fix
> is for Barclays to deploy RFC compliant DNS servers. Their servers nominally
> support EDNS and unknown EDNS options are supposed to be ignored, not cause
> the query to be dropped.
>
> % dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 356 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
> ;; MSG SIZE rcvd: 79
>
> % dig federate-secure.glbaa.barclays.com @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com @157.83.102.245
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> [beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com +nocookie
> @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 383 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
> ;; MSG SIZE rcvd: 79
>
> %
>
>
> > On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users
> > wrote:
> >
> > Hi Bind Users,
> >
> > Anyone have a similar issue we are encountering with the subdomain of
> > Barclays.com specifically federate.secure.barclays.com
> > Our cache server could not resolve the said subdomain, but was able to
> > resolve their root domain barclays.com and any other known domains.
> > Debug just showed below little details of logs.
> > That subdomain was resolvable using Google DNS and other OpenDNS.
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> > (x.x.x.x)
> > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> > (x.x.x.x)
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> > (x.x.x.x)
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> >
> > Thank you,
> > Wil
> >
> &
Re: Query failed (timed out)
Hi Steinar, Noted and thank you very much. Regards. *Wil* On Wed, Nov 6, 2019 at 4:21 PM wrote: > > The workaround works, does BIND 9.14 has a patch to resolve this? Since > we > > have a multiple Cache server, we need to do this every time we encounter > > another domain that has this same issue. > > There's probably no patch to "resolve" this, because the correct way > to fix the problem is at the source of the problem, typically load > balancers which don't implement DNS correctly. > > You may want to read > > https://www.isc.org/blogs/dns-flag-day-2020/ > https://www.isc.org/blogs/dns-flag-day-was-it-a-success/ > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > -- This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately. ___ 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
Re: Query failed (timed out)
> The workaround works, does BIND 9.14 has a patch to resolve this? Since we > have a multiple Cache server, we need to do this every time we encounter > another domain that has this same issue. There's probably no patch to "resolve" this, because the correct way to fix the problem is at the source of the problem, typically load balancers which don't implement DNS correctly. You may want to read https://www.isc.org/blogs/dns-flag-day-2020/ https://www.isc.org/blogs/dns-flag-day-was-it-a-success/ Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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
Re: Query failed (timed out)
Hi Mark,
The workaround works very well, i also got the same response from Daniel of
Switch.
Thank you very much!
*Wil*
On Wed, Nov 6, 2019 at 3:52 PM Mark Andrews wrote:
> The DNS servers for federate-secure.glbaa.barclays.com are *broken* which
> is what federate.secure.barclays.com points to. They do not respond to
> queries with EDNS options present and named sends a DNS COOKIE EDNS option
> by default.
>
> You can work around this by specifying
>
> server 157.83.102.245 { send-cookie no; };
>
> and similarly for all the other IP addresses of the GLB but the real fix
> is for Barclays to deploy RFC compliant DNS servers. Their servers
> nominally
> support EDNS and unknown EDNS options are supposed to be ignored, not cause
> the query to be dropped.
>
> % dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 356 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
> ;; MSG SIZE rcvd: 79
>
> % dig federate-secure.glbaa.barclays.com @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com @157.83.102.245
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> [beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com
> +nocookie @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 383 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
> ;; MSG SIZE rcvd: 79
>
> %
>
>
> > On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> >
> > Hi Bind Users,
> >
> > Anyone have a similar issue we are encountering with the subdomain of
> Barclays.com specifically federate.secure.barclays.com
> > Our cache server could not resolve the said subdomain, but was able to
> resolve their root domain barclays.com and any other known domains.
> > Debug just showed below little details of logs.
> > That subdomain was resolvable using Google DNS and other OpenDNS.
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query failed (timed out) for
> federate.secure.barclays.com/IN/A at query.c:6786
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query failed (timed out) for
> federate.secure.barclays.com/IN/A at query.c:6786
> >
> > Thank you,
> > Wil
> >
> >
> > This e-mail message (including attachments, if any) is intended for the
> use of the individual or the entity to whom it is addressed and may contain
> information that is privileged, proprietary, confidential and exempt from
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify the sender and delete this E-mail message immediately.
> >
> > _
Re: Query failed (timed out)
Hi Daniel,
The workaround works, does BIND 9.14 has a patch to resolve this? Since we
have a multiple Cache server, we need to do this every time we encounter
another domain that has this same issue.
Thank you!
*Wil*
On Wed, Nov 6, 2019 at 3:50 PM Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:
> federate.secure.barclays.com. is a CNAME pointing to
> federate-secure.glbaa.barclays.com
>
> The authoritative name servers for federate-secure.glbaa.barclays.com
> are broken:
>
> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
> glbaa.barclays.com. 900 IN NS ns21.barclays.com
>
> They only seem to respond to A, queries. Everything else times out.
> Queries with EDNS Cookies (RFC7873) timeout as well.
>
> You should be able to work around this by adding this to named.conf
>
> server 157.83.126.246 { send-cookie false; };
> server 157.83.102.246 { send-cookie false; };
> server 157.83.126.245 { send-cookie false; };
> server 157.83.102.245 { send-cookie false; };
>
> See also
>
> https://ftp.isc.org/isc/bind9/9.14.0/doc/arm/Bv9ARM.ch05.html#server_statement_grammar
>
> Daniel
>
>
> On 06.11.19 08:32, Wilfred Sarmiento via bind-users wrote:
> > Hi Bind Users,
> >
> > Anyone have a similar issue we are encountering with the subdomain of
> > Barclays.com specifically federate.secure.barclays.com
> > <http://federate.secure.barclays.com>
> > Our cache server could not resolve the said subdomain, but was able to
> > resolve their root domain barclays.com <http://barclays.com> and any
> > other known domains.
> > Debug just showed below little details of logs.
> > That subdomain was resolvable using Google DNS and other OpenDNS.
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> > + (x.x.x.x)
> >
> > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> > + (x.x.x.x)
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> >
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> > + (x.x.x.x)
> >
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> >
> >
> > Thank you,
> > *Wil
> > *
> >
> >
> > This e-mail message (including attachments, if any) is intended for the
> > use of the individual or the entity to whom it is addressed and may
> > contain information that is privileged, proprietary, confidential and
> > exempt from disclosure. If you are not the intended recipient, you are
> > notified that any dissemination, distribution or copying of this
> > communication is strictly prohibited. If you have received this
> > communication in error, please notify the sender and delete this E-mail
> > message immediately.
> >
> >
> > ___
> > 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
> >
>
--
This e-mail message (including attachments, if any) is intended for the use
of the individual or the entity to whom it is addressed and may contain
information that is privileged, proprietary, confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and delete this E-mail message immediately.
___
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
Re: Query failed (timed out)
The DNS servers for federate-secure.glbaa.barclays.com are *broken* which
is what federate.secure.barclays.com points to. They do not respond to
queries with EDNS options present and named sends a DNS COOKIE EDNS option
by default.
You can work around this by specifying
server 157.83.102.245 { send-cookie no; };
and similarly for all the other IP addresses of the GLB but the real fix
is for Barclays to deploy RFC compliant DNS servers. Their servers nominally
support EDNS and unknown EDNS options are supposed to be ignored, not cause
the query to be dropped.
% dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;federate-secure.glbaa.barclays.com. IN A
;; ANSWER SECTION:
federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
;; Query time: 356 msec
;; SERVER: 157.83.102.245#53(157.83.102.245)
;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
;; MSG SIZE rcvd: 79
% dig federate-secure.glbaa.barclays.com @157.83.102.245
; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
federate-secure.glbaa.barclays.com @157.83.102.245
;; global options: +cmd
;; connection timed out; no servers could be reached
[beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com +nocookie
@157.83.102.245
; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;federate-secure.glbaa.barclays.com. IN A
;; ANSWER SECTION:
federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
;; Query time: 383 msec
;; SERVER: 157.83.102.245#53(157.83.102.245)
;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
;; MSG SIZE rcvd: 79
%
> On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users
> wrote:
>
> Hi Bind Users,
>
> Anyone have a similar issue we are encountering with the subdomain of
> Barclays.com specifically federate.secure.barclays.com
> Our cache server could not resolve the said subdomain, but was able to
> resolve their root domain barclays.com and any other known domains.
> Debug just showed below little details of logs.
> That subdomain was resolvable using Google DNS and other OpenDNS.
>
> client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
> query: federate.secure.barclays.com IN A + (x.x.x.x)
> client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
> query: federate.secure.barclays.com IN A + (x.x.x.x)
> client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
> query failed (timed out) for federate.secure.barclays.com/IN/A at query.c:6786
> client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
> query: federate.secure.barclays.com IN A + (x.x.x.x)
> client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
> query failed (timed out) for federate.secure.barclays.com/IN/A at query.c:6786
>
> Thank you,
> Wil
>
>
> This e-mail message (including attachments, if any) is intended for the use
> of the individual or the entity to whom it is addressed and may contain
> information that is privileged, proprietary, confidential and exempt from
> disclosure. If you are not the intended recipient, you are notified that any
> dissemination, distribution or copying of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> the sender and delete this E-mail message immediately.
>
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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
Re: Query failed (timed out)
federate.secure.barclays.com. is a CNAME pointing to
federate-secure.glbaa.barclays.com
The authoritative name servers for federate-secure.glbaa.barclays.com
are broken:
glbaa.barclays.com. 900 IN NS ns24.barclays.net.
glbaa.barclays.com. 900 IN NS ns22.barclays.net.
glbaa.barclays.com. 900 IN NS ns23.barclays.com.
glbaa.barclays.com. 900 IN NS ns21.barclays.com
They only seem to respond to A, queries. Everything else times out.
Queries with EDNS Cookies (RFC7873) timeout as well.
You should be able to work around this by adding this to named.conf
server 157.83.126.246 { send-cookie false; };
server 157.83.102.246 { send-cookie false; };
server 157.83.126.245 { send-cookie false; };
server 157.83.102.245 { send-cookie false; };
See also
https://ftp.isc.org/isc/bind9/9.14.0/doc/arm/Bv9ARM.ch05.html#server_statement_grammar
Daniel
On 06.11.19 08:32, Wilfred Sarmiento via bind-users wrote:
> Hi Bind Users,
>
> Anyone have a similar issue we are encountering with the subdomain of
> Barclays.com specifically federate.secure.barclays.com
> <http://federate.secure.barclays.com>
> Our cache server could not resolve the said subdomain, but was able to
> resolve their root domain barclays.com <http://barclays.com> and any
> other known domains.
> Debug just showed below little details of logs.
> That subdomain was resolvable using Google DNS and other OpenDNS.
>
> client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> + (x.x.x.x)
>
> client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852
> (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> + (x.x.x.x)
>
> client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> (federate.secure.barclays.com): query failed (timed out) for
> federate.secure.barclays.com/IN/A at query.c:6786
>
> client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> + (x.x.x.x)
>
> client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> (federate.secure.barclays.com): query failed (timed out) for
> federate.secure.barclays.com/IN/A at query.c:6786
>
>
> Thank you,
> *Wil
> *
>
>
> This e-mail message (including attachments, if any) is intended for the
> use of the individual or the entity to whom it is addressed and may
> contain information that is privileged, proprietary, confidential and
> exempt from disclosure. If you are not the intended recipient, you are
> notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify the sender and delete this E-mail
> message immediately.
>
>
> ___
> 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
Query failed (timed out)
Hi Bind Users, Anyone have a similar issue we are encountering with the subdomain of Barclays.com specifically federate.secure.barclays.com Our cache server could not resolve the said subdomain, but was able to resolve their root domain barclays.com and any other known domains. Debug just showed below little details of logs. That subdomain was resolvable using Google DNS and other OpenDNS. client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com): query: federate.secure.barclays.com IN A + (x.x.x.x) client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com): query: federate.secure.barclays.com IN A + (x.x.x.x) client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com): query failed (timed out) for federate.secure.barclays.com/IN/A at query.c:6786 client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com): query: federate.secure.barclays.com IN A + (x.x.x.x) client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com): query failed (timed out) for federate.secure.barclays.com/IN/A at query.c:6786 Thank you, *Wil* -- This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately. ___ 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
