dotNet: DNS PTR (reverse) queries

[PiqueABoo]

Haven't done reverse DNS lookups on Windows for a long while and just found out the hard way that it can be a pain with dotNet and the experience is worth writing down:

 

1) Use an older function like Resolve() and you get told it's 'obsolete' and you should use GetHostByAddress(). Do what you're told and you may well hit this problem: MS Connect link

 

2) Either way your code may end up hanging around a while if the IP isn't in DNS. Presumably it tries asking whatever is at that IP address for it's NetBIOS name, and if that box isn't switched on eventually gets around to timing out. YMMV but I didn't want the latter.

 

3) So I gave up and went and found a 3rd party DNS resolver dnDNS and so far that works just fine.

[Geoff]

I don't know anything about .net coding but over here in *nix land we generally try and do DNS resolution (in either direction) in it's own thread/process and use a named pipe/IPC/etc to tell the main program if/when we get an answer. That way we don't get in the way of the main processes execution path and hold everything up.

[PiqueABoo]

Oh you do that everywhere when you need to, but in this case a) the DNS service running on the same box is authoritative for my queries, b) I only want an answer from DNS (and I want it to be correct!), c) there's not enough mileage in it to justify coding threads and locks etc.

[Guest monkeyx]

Thanks for DNS link, will have a look at that.

 

TO be honest I currently resolve IP address/host via a thread to stop really bad WMI timeouts by only trying to connect to a valid host that pings, as the WMI RPC timeout is V slow!

 

I take it you were using a try/catch on the ip lookup. They do sometimes seem to add a bit of lag to reponse times, when the catch fires! Been looking at ways of working around it, that avoid c++!

 

If anyone has info on this I would be grateful.

[PiqueABoo]

stop really bad WMI timeouts by only trying to connect to a valid host that pings, as the WMI RPC timeout is V slow!

 

Same principle here, but I usually send an ARP to the target IP to check for signs of life (which works nicely provided your targets are on the same subnet)

 

I take it you were using a try/catch on the ip lookup. They do sometimes seem to add a bit of lag to reponse times, when the catch fires! Been looking at ways of working around it, that avoid c++!

 

Have thrown the GetHostEntry/ByAddress code away now, but must have been catching. Didn't notice that lag but it's got to be teensy compared to an RPC timeout.