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

[Petr Špaček]

On 02. 06. 20 23:39, Guillaume LUCAS wrote:
> Hello,
> 
> I just subscribed to this list, so sorry for the thread breaking.
> 
>> Several users on Twitter reported problems accessing Banque
>> Populaire (a French bank)
> 
> Since 1 pm (UTC+2) this day (June 2nd), it works from CloudFlare, FDN,…
> everywhere. Customers confirm that on Twitter [*]. But
> nsisp1.i-bp.banquepopulaire.fr. still returns REFUSED for NS/SOA and
> over-TCP queries for www.banquepopulaire.fr or
> www.ibps.bpaca.banquepopulaire.fr. So, I don't understand what the root
> cause of the problem was…
> 
> www.caisse-epargne.fr, a french bank of the same banking group as Banque
> Populaire, had a similar problem in the same period of time: the two
> name servers for this DNS zone, nslp1.gcetech.net and nslp2.gcetech.net,
> returned NODATA for NS/SOA queries (but they answered to over-TCP
> queries). Unbound 1.9 could resolve this name, Unbound 1.6 couldn't.
> Technical details (in french): <http://shaarli.guiguishow.info/?TqC4Ug>.
> Like Banque Populaire, name resolution works since 1 pm (UTC+2) today.
> nslp(1|2).gcetech.net still returns NODATA… So, again, I don't
> understand what the root cause was…
> 
> @Matthew: you said « bcpe.fr is delegated to the same servers which do
> not answer NS queries ». It's wrong. bpce.fr have always been delegated
> to dns(1|2).bpce.fr . These servers have always answered to NS/SOA and
> TCP queries. Name servers for banquepopulaire / bpce.fr / groupebpce.com
> = dns(1|2).bpce.fr, name servers for www.banquepopulaire.fr /
> www.ibps.*.banquepopulaire.fr / www.*.banquepopulaire.fr =
> nsisp1.i-bp.banquepopulaire.fr. On last Saturday, I was able to
> reproduce your result for "dig @1.1.1.1 banquepopulaire.fr ns":
> CloudFlare always aswered SERVFAIL (or didn't answer). CloudFlare was
> the only resolver in this case. So, like you observed, it's normal that
> CloudFlare stop the resolution at this point, but what about the other
> resolvers?

Please let's not get to shaming resolvers here, the delegation chain for www.banquepopulaire.fr. is a utter mess.

The subdomain "www" is delegated to IP addresss 91.135.182.250 which answers REFUSED to most queries, so I guess it is a dumb or misconfigured load-balancer.

The only query which kind of works is:
$ dig +nord @91.135.182.250 www.banquepopulaire.fr

; <<>> DiG 9.16.3 <<>> +nord @91.135.182.250 www.banquepopulaire.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32881
;; flags: qr aa ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.banquepopulaire.fr.	30	IN	A	91.135.183.180
www.banquepopulaire.fr.	30	IN	A	91.135.183.180

;; Query time: 56 msec
;; SERVER: 91.135.182.250#53(91.135.182.250)
;; WHEN: St čen 03 10:33:51 CEST 2020
;; MSG SIZE  rcvd: 83

Yes, the duplicate RR is really here!


Fresh DNSViz analysis:
https://dnsviz.net/d/www.banquepopulaire.fr/XtdfDQ/dnssec/

    www.banquepopulaire.fr zone: The server(s) were not responsive to queries over TCP. (91.135.182.250)
    www.banquepopulaire.fr/DNSKEY: The response had an invalid RCODE (REFUSED). (91.135.182.250, UDP_-_EDNS0_4096_D_K, UDP_-_EDNS0_512_D_K)
    www.banquepopulaire.fr/MX: The response had an invalid RCODE (REFUSED). (91.135.182.250, UDP_-_EDNS0_4096_D_K, UDP_-_EDNS0_512_D_K)
    www.banquepopulaire.fr/NS: The response had an invalid RCODE (REFUSED). (91.135.182.250, UDP_-_EDNS0_4096_D_K)
    www.banquepopulaire.fr/SOA: No response was received from the server over TCP (tried 3 times). (91.135.182.250, TCP_-_EDNS0_4096_D)
    www.banquepopulaire.fr/SOA: The response had an invalid RCODE (REFUSED). (91.135.182.250, UDP_-_EDNS0_4096_D_K, UDP_-_EDNS0_4096_D_K_0x20)
    www.banquepopulaire.fr/TXT: The response had an invalid RCODE (REFUSED). (91.135.182.250, UDP_-_EDNS0_4096_D_K)

>From my perspective it is sufficiently broken to warrant fix on auth side.

Maybe resolver operators decided to workaroud it on their side, which would be the most unfortunate. The auth operator should bear the cost of their own misconfigurations, not resolver operators.

-- 
Petr Špaček  @  CZ.NIC