Problem resolving a domain
Hi,
at work, I have a problem resolving the following domain:
myapplication.international.barclays.com
BIND 9.16.27, FreeBSD 12.3-P5.
2022Q2 ports.
I copied the config to a VM at home - but it did not work there, either.
I believe it must have happened on the update from BIND 9.16.26 to 9.16.27.
options {
directory "/usr/local/etc/namedb/working";
pid-file"/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
allow-recursion {"rec";};
allow-query-cache { localhost; "rec" ; };
// CIS recommended:
// serverid none;
// dnssec-enable yes;
// dnssec-validation auto;
// dnssec-accept-expired no;
listen-on { 192.168.1.61; };
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
};
acl rec {
127.0.0.0/8;
192.168.1.0/24;
::1;
};
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
zone "localhost"{ type master; file
"/usr/local/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// RFC 1912-style zone for IPv6 localhost address (RFC 6303)
zone "0.ip6.arpa" { type master; file
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
// "This" Network (RFCs 1912, 5735 and 6303)
zone "0.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// Private Use Networks (RFCs 1918, 5735 and 6303)
zone "10.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// Shared Address Space (RFC 6598)
zone "64.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "65.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "66.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "67.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "68.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "69.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "70.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "71.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "72.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "73.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "74.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "75.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "76.100.in-addr.arpa" { type
Re: Problem resolving a domain
Hi Rainer,
I believe this is unrelated to any upgrade. The nameservers for the domain are
broken:
$ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
myapplication.international.barclays.com @ns2.barcap.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
;; QUESTION SECTION:
;myapplication.international.barclays.com. IN A
;; ANSWER SECTION:
myapplication.international.barclays.com. 900 IN CNAME
myapplication.glbaa.barclays.com.
;; AUTHORITY SECTION:
glbaa.barclays.com. 900 IN NS ns22.barclays.net.
glbaa.barclays.com. 900 IN NS ns21.barclays.com.
glbaa.barclays.com. 900 IN NS ns24.barclays.net.
glbaa.barclays.com. 900 IN NS ns23.barclays.com.
;; ADDITIONAL SECTION:
ns21.barclays.com. 900 IN A 157.83.102.245
ns23.barclays.com. 900 IN A 157.83.126.245
ns22.barclays.net. 600 IN A 157.83.102.246
ns24.barclays.net. 600 IN A 157.83.126.246
;; Query time: 196 msec
;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
;; WHEN: Fri May 13 14:08:49 CEST 2022
;; MSG SIZE rcvd: 283
and the nameservers itself just timeout:
$ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.
; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> +timeout
+retries IN A myapplication.glbaa.barclays.com. @ns21.barclays.com.
;; global options: +cmd
;; connection timed out; no servers could be reached
DNSVIZ gives the same result:
https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
• glbaa.barclays.com zone: The server(s) were not responsive to queries
over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245, 157.83.126.246)
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 13. 5. 2022, at 13:54, Rainer Duffner wrote:
>
> Hi,
>
> at work, I have a problem resolving the following domain:
>
> myapplication.international.barclays.com
>
>
> BIND 9.16.27, FreeBSD 12.3-P5.
> 2022Q2 ports.
>
>
> I copied the config to a VM at home - but it did not work there, either.
>
> I believe it must have happened on the update from BIND 9.16.26 to 9.16.27.
>
>
> options {
>directory "/usr/local/etc/namedb/working";
>pid-file"/var/run/named/pid";
>dump-file "/var/dump/named_dump.db";
>statistics-file "/var/stats/named.stats";
>allow-recursion {"rec";};
>allow-query-cache { localhost; "rec" ; };
>// CIS recommended:
>// serverid none;
>// dnssec-enable yes;
>// dnssec-validation auto;
>// dnssec-accept-expired no;
>
>listen-on { 192.168.1.61; };
>
>disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
>disable-empty-zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>disable-empty-zone
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>
> };
>
> acl rec {
>127.0.0.0/8;
>192.168.1.0/24;
>::1;
> };
>
> /* Serving the following zones locally will prevent any queries
>for these zones leaving your network and going to the root
>name servers. This has two significant advantages:
>1. Faster local resolution for your users
>2. No spurious traffic will be sent from your network to the roots
> */
> // RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
> zone "localhost"{ type master; file
> "/usr/local/etc/namedb/master/localhost-forward.db"; };
> zone "127.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/localhost-reverse.db"; };
> zone "255.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
>
> // RFC 1912-style zone for IPv6 localhost address (RFC 6303)
> zone "0.ip6.arpa" { type master; file
> "/usr/local/etc/namedb/master/localhost-reverse.db"; };
>
> // "This" Network (RFCs 1912, 5735 and 6303)
> zone "0.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
>
> // Private Use Networks (RFCs 1918, 5735 and 6303)
> zone "10.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
> zone "16.172.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
> zone "17.172.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
> zone "18.172.in-addr.arpa" { type master; file
> "/u
Re: Problem resolving a domain
I have noticed this, too,
The problem seems to be related to edns - disabling edns for the upstream
servers looks to resolve the issue, this can be seen with later versions of
dig -
$ dig *+noedns* +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.
I have config along the lines of -
server 157.83.102.245 {
edns no;
};
for each of the problematic upstreams. I contacted Barclays a few months
ago about this, but never got a solid response.
Paul
On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
> Hi Rainer,
>
> I believe this is unrelated to any upgrade. The nameservers for the domain
> are broken:
>
> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>
> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
> myapplication.international.barclays.com @ns2.barcap.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1220
> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
> ;; QUESTION SECTION:
> ;myapplication.international.barclays.com. IN A
>
> ;; ANSWER SECTION:
> myapplication.international.barclays.com. 900 IN CNAME
> myapplication.glbaa.barclays.com.
>
> ;; AUTHORITY SECTION:
> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>
> ;; ADDITIONAL SECTION:
> ns21.barclays.com. 900 IN A 157.83.102.245
> ns23.barclays.com. 900 IN A 157.83.126.245
> ns22.barclays.net. 600 IN A 157.83.102.246
> ns24.barclays.net. 600 IN A 157.83.126.246
>
> ;; Query time: 196 msec
> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
> ;; WHEN: Fri May 13 14:08:49 CEST 2022
> ;; MSG SIZE rcvd: 283
>
>
> and the nameservers itself just timeout:
>
> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
> ns21.barclays.com.
>
> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
> +timeout +retries IN A myapplication.glbaa.barclays.com. @
> ns21.barclays.com.
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
>
> DNSVIZ gives the same result:
>
> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>
> • glbaa.barclays.com zone: The server(s) were not responsive to
> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
> 157.83.126.246)
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> > On 13. 5. 2022, at 13:54, Rainer Duffner wrote:
> >
> > Hi,
> >
> > at work, I have a problem resolving the following domain:
> >
> > myapplication.international.barclays.com
> >
> >
> > BIND 9.16.27, FreeBSD 12.3-P5.
> > 2022Q2 ports.
> >
> >
> > I copied the config to a VM at home - but it did not work there, either.
> >
> > I believe it must have happened on the update from BIND 9.16.26 to
> 9.16.27.
> >
> >
> > options {
> >directory "/usr/local/etc/namedb/working";
> >pid-file"/var/run/named/pid";
> >dump-file "/var/dump/named_dump.db";
> >statistics-file "/var/stats/named.stats";
> >allow-recursion {"rec";};
> >allow-query-cache { localhost; "rec" ; };
> >// CIS recommended:
> >// serverid none;
> >// dnssec-enable yes;
> >// dnssec-validation auto;
> >// dnssec-accept-expired no;
> >
> >listen-on { 192.168.1.61; };
> >
> >disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
> >disable-empty-zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
> >disable-empty-zone
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
> >
> > };
> >
> > acl rec {
> >127.0.0.0/8;
> >192.168.1.0/24;
> >::1;
> > };
> >
> > /* Serving the following zones locally will prevent any queries
> >for these zones leaving your network and going to the root
> >name servers. This has two significant advantages:
> >1. Faster local resolution for your users
> >2. No spurious traffic will be sent from your network to the roots
> > */
> > // RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
> > zone "localhost"{ type master; file
> "/usr/local/etc/namedb/master/localhost-forward.db"; };
> > zone "127.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/localhost-reverse.db"; };
> > zone "255.in-addr.arpa" { type master; file
> "/usr/local
Re: Problem resolving a domain
Further to this, I've discovered that disabling DNS cookies also seems to
help with resolution -
$ dig +nocookie +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.
Maybe the send-cookie option could be investigated? YMMV..
On a side note other recursive DNS software seem to fall back gracefully
and resolve these problems
Paul
On Fri, 13 May 2022 at 13:51, Paul Stead wrote:
> I have noticed this, too,
>
> The problem seems to be related to edns - disabling edns for the upstream
> servers looks to resolve the issue, this can be seen with later versions of
> dig -
>
> $ dig *+noedns* +timeout=1 +retries=0 IN A
> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>
> I have config along the lines of -
>
> server 157.83.102.245 {
> edns no;
> };
>
> for each of the problematic upstreams. I contacted Barclays a few months
> ago about this, but never got a solid response.
>
> Paul
>
> On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
>
>> Hi Rainer,
>>
>> I believe this is unrelated to any upgrade. The nameservers for the
>> domain are broken:
>>
>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>
>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>> myapplication.international.barclays.com @ns2.barcap.com.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>> ;; WARNING: recursion requested but not available
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1220
>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>> ;; QUESTION SECTION:
>> ;myapplication.international.barclays.com. IN A
>>
>> ;; ANSWER SECTION:
>> myapplication.international.barclays.com. 900 IN CNAME
>> myapplication.glbaa.barclays.com.
>>
>> ;; AUTHORITY SECTION:
>> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
>> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
>> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
>> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>>
>> ;; ADDITIONAL SECTION:
>> ns21.barclays.com. 900 IN A 157.83.102.245
>> ns23.barclays.com. 900 IN A 157.83.126.245
>> ns22.barclays.net. 600 IN A 157.83.102.246
>> ns24.barclays.net. 600 IN A 157.83.126.246
>>
>> ;; Query time: 196 msec
>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>> ;; MSG SIZE rcvd: 283
>>
>>
>> and the nameservers itself just timeout:
>>
>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
>> ns21.barclays.com.
>>
>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
>> +timeout +retries IN A myapplication.glbaa.barclays.com. @
>> ns21.barclays.com.
>> ;; global options: +cmd
>> ;; connection timed out; no servers could be reached
>>
>>
>> DNSVIZ gives the same result:
>>
>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>
>> • glbaa.barclays.com zone: The server(s) were not responsive to
>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>> 157.83.126.246)
>>
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>>
>> My working hours and your working hours may be different. Please do not
>> feel obligated to reply outside your normal working hours.
>>
>> > On 13. 5. 2022, at 13:54, Rainer Duffner
>> wrote:
>> >
>> > Hi,
>> >
>> > at work, I have a problem resolving the following domain:
>> >
>> > myapplication.international.barclays.com
>> >
>> >
>> > BIND 9.16.27, FreeBSD 12.3-P5.
>> > 2022Q2 ports.
>> >
>> >
>> > I copied the config to a VM at home - but it did not work there, either.
>> >
>> > I believe it must have happened on the update from BIND 9.16.26 to
>> 9.16.27.
>> >
>> >
>> > options {
>> >directory "/usr/local/etc/namedb/working";
>> >pid-file"/var/run/named/pid";
>> >dump-file "/var/dump/named_dump.db";
>> >statistics-file "/var/stats/named.stats";
>> >allow-recursion {"rec";};
>> >allow-query-cache { localhost; "rec" ; };
>> >// CIS recommended:
>> >// serverid none;
>> >// dnssec-enable yes;
>> >// dnssec-validation auto;
>> >// dnssec-accept-expired no;
>> >
>> >listen-on { 192.168.1.61; };
>> >
>> >disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
>> >disable-empty-zone
>> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>> >disable-empty-zone
>> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>> >
>> > };
>> >
>> > acl rec {
>> >127.0.0.0/8;
>> >192.168.1.0/24;
>> >::1;
>> > };
>> >
>> > /* Serving the following zones locally will prevent any queries
>> >for these zones lea
Re: Problem resolving a domain
Working around servers that drop queries causes problems for zones that do have
protocol compliant servers. The workarounds cause problems with getting
DNSSEC responses wic leads to validation failures.
--
Mark Andrews
> On 13 May 2022, at 22:58, Paul Stead wrote:
>
>
> Further to this, I've discovered that disabling DNS cookies also seems to
> help with resolution -
>
> $ dig +nocookie +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
> @ns21.barclays.com.
>
> Maybe the send-cookie option could be investigated? YMMV..
>
> On a side note other recursive DNS software seem to fall back gracefully and
> resolve these problems
>
> Paul
>
> On Fri, 13 May 2022 at 13:51, Paul Stead wrote:
>> I have noticed this, too,
>>
>> The problem seems to be related to edns - disabling edns for the upstream
>> servers looks to resolve the issue, this can be seen with later versions of
>> dig -
>>
>> $ dig +noedns +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
>> @ns21.barclays.com.
>>
>> I have config along the lines of -
>>
>> server 157.83.102.245 {
>> edns no;
>> };
>>
>> for each of the problematic upstreams. I contacted Barclays a few months ago
>> about this, but never got a solid response.
>>
>> Paul
>>
>> On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
>>> Hi Rainer,
>>>
>>> I believe this is unrelated to any upgrade. The nameservers for the domain
>>> are broken:
>>>
>>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>>> myapplication.international.barclays.com @ns2.barcap.com.
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>>> ;; WARNING: recursion requested but not available
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1220
>>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>>> ;; QUESTION SECTION:
>>> ;myapplication.international.barclays.com. IN A
>>>
>>> ;; ANSWER SECTION:
>>> myapplication.international.barclays.com. 900 IN CNAME
>>> myapplication.glbaa.barclays.com.
>>>
>>> ;; AUTHORITY SECTION:
>>> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
>>> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>>>
>>> ;; ADDITIONAL SECTION:
>>> ns21.barclays.com. 900 IN A 157.83.102.245
>>> ns23.barclays.com. 900 IN A 157.83.126.245
>>> ns22.barclays.net. 600 IN A 157.83.102.246
>>> ns24.barclays.net. 600 IN A 157.83.126.246
>>>
>>> ;; Query time: 196 msec
>>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>>> ;; MSG SIZE rcvd: 283
>>>
>>>
>>> and the nameservers itself just timeout:
>>>
>>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
>>> @ns21.barclays.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> +timeout
>>> +retries IN A myapplication.glbaa.barclays.com. @ns21.barclays.com.
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> DNSVIZ gives the same result:
>>>
>>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>>
>>> • glbaa.barclays.com zone: The server(s) were not responsive to
>>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>>> 157.83.126.246)
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ond...@isc.org
>>>
>>> My working hours and your working hours may be different. Please do not
>>> feel obligated to reply outside your normal working hours.
>>>
>>> > On 13. 5. 2022, at 13:54, Rainer Duffner wrote:
>>> >
>>> > Hi,
>>> >
>>> > at work, I have a problem resolving the following domain:
>>> >
>>> > myapplication.international.barclays.com
>>> >
>>> >
>>> > BIND 9.16.27, FreeBSD 12.3-P5.
>>> > 2022Q2 ports.
>>> >
>>> >
>>> > I copied the config to a VM at home - but it did not work there, either.
>>> >
>>> > I believe it must have happened on the update from BIND 9.16.26 to
>>> > 9.16.27.
>>> >
>>> >
>>> > options {
>>> >directory "/usr/local/etc/namedb/working";
>>> >pid-file"/var/run/named/pid";
>>> >dump-file "/var/dump/named_dump.db";
>>> >statistics-file "/var/stats/named.stats";
>>> >allow-recursion {"rec";};
>>> >allow-query-cache { localhost; "rec" ; };
>>> >// CIS recommended:
>>> >// serverid none;
>>> >// dnssec-enable yes;
>>> >// dnssec-validation auto;
>>> >// dnssec-accept-expired no;
>>> >
>>> >listen-on { 192.168.1.61; };
>>> >
>>> >disable-emp
Re: Problem resolving a domain
Agreed, but without the upstream provider actually fixing the issue I
couldn't find a way to provide resolution of this domain to my customers -
are there better ways to resolve this from our side?
There seems to be a document about this issue -
https://kb.isc.org/docs/aa-01387
Paul
On Fri, 13 May 2022 at 14:07, Mark Andrews wrote:
> Working around servers that drop queries causes problems for zones that do
> have protocol compliant servers. The workarounds cause problems with
> getting DNSSEC responses wic leads to validation failures.
>
> --
> Mark Andrews
>
> On 13 May 2022, at 22:58, Paul Stead wrote:
>
>
> Further to this, I've discovered that disabling DNS cookies also seems to
> help with resolution -
>
> $ dig +nocookie +timeout=1 +retries=0 IN A
> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>
> Maybe the send-cookie option could be investigated? YMMV..
>
> On a side note other recursive DNS software seem to fall back gracefully
> and resolve these problems
>
> Paul
>
> On Fri, 13 May 2022 at 13:51, Paul Stead wrote:
>
>> I have noticed this, too,
>>
>> The problem seems to be related to edns - disabling edns for the upstream
>> servers looks to resolve the issue, this can be seen with later versions of
>> dig -
>>
>> $ dig *+noedns* +timeout=1 +retries=0 IN A
>> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>>
>> I have config along the lines of -
>>
>> server 157.83.102.245 {
>> edns no;
>> };
>>
>> for each of the problematic upstreams. I contacted Barclays a few months
>> ago about this, but never got a solid response.
>>
>> Paul
>>
>> On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
>>
>>> Hi Rainer,
>>>
>>> I believe this is unrelated to any upgrade. The nameservers for the
>>> domain are broken:
>>>
>>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>>> myapplication.international.barclays.com @ns2.barcap.com.
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>>> ;; WARNING: recursion requested but not available
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1220
>>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>>> ;; QUESTION SECTION:
>>> ;myapplication.international.barclays.com. IN A
>>>
>>> ;; ANSWER SECTION:
>>> myapplication.international.barclays.com. 900 IN CNAME
>>> myapplication.glbaa.barclays.com.
>>>
>>> ;; AUTHORITY SECTION:
>>> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
>>> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>>>
>>> ;; ADDITIONAL SECTION:
>>> ns21.barclays.com. 900 IN A 157.83.102.245
>>> ns23.barclays.com. 900 IN A 157.83.126.245
>>> ns22.barclays.net. 600 IN A 157.83.102.246
>>> ns24.barclays.net. 600 IN A 157.83.126.246
>>>
>>> ;; Query time: 196 msec
>>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>>> ;; MSG SIZE rcvd: 283
>>>
>>>
>>> and the nameservers itself just timeout:
>>>
>>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
>>> ns21.barclays.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
>>> +timeout +retries IN A myapplication.glbaa.barclays.com. @
>>> ns21.barclays.com.
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> DNSVIZ gives the same result:
>>>
>>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>>
>>> • glbaa.barclays.com zone: The server(s) were not responsive to
>>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>>> 157.83.126.246)
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ond...@isc.org
>>>
>>> My working hours and your working hours may be different. Please do not
>>> feel obligated to reply outside your normal working hours.
>>>
>>> > On 13. 5. 2022, at 13:54, Rainer Duffner
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > at work, I have a problem resolving the following domain:
>>> >
>>> > myapplication.international.barclays.com
>>> >
>>> >
>>> > BIND 9.16.27, FreeBSD 12.3-P5.
>>> > 2022Q2 ports.
>>> >
>>> >
>>> > I copied the config to a VM at home - but it did not work there,
>>> either.
>>> >
>>> > I believe it must have happened on the update from BIND 9.16.26 to
>>> 9.16.27.
>>> >
>>> >
>>> > options {
>>> >directory "/usr/local/etc/namedb/working";
>>> >pid-file"/var/run/named/pid";
>>> >dump-file "/var/dump/named_dump.db";
>>> >statistics-file "/var/stats/named.stats";
>>> >allow-recursion {"rec";};
>>> >allo
Re: Problem resolving a domain
Hi, Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it. While I investigated this issue, I came around a posting from one or two years ago where similar problems with Barclays were reported. And now, because I already spent too much time on this, I did a little digging and found a few job descriptions on their site: https://search.jobs.barclays/job/knutsford/network-connectivity-engineer/13015/26345992688 So, they use Infoblox and F5 - though I guess the problem is more with the firewall before these products… Funnily enough, this problem was a reported to us by an entity (a subsidiary of our company) that uses Infoblox. I’m half-tempted to contact them so they can contact Barclays - but likely neither side is going to bother - because „It works with Google-DNS“. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem resolving a domain
> The problem is also that google and quad9 and most of the rest of the > internet seem to be able to resolve it. Yes, that’s **the problem**. There’s no pressure to get Barclays to fix this. If you are a customer, complain loudly. Advice your customers who are customers to complain loudly. They are non-compliant and need to deploy the fix at their side. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 13. 5. 2022, at 15:16, Rainer Duffner wrote: > > Hi, > > > Thanks for the hints! > > It does indeed work with these settings. > > The problem is also that google and quad9 and most of the rest of the > internet seem to be able to resolve it. > > > While I investigated this issue, I came around a posting from one or two > years ago where similar problems with Barclays were reported. > > And now, because I already spent too much time on this, I did a little > digging and found a few job descriptions on their site: > > > https://search.jobs.barclays/job/knutsford/network-connectivity-engineer/13015/26345992688 > > > So, they use Infoblox and F5 - though I guess the problem is more with the > firewall before these products… > > Funnily enough, this problem was a reported to us by an entity (a subsidiary > of our company) that uses Infoblox. > > I’m half-tempted to contact them so they can contact Barclays - but likely > neither side is going to bother - because „It works with Google-DNS“. > > > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: Message signed with OpenPGP -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem resolving a domain
Am 13.05.22 um 15:16 schrieb Rainer Duffner: Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it the real problem is that they are working around it - if not the stupid upstream dns providers would have pressure to do their jobs and fix it at the root cause -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
