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): 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, co
Re: CNAME as an alias to a TXT record
Many thanks for all the responses. For the sake of completeness I am just reporting that every thing is working as expected. On 2019-11-04 12:30 p.m., Computerisms Corporation wrote: Hi, I am wondering if it is possible to create a CNAME in one zone to resolve as a TXT record in another zone. Can't find anything that says it will work, but can't find any thing that says it won't, either. For example, I have added in the zone file for dom1: _acme-challenge CNAME _acme-challenge.dom2.com. and then in zone file for dom2: _acme-challenge TXT "thisismytextvalue" Then, and more or less as expected, the following dig command fails to return a record. dig -t TXT _acme-challenge.dom1.com Is there a way to get the dig command to return the TXT value for dom2? Or is that something that can pretty much only happen with A records? ___ 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: CNAME as an alias to a TXT record
In article , Computerisms Corporation wrote: > Hi, > > I am wondering if it is possible to create a CNAME in one zone to > resolve as a TXT record in another zone. Can't find anything that says > it will work, but can't find any thing that says it won't, either. CNAME isn't type-specific. It simply makes one name an alias for another name. If the target name has a TXT record, then you'll get that when you look up TXT for the CNAME. -- Barry Margolin Arlington, MA ___ 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 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
> >
> >
> > 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: CNAME as an alias to a TXT record
On 04.11.19 12:30, Computerisms Corporation wrote: I am wondering if it is possible to create a CNAME in one zone to resolve as a TXT record in another zone. On 06.11.19 09:48, Matus UHLAR - fantomas wrote: CNAME will not resolve as a TXT. CNAME will make ALL types queries for original query being resolved as the destination FYI you can try querying cname-example.fantomas.sk: % dig +noall +answer any cname-example.fantomas.sk. cname-example.fantomas.sk. 43200 IN CNAME cname-dest.fantomas.sk. % dig +noall +answer txt cname-example.fantomas.sk. cname-example.fantomas.sk. 43200 IN CNAME cname-dest.fantomas.sk. cname-dest.fantomas.sk. 43200 IN TXT "this is an example of how CNAME works" % dig +noall +answer mx cname-example.fantomas.sk. cname-example.fantomas.sk. 43200 IN CNAME cname-dest.fantomas.sk. cname-dest.fantomas.sk. 43200 IN MX 10 cname-dest.fantomas.sk. % dig +noall +answer a cname-example.fantomas.sk. cname-example.fantomas.sk. 43200 IN CNAME cname-dest.fantomas.sk. cname-dest.fantomas.sk. 43200 IN A 127.0.0.1 Can't find anything that says it will work, but can't find any thing that says it won't, either. For example, I have added in the zone file for dom1: _acme-challenge CNAME _acme-challenge.dom2.com. and then in zone file for dom2: _acme-challenge TXT "thisismytextvalue" Then, and more or less as expected, the following dig command fails to return a record. dig -t TXT _acme-challenge.dom1.com is is supposed to work this way. If it doesn't, you have an error somewhere. Are you sure that there's no other _acme-challenge.dom1.com record than the CNAME? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Holmes, what kind of school did you study to be a detective? - Elementary, Watkins. -- Daffy Duck & Porky Pig ___ 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: CNAME as an alias to a TXT record
On 04.11.19 12:30, Computerisms Corporation wrote: I am wondering if it is possible to create a CNAME in one zone to resolve as a TXT record in another zone. CNAME will not resolve as a TXT. CNAME will make ALL types queries for original query being resolved as the destination Can't find anything that says it will work, but can't find any thing that says it won't, either. For example, I have added in the zone file for dom1: _acme-challenge CNAME _acme-challenge.dom2.com. and then in zone file for dom2: _acme-challenge TXT "thisismytextvalue" Then, and more or less as expected, the following dig command fails to return a record. dig -t TXT _acme-challenge.dom1.com is is supposed to work this way. If it doesn't, you have an error somewhere. Are you sure that there's no other _acme-challenge.dom1.com record than the CNAME? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. (R)etry, (A)bort, (C)ancer ___ 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 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.
> >
> > ___
> > 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
>
>
--
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
Re: bind-users Digest, Vol 3297, Issue 1
Dear Wil, Your email was fascinating. Thank you Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, November 6, 2019 3:15 AM, wrote: > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > > Today's Topics: > > 1. Query failed (timed out) (Wilfred Sarmiento) > 2. Re: Query failed (timed out) (Daniel Stirnimann) > 3. Re: Query failed (timed out) (Mark Andrews) > 4. Re: Query failed (timed out) (Wilfred Sarmiento) > > > Message: 1 > Date: Wed, 6 Nov 2019 15:32:48 +0800 > From: Wilfred Sarmiento wpsarmie...@globe.com.ph > To: bind-users@lists.isc.org > Subject: Query failed (timed out) > Message-ID: > caclugzt37g_8bjynyg-ye+u8ucqyuvhcbpvyoxmwsyatiqe...@mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > 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. > > -- next part -- > An HTML attachment was scrubbed... > URL: > https://lists.isc.org/pipermail/bind-users/attachments/20191106/7228a0d3/attachment-0001.htm > > -- > > Message: 2 > Date: Wed, 6 Nov 2019 08:50:31 +0100 > From: Daniel Stirnimann daniel.stirnim...@switch.ch > To: Wilfred Sarmiento wpsarmie...@globe.com.ph, > > > > > Subject: Re: Query failed (timed out) > Message-ID: 4a60fcf1-58b5-bda2-f8e1-56b67c9e4...@switch.ch > Content-Type: text/plain; charset="utf-8" > > federate.secure.barclays.com. is a CNAME pointing to > federate-secure.glbaa.barclays.com > > The aut
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
> >
> > 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
> >
>
--
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
