Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Stephane Bortzmeyer]

On Sat, May 30, 2020 at 06:50:53PM +,
 dagon  wrote 
 a message of 41 lines which said:

>  How can you even load
>  such a zone in a modern authority server?  All modern auth
>  servers would fail, I believe.

It may be that the authority server is correct but there is a firewall
in front of it, filtering requests and generating REFUSED, timeouts,
etc. I've seen people putting broken middleboxes before perfectly
working BIND servers...
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Ondřej Surý]

Most probably it is the load-balancer. I’ve seen this before.

Ondřej
--
Ondřej Surý 

> On 30 May 2020, at 21:09, dagon  wrote:
> 
> How can you even load
> such a zone in a modern authority server?  All modern auth
> servers would fail, I believe.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[dagon]

On Sat, May 30, 2020 at 06:09:24PM +0200, Stephane Bortzmeyer wrote:

> The existing DNS configuration is clearly very questionable, such as a
> zone delegated to just one name server, and a broken one, replying
> REFUSED for NS and SOA queries.

> The question is "how did this incorrect setup can produce *sometimes*
> a resolution failure?"

Guesses:

  1) I speculate some cloud resolvers like Cloudflare enforce 1035's
 requirement that a valid zone ('master file') contain at least an
 SOA and NS, and therefore fail lookups in the zone.  This is a
 guess.

  2) And as you know qname minimization (strict or flexible) should
 work here.  But perhaps Cloudflare has another 7816-like policy
 that fails this zone?  This is also a complete guess.

 In writing intentionally bad DNS authorities, I've found the
 cloud DNS providers have batteries of checks (e.g., for ECS
 support, for child NS, for SOA, etc.).  Some like OpenDNS even
 probe each label level of lenghty qnames for zone cuts.

 The cloud providers promise safety improvements, so perhaps the
 missing SOA causes a fail, or they implemented 7816 differently.

  3) Perhaps an appliance is not passing SOA queries?  Even if cloud
 providers don't enforce the 1035 'minimal master file'
 requirements, the bank's authority should.  How can you even load
 such a zone in a modern authority server?  All modern auth
 servers would fail, I believe.

Most malware domains do a better job of provisioning and
configuration.  Can this bank be helped?

-- 
David Dagon
da...@sudo.sh
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Paul Ebersman]

matthew-l> I wonder whether the first one (SERVFAIL for NS) is a clue.
matthew-l> bcpe.fr is delegated to the same servers which do not answer
matthew-l> NS queries.  Thus, NS RRSET is only available from the parent
matthew-l> (.fr) and not the child.  Maybe this upsets child-centric
matthew-l> resolvers.

Likely. Comcast is using nominum, which is parent-centric. Works on
their resolvers:

$ dig @75.75.75.75 banquepopulaire.fr ns

; <<>> DiG 9.12.2 <<>> @75.75.75.75 banquepopulaire.fr ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62340
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;banquepopulaire.fr.IN  NS

;; ANSWER SECTION:
banquepopulaire.fr. 3600IN  NS  dns2.bpce.fr.
banquepopulaire.fr. 3600IN  NS  dns1.bpce.fr.

;; Query time: 367 msec
;; SERVER: 75.75.75.75#53(75.75.75.75)
;; WHEN: Sat May 30 11:30:55 MDT 2020
;; MSG SIZE  rcvd: 90

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Matthew Richardson]

Dear Stephane,

Whilst I have not got an answer, I have managed to get an example of a
failure using Cloudflare:-

>; <<>> DiG 9.11.19 <<>> @1.1.1.1 banquepopulaire.fr ns
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41975
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 1452
>;; QUESTION SECTION:
>;banquepopulaire.fr.IN  NS
>
>;; Query time: 14 msec
>;; SERVER: 1.1.1.1#53(1.1.1.1)
>;; WHEN: Sat May 30 18:02:59 BST 2020
>;; MSG SIZE  rcvd: 47

and thereafter:-

>; <<>> DiG 9.11.19 <<>> @1.1.1.1 www.banquepopulaire.fr
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53725
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 1452
>;; QUESTION SECTION:
>;www.banquepopulaire.fr.IN  A
>
>;; Query time: 4148 msec
>;; SERVER: 1.1.1.1#53(1.1.1.1)
>;; WHEN: Sat May 30 18:03:21 BST 2020
>;; MSG SIZE  rcvd: 51

I wonder whether the first one (SERVFAIL for NS) is a clue.  bcpe.fr is
delegated to the same servers which do not answer NS queries.  Thus, NS
RRSET is only available from the parent (.fr) and not the child.  Maybe
this upsets child-centric resolvers.

