[Solved] [DNSSEC] Mabanque.bnpparibas dns resolution fail with forwarding

Hello,
I’ve a bug with one specific domain (new tld): .bnpparibas
I can’t resolve mabanque.bnpparibas if dns forwarding is activated (via foris checkbox)
And if I query directly the server I’m suposed to forward to, it works

Best than a long explaination :

WITH DNS FORWARDING

/var/resolv.conf.auto

# Interface wan
nameserver 217.31.204.130
nameserver 193.29.206.206

#cat /etc/config/resolver

config resolver ‘common’
list interface ‘0.0.0.0’
list interface ‘::0’
option port ‘53’
option keyfile ‘/etc/root.keys’
option verbose ‘0’
option msg_buffer_size ‘4096’
option msg_cache_size ‘20M’
option net_ipv6 ‘0’
option net_ipv4 ‘1’
option prefered_resolver ‘kresd’
option prefetch ‘yes’
option ignore_root_key ‘0’
option dynamic_domains ‘0’
option forward_upstream ‘1’

config resolver ‘kresd’
option rundir ‘/tmp/kresd’
option log_stderr ‘1’
option log_stdout ‘1’
option forks ‘1’

config resolver ‘unbound’
option outgoing_range ‘60’
option outgoing_num_tcp ‘1’
option incoming_num_tcp ‘1’
option msg_cache_slabs ‘1’
option num_queries_per_thread ‘30’
option rrset_cache_size ‘100K’
option rrset_cache_slabs ‘1’
option infra_cache_slabs ‘1’
option infra_cache_numhosts ‘200’
list access_control ‘0.0.0.0/0 allow’
list access_control ‘::0/0 allow’
option pidfile ‘/var/run/unbound.pid’
option root_hints ‘/etc/unbound/named.cache’
option target_fetch_policy ‘2 1 0 0 0’
option harden_short_bufsize ‘yes’
option harden_large_queries ‘yes’
option key_cache_size ‘100k’
option key_cache_slabs ‘1’
option neg_cache_size ‘10k’
option prefetch_key ‘yes’

config resolver ‘unbound_remote_control’
option control_enable ‘no’
list control_interface ‘0.0.0.0’
list control_interface ‘::0’

cat /tmp/kresd.config

–Automatically generated file; DO NOT EDIT
modules = {
‘hints > iterate’
, ‘policy’
, ‘stats’
, predict = {
window = 30 – 30 minutes sampling window
, period = 24*(60/30) – track last 24 hours
}
}
hints.config(‘/tmp/kresd/hints.tmp’)
net.bufsize(4096)
net.ipv4=true
net.ipv6=false
cache.open(20*MB)
cache.clear()
policy.add(policy.all(policy.FORWARD({
‘193.29.206.206’,
‘217.31.204.130’,
})))

dig mabanque.bnpparibas

; <<>> DiG 9.10.5-P3 <<>> mabanque.bnpparibas
;; global options: +cmd
;; connection timed out; no servers could be reached

OR other possible response

; <<>> DiG 9.10.5-P3 <<>> mabanque.bnpparibas
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43648
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mabanque.bnpparibas. IN A

;; Query time: 194 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 30 21:49:25 CET 2017
;; MSG SIZE rcvd: 37

dig bnpparibas

; <<>> DiG 9.10.5-P3 <<>> bnpparibas
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4471
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
bnpparibas. 872 IN SOA a0.nic.bnpparibas. noc.afilias-nst.info. 1000002224 10800 3600 2764800 900

;; Query time: 63 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 30 21:48:34 CET 2017
;; MSG SIZE rcvd: 102

Asking directly DNS server works

#dig mabanque.bnpparibas @217.31.204.130

; <<>> DiG 9.10.5-P3 <<>> mabanque.bnpparibas @217.31.204.130
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23423
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mabanque.bnpparibas. IN A

;; ANSWER SECTION:
mabanque.bnpparibas. 9 IN A 159.50.187.79

;; Query time: 41 msec
;; SERVER: 217.31.204.130#53(217.31.204.130)
;; WHEN: Mon Oct 30 21:49:45 CET 2017
;; MSG SIZE rcvd: 64

EDIT :
with or without DNSSEC support does not change the situation – WRONG
DNSSEC is the problem with this tld

Any clue on that problem ?
Thank you very much

PS: as for now, dns forwarding is disabled, but resolution takes muccccchhh longer

Thank you! We (kresd upstream) will have a look at it.

I recommend choosing some more reliable servers to forward to.

$ kdig @217.31.204.130 mabanque.bnpparibas DNSKEY +dnssec +cd
;; WARNING: response timeout for 217.31.204.130@53(UDP)

;; WARNING: response timeout for 217.31.204.130@53(UDP)

;; WARNING: response timeout for 217.31.204.130@53(UDP)
;; WARNING: failed to query server 217.31.204.130@53(UDP)


