Does setting router DNS to 208.67.220.220 interfere with Remote Desktop Connection?
In the "WAN IP Settings" page of my Actiontec GT784WNV DSL modem router, I have "Select the DNS Type" set to Static DNS Addresses 208.67.220.220 as Primary and 208.67.222.222 as Secondary. The OpenDns Updaters on both my home computers are working - I am definitely linking to OpenDNS, which of course is good.
[NOTE: In the "LAN IP and DHCP Settings" page of the modem router, "Set the DNS values" is set EITHER to Dynamic OR to Static with DNS Server 1 set to 192.168.1.1, which is the IP of the modem router itself, and DNS Server 2 left blank. The problem I explain below is the same either way.]
I have two Win XP Pro SP3 machines at home on a Workgroup home network. If I want to control one PC with the other using MS Remote Desktop Connection (RDC), I cannot specify the Host (remote) PC by name - I must use its IP address, which today is 192.168.1.5. If I try to connect with its name, RDC gives me an error message "This computer cannot connect to the remote computer. ..." Also, if I open a cmd window and try to ping the remote computer by name, the ping goes outside the Workgroup home network and reaches out to one of OpenDNS's IP addresses to do the ping! But if I ping by IP, it stays internal.
NOW, if I go back to the "WAN IP Settings" page of my modem router and set "Select the DNS Type" to Dynamic (no longer OpenDNS), then RDC works using the Host (remote) computer's name. However, the OpenDNS Updaters then report errors and I am no longer doing DNS with OpenDNS, which of course is bad.
►There is no question that setting the modem router "WAN IP Settings" to Static for DNS with the OpenDNS IP numbers is preventing RDC from connecting inside my home workgroup using computer names. RDC still works with internal IP numbers, but, as my home workgroup uses DHCP internally, this makes RDC harder to use.◄
► So, how can I have BOTH my modem router set to use OpenDNS for its outside DNS lookups AND my RDC work using computer names? ◄
☻ Hey - this is a toughy, yes? We'll be REAL IMPRESSED if there's an answer to this. ☺
-
You'll configure the OpenDNS resolver addresses only on the WAN side of your router, not on the LAN side. Configuring on the LAN side indeed impacts or breaks local name resolution. This is to be expected, of course. If you introduce external resolver addresses on the LAN side, internal name resolution cannot work orderly anymore.
If you cannot configure the OpenDNS resolver addresses on the WAN side (only), you'll have to add your internal names to the VPN exceptions list.
https://support.opendns.com/entries/26022539-How-do-I-use-OpenDNS-and-Manage-Internal-Resources-and-Virtual-Private-Networks-Not sure what this has to do with the OpenDNS Updater. It should work independently from where you configured the resolver addresses. You may want to post the Updater's log here if there are problems, so we can take a look.
-
Rotblitz - I'm REAL IMPRESSED.
Your suggestions seems to be working, although it takes a few minutes for the added VPN setting to catch hold.
I added three things to the VPN exceptions list:
- the full router's domain name domain.actdsltmp
- just actdsltmp
- the target (host) PC name georgeI don't know which of these did the trick - do you?
As you and team do not yet have instructions for my Actiontec GT784WNV DSL modem router, I strongly suggest you add these VPN exceptions list notes to those instructions whenever you post them. Also, I have attached screenshots of the WAN and LAN pages in this model Actiontec GT784WNV if they are helpful.
Actiontec GT784WNV - Advanced Setup - IP Addressing - WAN IP Address.pdf
Actiontec GT784WNV - Advanced Setup - LAN IP AND DHCP SETTINGS.pdf -
"Your suggestions seems to be working, although it takes a few minutes for the added VPN setting to catch hold."
To take effect more immediately than 3 minutes, you need to flush your local caches, of course.
https://support.opendns.com/entries/23281284-Clearing-the-DNS-Cache-on-Computers-and-Servers
https://support.opendns.com/entries/23739610-Clearing-the-DNS-Cache-on-Browser"I don't know which of these did the trick - do you?"
Your domain stats will tell you. https://dashboard.opendns.com/stats/all/topdomains
"As you and team do not yet have instructions..."
Certainly not, I'm just a user like you. :) And there is no team of mine.
You better open a support ticket to get the instructions added. -
Not sure how to read the domain stats. A bunch of lines have [something].domain.actdsltmp -- the last two words being the domain name inside my modam router. All seem to be resolved normally. One line says: george.domain.actdsltmp 15 This domain resolved normally. You can block this domain or block similar domains . That's the target (host) computer. What does that line mean? Another line is very similar with the name of my principal PC - the one I'm on now. Also domain resolved normally. Is that OK? -
Not sure how to read the domain stats. A bunch of lines have [something].domain.actdsltmp -- the last two words being the domain name inside my modam router. All seem to be resolved normally. One line says: george.domain.actdsltmp 15 This domain resolved normally. You can block this domain or block similar domains . That's the target (host) computer. What does that line mean? Another line is very similar with the name of my principal PC - the one I'm on now. Also domain resolved normally. Is that OK? -
"A bunch of lines have [something].domain.actdsltmp"
These are all local name resolution attempts exactly with the names as they appear at OpenDNS. These "DNS suffixes" are appended by your OS when building the DNS queries. It may be sufficient to add actdsltmp or domain.actdsltmp to your VPN exceptions list then. "Subdomains" are usually covered by the parent.
"This domain resolved normally."
This message shows up always except if a domain is blocked by your settings. Also NXDOMAIN and SERVFAIL DNS results appear like this.
You can reveal what is really returned by executing commands like (trailing dots are significant to indicate an FQDN):
nslookup george nslookup [something].domain.actdsltmp.
nslookup domain.actdlstmp.
nslookup actdlstmp.
...and so forth...They should return either the private IP address of the related device or an NXDOMAIN DNS result (domain does not exist), the latter being returned by OpenDNS. If it returns a public IP address like 67.215.65.132 (hit-nxdomain.opendns.com), then your VPN exceptions list is not correct and does not cover certain names.
-
"none of them works."
No, all of them works. I said: They should return either the private IP address of the related device or an NXDOMAIN DNS result (domain does not exist)
And exactly this is what is happeing now, as should be."But RDC is working with the target (host) PC name!"
Yes, because OpenDNS now returns NXDOMAIN, and your OS continues to resolve by other means, e.g. NetBIOS, as should be. NetBIOS can resolve your internal names, external DNS can't.
-
Rotblitz - great - understood. Now, do you think I should go into the network settings for both PCs and DISABLE NetBIOS? On a few other threads about this type of problem, some posters advised how NetBIOS is old and sometimes problem-prone, and even internal workgroup networks should move to DNS-IP. What do you think?
Please sign in to leave a comment.
Comments
14 comments