Hi all,
all public DNS resolvers (Google, OpenDNS, etc.) can resolve icaps [.] munichre [.] com.
Only Cloudflare resolver does not deliver the A record.
What is the reason?
Regards,
Axel
$ dig icaps.munichre.com @1.1.1.1
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> icaps.munichre.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14281
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;icaps.munichre.com. IN A
;; ANSWER SECTION:
icaps.munichre.com. 28800 IN A 193.103.195.220
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Fri Dec 09 16:08:50 CET 2022
;; MSG SIZE rcvd: 63
Works for me. Does it not work in a specific location? (try dig with +nsid).
Thanks.
It’s strange right now I get the right answer too.
I tried this since six days.
However, if you throw the domain into DNSChecker right now.
https:// dnschecker. org/#A/icaps . munichre . com
It shows still that Cloudflare public DNS is the only resolver not delivering the A record.
In the past days sometimes a Mexican and a New Zealand resolver had the same problem.
You have a bad delegation (horizontal referral) in your DNS setup.
The domain’s two nameservers are netserv.munichre.com and ftp.munichreamerica.com. The first one looks okay.
The problem is that ftp.munichreamerica.com is delegating this request (via NS record) to two other servers, netserv.munichreamerica.com and netserv.munichre.com. That second one is your other primary nameserver, which, as I said, is fine. But the first one is delegating back onto itself. So half of your requests are going to this bad setup, and half of those requests will fail because the query loops back on itself. The result is that 25% of queries for icaps.munichre.com will fail. Because of caching, some servers that once failed will now succeed, and vice-versa.
You can see the details in the following dig output:
> dig icaps.munichre.com @ftp.munichreamerica.com
; <<>> DiG 9.10.6 <<>> icaps.munichre.com @ftp.munichreamerica.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39418
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;icaps.munichre.com. IN A
;; AUTHORITY SECTION:
icaps.munichre.com. 900 IN NS netserv.munichreamerica.com.
icaps.munichre.com. 900 IN NS netserv.munichre.com.
;; ADDITIONAL SECTION:
netserv.munichreamerica.com. 28800 IN A 167.15.253.70
netserv.munichre.com. 900 IN A 193.103.202.35
;; Query time: 22 msec
;; SERVER: 167.15.253.70#53(167.15.253.70)
;; WHEN: Fri Dec 09 12:24:59 EST 2022
;; MSG SIZE rcvd: 139
> dig icaps.munichre.com @netserv.munichreamerica.com
; <<>> DiG 9.10.6 <<>> icaps.munichre.com @netserv.munichreamerica.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3810
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;icaps.munichre.com. IN A
;; AUTHORITY SECTION:
icaps.munichre.com. 900 IN NS netserv.munichre.com.
icaps.munichre.com. 900 IN NS netserv.munichreamerica.com.
;; ADDITIONAL SECTION:
netserv.munichreamerica.com. 28800 IN A 167.15.253.70
netserv.munichre.com. 900 IN A 193.103.202.35
;; Query time: 24 msec
;; SERVER: 167.15.253.70#53(167.15.253.70)
;; WHEN: Fri Dec 09 12:26:10 EST 2022
;; MSG SIZE rcvd: 139
1 Like
Many thanks for the explanation.
I’ll pass this info to Munich Re.
1 Like
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.