$ dig @193.29.206.206 mabanque.bnpparibas DNSKEY +dnssec +cd

; <<>> DiG 9.10.3-P4 <<>> @193.29.206.206 mabanque.bnpparibas DNSKEY +dnssec +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2167
;; ...

You may want to add ours https://www.nic.cz/odvr/ Up to four IPs are supported for forwarding, and kresd is using random choice biased to those that reply faster. Therefore, having more of them is likely to improve speed and in cases like this also resiliency.

Thank you for your fast reply.
The thing is I am already using your servers ! (217.31.204.130 and 193.29.206.206 are CZ.NIC servers…!)

more tests :
kdig @8.8.8.8 mabanque.bnpparibas DNSKEY +dnssec +cd
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 52155
;; Flags: qr rd ra cd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 512 B; ext-rcode: Unused

;; QUESTION SECTION:
;; mabanque.bnpparibas. IN DNSKEY

;; Received 48 B
;; Time 2017-11-01 16:41:24 CET
;; From 8.8.8.8@53(UDP) in 2035.7 ms
; Warning: failed to query server 8.8.8.8@53(UDP)

no betters results with this querry on google resolvers

Oops, the addresses did feel familiar :slight_smile:

more tests : […]

The problem is actually with the zone – they just serve bad authoritative answers: mabanque.bnpparibas | DNSViz If you’re their customer, they might listen to you, but I don’t expect the engagement is worth it.

I really responded too rashly, apparently, drawing premature conclusions.

OK, so they are doing it wrong.
But nobody else seems to have this problem (I don’t expect a lot of people having there own router). And I Won’t try explaining this to a bank…

i run others tests

dig mabanque.bnpparibas +dnssec +cd

; <<>> DiG 9.10.5-P3 <<>> mabanque.bnpparibas +dnssec +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12218
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mabanque.bnpparibas. IN A

;; ANSWER SECTION:
mabanque.bnpparibas. 30 IN A 159.50.188.20

;; Query time: 106 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 01 16:46:44 CET 2017
;; MSG SIZE rcvd: 64

dig mabanque.bnpparibas

; <<>> DiG 9.10.5-P3 <<>> mabanque.bnpparibas
;; global options: +cmd
;; connection timed out; no servers could be reached

IT seems the +cd flag makes it working
what is the purpose of cd? disabling checking of what ? dnssec ?

try with dnssec disabled, it works
so to sum it up : I can’t connect because they tried and failed dnssec, and your serveur does a good job. every other user on the planet who use an ISP DNS which in a lot of cases doesn’t follow dnssec won’t have any problem ?

last question:
why does it works with forwarding disabled AND DNSSEC enabled ?

dig mabanque.bnpparibas +trace +dnssec

; <<>> DiG 9.9.5-9+deb8u14-Debian <<>> mabanque.bnpparibas +trace +dnssec
;; global options: +cmd
. 510986 IN NS a.root-servers.net.
. 510986 IN NS b.root-servers.net.
. 510986 IN NS c.root-servers.net.
. 510986 IN NS d.root-servers.net.
. 510986 IN NS e.root-servers.net.
. 510986 IN NS f.root-servers.net.
. 510986 IN NS g.root-servers.net.
. 510986 IN NS h.root-servers.net.
. 510986 IN NS i.root-servers.net.
. 510986 IN NS j.root-servers.net.
. 510986 IN NS k.root-servers.net.
. 510986 IN NS l.root-servers.net.
. 510986 IN NS m.root-servers.net.
. 510986 IN RRSIG NS 8 0 518400 20171113170000 20171031160000 46809 . HiWj4vroKVwBAiJFezh0ddPIYhCCJTHf03ggaxvZGPHF95vtyLbAUA3P +fdgOX9zAsuNy12FI04Rkworqcv3YR/OS84d6QAYE6s5/+cmLBqaLqak QJsoYKGxDLjlYlkdflrQNgtpOb7H9dE8FAGJ1IxmzaHbAC+yyZlynYut q1t3Oyenv0AgQNBy5dWodxIjENlZePfaXdfORIS9JUvldMjKlHL/faIb 15NC7/zT10id/eiguHoImJusNDTsut8/IpU+VmmkWAWu3ay4y3/smyJU qE4KR6MEg+Deb9ZB9ofnJCW30wpe1pCXUPQwtnGKj3+geljrm7lHo9m/ yeHYiQ==
;; Received 525 bytes from 192.168.1.254#53(192.168.1.254) in 748 ms

