Forum Discussion
Issues with Network Name Resolution
Support has a good point, and data is not laying.
Note though that those stats are not saying 45% of observed IPs fail to resolve.
It means 45% of resolve attempts.
So if you have little amount of IPs doing most of the traffic over time, and they resolve fine, it will increase your success rate in this metric...
Also the other way around, if you have little IPs that fail to resolve but doing most of the traffic,
they will lower your rate in this metric...
I know - having per IP aggregated stats would be nice, but it comes with a price that we currently try to avoid, but support can also turn on tracing for you for a few hours to also give you a significant amount of examples which succeed/fail for each method which might also help you understand what is going on in the network. We usually turn those on only for a few hours, as this is extremely verbose and heavy...
What about NTLMRpc ? what was the success rate there?
are NTLM RPC and Netbios blocked most of the time? if yes, it could be that RDP is doing better...
- Timing: NNR will take place probably seconds within the time the endpoint initiated contact with the DC, so most chances it's not asleep or disconnected.
- all high certainty active methods run in parallel
- DNS is low certainty , so we try to relay on it as low as possible, we don not support relying just on DNS based NNR.
- As for alternatives - Yes, there are plans, we have methods via other protocols as well, some of them are already actively used in private preview customers, and once we tune it enough , will be used for everyone and offer more flexibility.
- We are considering using MDE as well, but this is currently considered only in theory and far from a decision if will be eventually effective, and if yes, it will take a significant time to implement.
- The process resolves IP to name
Thank you so much EliOfek for your response, it is very helpful and greatly appreciated.
I did not mean to come across as doubting the recommendation or the data itself, in fact I do agree with it, I just have a hard time understanding how RDP could be a lower failure rate than NetBIOS.
TCP135 and UDP137 are allowed to all but a few clients that the sensors/DC's are attempting to resolve. RDP is blocked to anything on VPN or behind another firewall so therefore much more restricted. Where this is the case (no NetBIOS, NTLMRpc or RDP) is there any alternative to attaining higher certainty?
Support did not provide NTLMRpc rates so assuming OK otherwise but have asked for numbers. I have also asked support to look at turning up trace level logging. I will update this thread once i know more
So if I understand you correctly, NRR is a result of a client contacting a DC. That is good to know. Also glad to hear there are alternate protocols being worked and tuned. Hopefully something there that can be used for those types of devices\appliances that cannot\will not be able to return data back for NRR.