When too many PTR RRs are returned nmap's parallel reverse DNS lookup fails as the register is truncated for not fitting into UDP and no fallback to TCP is made. The system-resolver works flawlessly there though.
Nmap should instead try to fallback in such a situation to doing a slower TCP request. This will more likely become a worse problem as signed DNS records become more common.
@klondi Thanks for the report. Do you have an example IP address for which this is an issue? This would help us to develop and test a fix.
Not that i can publicly disclose (sadly) I'll try to prepare such address using ipv6 and come back to you.
Otherwise if you have control over an ipv4 rrdns, you could publish say 20 or 30 long ptr record as query replies to experience the issue as it is caused by truncation when the record can't fit an UDP packet.
I tried but at least hurricane electric doesn't allows me to do so :(
I also tried with dnsmasq but it only returned the first record. To my understanding the servers being used are bind so I suspect it should be possible to set such a setup but I'm, not familar with it to do so either.
Depending on the flags we send, we could get different or no responses:
Some resources for solving this issue:
Finally, we should be sure that our dns-* NSE scripts can handle these fallback behaviors.
I can at least confirm that in the case triggering the issue (for which sadly I still have no clearance for disclosing). The following call works on nse scripts:
The case triggering the issue though is basically the server returning too many RRs in response to the PTR query. I suspect this is doable with BIND but can't say with total security as I don't have full knowledge of the servers being used for serving DNS in the particular network that triggered the issue.
I think that the logic can be improved a bit though as nowadays we only require a single hostname:
I am working on nmap_dns "modernization"
Since the commit 0ce5ffe6 nmap_dns try to process also truncated packets, this should solve your problem in most cases, while TCP fallback is still missing, if you would test it and report back it would be welcomed :)
was there any progress with this? I can see that there was some GSoC for this, but that link above is dead.
@mhlavink We're working on it in #434 and #400, but we haven't ironed out all the bugs yet. Should be done in the next week or so.
Falls back to "getnameinfo" for truncated replies in reverse DNS reso…
…lver. Closes #434 and #400, fixes #364 and #103.
@mhlavink @klondi We've just pushed a change to handle truncated replies: if the reply contains an answer that is satisfactory, we use it even if the reply is marked truncated. Otherwise, we fall back to the system resolver for that address. We'd appreciate your feedback: please let us know if this solves the issue or if you have further problems.
@dmiller-nmap Thanks. I did some tests and it seems to resolve the issue. I've prepared test build and forwarded it to the user who originally reported this to us.
Well, we never closed out this issue, but I think it has been resolved. Let us know and we'll reopen if it shows up again.