bnpparibas. 172800 IN NS a0.nic.bnpparibas.
bnpparibas. 172800 IN NS a2.nic.bnpparibas.
bnpparibas. 172800 IN NS b0.nic.bnpparibas.
bnpparibas. 172800 IN NS c0.nic.bnpparibas.
bnpparibas. 86400 IN DS 825 7 1 2C6C5821939CB3BC107E8A64C4AA3940E772DA6D
bnpparibas. 86400 IN DS 825 7 2 3A7CB9DBC2606BCD95A6CE88D4D833B6CFCB7B43C84DADD3CFA7FF73 73C1C91B
bnpparibas. 86400 IN RRSIG DS 8 1 86400 20171114150000 20171101140000 46809 . cOzOQvf1MQjStcW0g1k8gze3cjd3UEgIxwwqqpfMIVqDvzgRt7ZcAO1e vsGg26jPwzN/NbpQ/S2nSW7pU5vUbQOZdRBQZuvYWWMVKgZzwCz1dw6g LNZYUKk+8QjieCJ/anliTCwCm4CtYukPy04BwgDrwsDzMLxWl5wSnXe0 Tk/lXwAhoEpU75UYjvfyoALiE8ozGik01G4D4llobuvzCXzHTFpG4oxA R0IpXErODpDlRML17yi5HJY2ndcL/EMCj9ironqjj1VVAtX524BquMO7 0WdFUA8SZ7yxFB9UhFfhvd6TTpJtoLNqd8bjtRAkdEIYWga7NsYOCjZz Y7q7Iw==
;; Received 667 bytes from 193.0.14.129#53(k.root-servers.net) in 855 ms

mabanque.bnpparibas. 86400 IN NS sns6.bnpparibas.fr.
mabanque.bnpparibas. 86400 IN NS sns5.bnpparibas.net.
bnt3k2h6f7btfbe58mb06ss1l8cek77h.bnpparibas. 900 IN NSEC3 1 1 1 D399EAAB 6IBJF5AP3M5TVAI3L9O49OLIFKPJDBC5 NS SOA RRSIG DNSKEY NSEC3PARAM
bnt3k2h6f7btfbe58mb06ss1l8cek77h.bnpparibas. 900 IN RRSIG NSEC3 7 2 900 20171122025526 20171101015526 60087 bnpparibas. e+bSJJbPEDR4INxZIjzfqbf5jwvsn04M0v56g0A1iY6BK4262v5qVqjs 8A37v1Z5LPj+wu3t9H9si5Ar2HcBfKX7Ljn4TKubAkbKB/Y8EIsYGghp OkLZ00hJK2GSSZzosSyTX860/5By+HfR4fbsPsdewfTAm3RVk3O/hzJr paQ=
;; Received 367 bytes from 65.22.67.9#53(a2.nic.bnpparibas) in 307 ms

mabanque.bnpparibas. 30 IN A 159.50.188.20
;; Received 64 bytes from 159.50.249.65#53(sns5.bnpparibas.net) in 21 ms

thank you very much

Yes. The purpose is to ignore any DNSSEC errors – typically just return whatever came from upstream without attempting any checks.

This is because without forwarding it’s easier (more natural) to discover zone properties, so kresd finds earlier that the zone is insecure and thus won’t even attempt to query for its DNSKEY.

Alright, understood !
Thanks a lot.

Last question :slight_smile:
Is there an easy method with kresd config, to either ignore dnssec errors and continue resolving (but for a security point of vue, is this bad and deceive the whole purpose of dnssec ? but dnssec validator should see the problem ?)

OR just disable forwarding for this domain

And watching http://dnsviz.net : in fact tld bnpparibas is protected with dnssec but not the sub-domains, did i understood well ?

thanks

Is there an easy method with kresd config, to either ignore dnssec errors and continue resolving […]

The main point of DNSSEC is to fail resolutions – those that don’t validate for some reason. Otherwise you do all the extra work for almost no benefit (very few software reads the AD flag).

There’s probably a few reasonable workaround possibilities, e.g. (1) forward all except this domain, as you suggest, or (2) explicitly mark this domain as insecure. I’ll post some config, hopefully tomorrow.

Correct.

See https://www.turris.cz/doc/en/public/dns_knot_misc#negative_trust_anchors

trust_anchors.negative = { ‘mabanque.bnpparibas’ }

Works perfectly

One more question to understand the dnssec system in that case:
what is the difference between:

mabanque.bnpparibas | DNSViz : which miserably fail
cic.fr | DNSViz : which works perfectly

in both case, tld is secure (.fr or .bnpparibas) and domain is not (mabanque and cic)
The only difference I could see is that :

dig cic.fr +dnssec DNSKEY : answers (status: NOERROR / flags: do; UDP size: 4096 B; ext-rcode: Unused)

dig mabanque.bnpparibas +dnssec DNSKEY : does not answers and timeout

Is this the reason of the failed resolving for this (not) DNSSEC protected domain ?
The delegated server should answer something (“i have no dnskey entry”) if asked ? else failing resolution?

The servers not answering is certainly a violation of the protocol. Empty NOERROR answer is perfectly OK, just saying that the name exists but it does have no records of that type.

The real reason why knot-resolver’s forwarding currently fails is that it needs to obtain mabanque.bnpparibas NS to verify that there’s a zone cut, and it isn’t answered either.

1 Like