I am just guessing though...

The whole thing is très mauvaise pratique as reported, all the more so for
a bank!

Best wishes,
Matthew

 --
>From: Stephane Bortzmeyer 
>To: DNS Operations List 
>Cc: 
>Date: Sat, 30 May 2020 18:09:24 +0200
>Subject: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

>Several users on Twitter reported problems accessing Banque Populaire
>(a French bank) https://www.banquepopulaire.fr
>https://www.ibps.loirelyonnais.banquepopulaire.fr
>https://www.ibps.bpaca.banquepopulaire.fr
>https://www.ibps.mediterranee.banquepopulaire.fr/
>
>From the limited reports, all errors point to a DNS issue. (For one
>user, adding the IP address in /etc/hosts solved the problem.)
>
>But testing with existing resolvers and with the RIPE Atlas probes do
>not show a widespread outage.
>
>The existing DNS configuration is clearly very questionable, such as a
>zone delegated to just one name server, and a broken one, replying
>REFUSED for NS and SOA queries.
>
>The question is "how did this incorrect setup can produce *sometimes*
>a resolution failure?"
>
>Details in french, plus dig outputs (not in french) are at
>.
>
>___
>dns-operations mailing list
>dns-operations@lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Florian Weimer]

* Stephane Bortzmeyer:

> Several users on Twitter reported problems accessing Banque Populaire
> (a French bank) https://www.banquepopulaire.fr
> https://www.ibps.loirelyonnais.banquepopulaire.fr
> https://www.ibps.bpaca.banquepopulaire.fr
> https://www.ibps.mediterranee.banquepopulaire.fr/
>
> From the limited reports, all errors point to a DNS issue. (For one
> user, adding the IP address in /etc/hosts solved the problem.)
>
> But testing with existing resolvers and with the RIPE Atlas probes do
> not show a widespread outage.

I can reproduce this to some extent:

$ dig +norecurse +dnssec @nsisp1.i-bp.banquepopulaire.fr. 
www.banquepopulaire.fr. MX

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +norecurse +dnssec 
@nsisp1.i-bp.banquepopulaire.fr. www.banquepopulaire.fr. MX
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 59096
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.banquepopulaire.fr.IN  MX

;; Query time: 41 msec
;; SERVER: 91.135.182.250#53(91.135.182.250)
;; WHEN: Sat May 30 18:36:35 CEST 2020
;; MSG SIZE  rcvd: 51

$ dig +norecurse +dnssec @nsisp1.i-bp.banquepopulaire.fr. 
www.banquepopulaire.fr. TYPE1000

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +norecurse +dnssec 
@nsisp1.i-bp.banquepopulaire.fr. www.banquepopulaire.fr. TYPE1000
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

A recursive resolver will turn these responses into SERVFAILs.

I suspect this can cause resolvers to cache bad server reachability
information, leading to name resolution error for A and  queries
as well.

Or it could just be a client that uses RFC 2782:

$ dig +norecurse +dnssec @nsisp1.i-bp.banquepopulaire.fr. 
_http._tcp.www.ibps.loirelyonnais.banquepopulaire.fr SRV

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +norecurse +dnssec 
@nsisp1.i-bp.banquepopulaire.fr. 
_http._tcp.www.ibps.loirelyonnais.banquepopulaire.fr SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49919
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_http._tcp.www.ibps.loirelyonnais.banquepopulaire.fr. IN SRV

;; Query time: 39 msec
;; SERVER: 91.135.182.250#53(91.135.182.250)
;; WHEN: Sat May 30 18:47:02 CEST 2020
;; MSG SIZE  rcvd: 81
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Stephane Bortzmeyer]

Several users on Twitter reported problems accessing Banque Populaire
(a French bank) https://www.banquepopulaire.fr
https://www.ibps.loirelyonnais.banquepopulaire.fr
https://www.ibps.bpaca.banquepopulaire.fr
https://www.ibps.mediterranee.banquepopulaire.fr/

>From the limited reports, all errors point to a DNS issue. (For one
user, adding the IP address in /etc/hosts solved the problem.)

But testing with existing resolvers and with the RIPE Atlas probes do
not show a widespread outage.

The existing DNS configuration is clearly very questionable, such as a
zone delegated to just one name server, and a broken one, replying
REFUSED for NS and SOA queries.

The question is "how did this incorrect setup can produce *sometimes*
a resolution failure?"

Details in french, plus dig outputs (not in french) are at
.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations