unbound fail to resolve a specific PTR while other (most!) do work.
I noticed that one because my MTA rejects a message with "can't find reverse hostname" ...
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> 224.243.93.193.in-addr.arpa. PTR
;; global options: +cmd
;; connection timed out; no servers could be reached
but using the +trace option it looks better:
$ dig 224.243.93.193.in-addr.arpa. PTR +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> 224.243.93.193.in-addr.arpa. PTR +trace
;; global options: +cmd
. 518377 IN NS h.root-servers.net.
. 518377 IN NS i.root-servers.net.
. 518377 IN NS j.root-servers.net.
. 518377 IN NS k.root-servers.net.
. 518377 IN NS l.root-servers.net.
. 518377 IN NS m.root-servers.net.
. 518377 IN NS a.root-servers.net.
. 518377 IN NS b.root-servers.net.
. 518377 IN NS c.root-servers.net.
. 518377 IN NS d.root-servers.net.
. 518377 IN NS e.root-servers.net.
. 518377 IN NS f.root-servers.net.
. 518377 IN NS g.root-servers.net.
;; Received 228 bytes from ::1#53(::1) in 3072 ms
in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
;; Received 421 bytes from 2001:503:c27::2:30#53(2001:503:c27::2:30) in 1558 ms
193.in-addr.arpa. 86400 IN NS ns3.nic.fr.
193.in-addr.arpa. 86400 IN NS pri.authdns.ripe.net.
193.in-addr.arpa. 86400 IN NS sec1.apnic.net.
193.in-addr.arpa. 86400 IN NS sec3.apnic.net.
193.in-addr.arpa. 86400 IN NS sns-pb.isc.org.
193.in-addr.arpa. 86400 IN NS tinnie.arin.net.
;; Received 201 bytes from 196.216.169.10#53(196.216.169.10) in 765 ms
243.93.193.in-addr.arpa. 172800 IN NS ns2.cloud4you.biz.
243.93.193.in-addr.arpa. 172800 IN NS ns1.cloud4you.biz.
;; Received 94 bytes from 202.12.29.59#53(202.12.29.59) in 554 ms
224.243.93.193.in-addr.arpa. 86400 IN PTR relay2.netsol4u.de.
;; Received 77 bytes from 193.93.242.42#53(193.93.242.42) in 10 ms
unbound fail to resolve a specific PTR while other (most!) do
work. I noticed that one because my MTA rejects a message with
"can't find reverse hostname" ...
The reason is that the authorities drop queries with uppercase in the
query name (they do not conform to the RFCs). I have fixed unbound
use-caps-for-id feature, that you are using here, to fallback and
attempt to resolve without the upper-lowercase mixing when there are
timeouts. This fixes the lookup of this PTR.
I also fixed a bug in the 0x20 fallback procedure in unbound.
I think that this domain will not resolve if the client (i.e. end
resolver) uses uppercase in the query name. So there are likely
resolution failures for anyone typing their website in uppercase into
the web-browser ... (well, on an empty cache).
Here is the same patch for 1.4.22. The difference is in worker.c,
libworker.c, libworker.h, and worker_cb.c files, which had changed in
svn trunk.
Wouter, you're a hero!
This passes regression tests for me.
I don't know what "regression tests" do in detail but at the end of the day
the patch apply clean and I could compile. But after activating "use-caps-for-id" again
unbound still fail to resolve 224.243.93.193.in-addr.arpa. PTR on *some* of my systems.
But these systems in question show other issues too.
We had a major update on our firewall. Allmost everything work but just now I could not resolve
some other hosts (again PTRs)
today I finaly can confirm that the solution you provide as patch work well.
we identified 2 unrelated faces of our general issue "reverse lookup fail for some ip-addresses"
Face #1:
Symptom:
reverse lookup fail for some ip addresses /if use-caps-for-id is active/
Reason:
the external nameserver is broken. It answer only for lowercase queries
$ dig @ns1.cloud4you.biz. 224.243.93.193.in-addr.arpa. PTR +short
relay2.netsol4u.de.
$ dig @ns1.cloud4you.biz. 224.243.93.193.IN-ADDR.ARPA. PTR +short
...
;; connection timed out; no servers could be reached
Workaround: disable use-caps-for-id in unbound <= 1.4.22
The Fix you sent me offlist let unbound retry the queries
in complete lowercase if there are no answer so far. That work.
Was wonderful to see in as tcpdump
Face #2:
Symptom:
reverse lookup fail for some ip addresses /regardless unbound is involved or not/
But only on udp transport. On TCP transport that gets the right answer.
$ dig @pns.dtag.de. 165.160.113.149.80.in-addr.arpa. PTR +norecurse +tcp +short
tcmail13.telekom.de.
Reason:
Cisco ASA Firewall in the way
Solution:
disable DNS content inspection on Cisco device
Wow, it responds with a label less, and another mangled.
Our hypothesis:
The Cisco device parses the message and saves PTR records in a 4 byte
buffer. It iterates all labels and stores it in the buffer* using
modulo 4 to prevent buffer overflows. It then forwards the parsed
packet instead of the original.
* either with 'add' or 'or':
165+80 = 245
165|80 = 245
