Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet IT

Dealing With ISPs That Use NXDomain Redirection? 264

Posted by timothy from the looking-at-you-charter dept.
Vrtigo1 writes "I work for a small company that has about 50 staff on the road relying on VPN back to our office at any given time. Many ISPs have implemented NXDomain redirection services that hijack DNS traffic to show you sponsored links and other related ads when you mistype a domain name. These services are incompatible with most VPN software, since they prevent the computer from resolving internal hostnames. Large ISPs typically provide an opt-out on their sponsored links page that immediately opts you out of the DNS redirection, but I've noticed that some smaller ISPs and CLECs have opt-out links that don't actually appear to do anything. I don't have a good solution for employees using these ISPs, and our employees are getting frustrated because the problem is becoming more prevalent and we can't fix it for them. I've tried calling a few of these smaller ISPs for help, but it's been like talking to a wall. Manually changing DNS servers works temporarily, but the user can't resolve internal hostnames when they connect to the office LAN again. Have you had to deal with ISPs using non-standard DNS servers? What is your solution?"
This discussion has been archived. No new comments can be posted.

Dealing With ISPs That Use NXDomain Redirection? More

Dealing With ISPs That Use NXDomain Redirection?

Comments Filter:

  • This is an easy one. (Score:5, Insightful)

    by snarfies ( 115214 ) on Wednesday May 13, 2009 @02:20PM (#27941189) Homepage

    If the small local ISP is screwing up, and refuses to respond in any useful way despite your best repeated efforts, it sounds like its time to take your business elsewhere, maybe to one of those large ISPs you mentioned. And make sure you tell them WHY. Who know, maybe the threat alone will be enough to get them to make a sudden change in policy for you, with a month or two of free service to boot.

    • Re:This is an easy one. (Score:5, Insightful)

      by internerdj ( 1319281 ) on Wednesday May 13, 2009 @02:27PM (#27941299)
      This guy sounds like a manager or IT worker who is having problems with his employees connecting to the work VPN. He isn't the one paying the bill(directly at least), so he doesn't even have the clout of a paying customer...

      • could someone explain what the issue is here? (Score:5, Informative)

        by goombah99 ( 560566 ) on Wednesday May 13, 2009 @03:11PM (#27942029)

        This guy sounds like a manager or IT worker who is having problems with his employees connecting to the work VPN.

        it sounds more like he has not stated the problem correctly.

        how is it possible that a VPN connection is doing DNS to an external name server? Should not every internet request flow over the vpn from the client to the server. once it reaches the internal vpn server the server should know how to route the internal addresses and for external addresses it could use an external domain name server. the problem described seems like it should not exist. what am I missing?

        • "how is it possible that a VPN connection is doing DNS to an external name server? Should not every internet request flow over the vpn from the client to the server. once it reaches the internal vpn server the server should know how to route the internal addresses and for external addresses it could use an external domain name server. the problem described seems like it should not exist. what am I missing?"

          Thank you, that is what confused the hell out of me too when I read it.

          When I VPN somewhere...I don

          • Re:could someone explain what the issue is here? (Score:5, Informative)

            by Intron ( 870560 ) on Wednesday May 13, 2009 @04:21PM (#27943175)
            Depends on the VPN setup. I don't want my VPN clients sending all of their web browsing through the VPN and then back out through my firewall. I only want the traffic destined for my internal network. On their end, they should have a route table that sends traffic for me through the VPN and everything else through their normal ISP. I can support a lot more users that way.

            • That's a hell of a security risk, having a client connected to both your internal network and external networks simultaneously.

              Every corporate VPN I have ever used has, as part of its function, disabled all network interfaces other than the one it was using once a connection was established. In addition it would prevent any traffic from going through the "normal" connection. The idea was that a machine should never have connectivity to both the internal network and the outside world simultaneously.

              The article poster doesn't need to fix their users' ISPs, they need to fix a horrifically broken and insecure VPN system.

              • Re:could someone explain what the issue is here? (Score:5, Informative)

                by Sparr0 ( 451780 ) <sparr0@gmail.com> on Wednesday May 13, 2009 @04:54PM (#27943733) Homepage Journal

                I have never seen that enforced, and only twice ever as the default setting. It is a client-side configuration option in most VPN software (Cisco, SecuRemote, most Linux VPN clients).

                You want VPN users to stream video or download game patches or do other non-business-related bandwidth intensive operations over the VPN, when they have a perfectly (ha!) good internet connection locally? I hope you have a REALLY big network pipe.

                • Re:could someone explain what the issue is here? (Score:4, Insightful)

                  by networkBoy ( 774728 ) on Wednesday May 13, 2009 @05:20PM (#27944173) Journal

                  Enforced at my work. In addition we don't allow user's personal machines onto the VPN. Since it's a company notebook on the VPN and all traffic goes through the VPN, we also enforce the internal AUP on remote users using the VPN. That means downloading a game patch will get you a stern talking to, downloading porn or torrents of wares, etc. will get you fired.
                  Again, this is all acceptable, because you are on company equipment (even if you are at home). If the case is that employees are being allowed to attach their personal equipment through the VPN to the company's internal network then I really hope you totally trust your employees, because one rogue could catastrophically hose you.
                  -nB

                • I have never seen that enforced, and only twice ever as the default setting. It is a client-side configuration option in most VPN software (Cisco, SecuRemote, most Linux VPN clients).

                  Actually, in the Cisco client it is NOT a client option. The server can override any and every setting in the client, including that one. Our Cisco VPN concentrator, for example, disables split networking the instant you connect.

              • I have also had this experience with VPNs. That said, unless the only VPN connections are coming from well, locked down corporate-issue boxes, doesn't this theory of security amount to "trusting the client" which is generally considered to be a bad idea?

              • Re:could someone explain what the issue is here? (Score:5, Insightful)

                by mellon ( 7048 ) on Wednesday May 13, 2009 @05:17PM (#27944131) Homepage

                I'm not sure what your threat model is, but I suspect you are claiming one of two things: either that the VPN node might act as a router, forwarding packets around your firewall, or that the VPN node might be compromised and used as a stepping-stone onto your network.

                In the case of the router vulnerability, this is something that you can control on the corporate side of things by simply not accepting packets down the VPN tunnel that don't come from the IP address that's the far endpoint of that tunnel. I'm not a VPN expert, but I would be surprised if this isn't how your VPN is configured by default.

                In the case of the stepping stone, this is a fairly weak threat model, for two reasons. First, if your machine has been rooted, there's a good chance that it will phone home out through your firewall even if you route all internet access through the VPN. So it will be a stepping stone to your network anyway.

                Second, if your machine has been rooted, and is running any sort of virus platform, it's going to try to infect machines on your network even if it doesn't have a link to the outside world. If you are genuinely concerned about threats originating on employee laptops, you shouldn't allow them to VPN into your network at all.

                So the point is that forcing the VPN'd node to access the internet through your site is probably going to be a big inconvenience for your users (the kind of inconvenience they will hack around, possibly making you even more vulnerable) and it's not going to buy you any meaningful security.

                Firewalls are great for slowing the spread of infection, and raising the cost of attacking you, but you really do need to secure every node as well, and if someone really wants to get past your firewall, and is willing to expend substantial effort to do so, you probably won't stop them without much sterner measures than the one you're advocating.

                • In the case of the router vulnerability, this is something that you can control on the corporate side of things by simply not accepting packets down the VPN tunnel that don't come from the IP address that's the far endpoint of that tunnel. I'm not a VPN expert, but I would be surprised if this isn't how your VPN is configured by default.

                  You can also filter packets on the receiving end of the VPN. That's how I configured our firewall at work. The VPN tunnel simply looks like another network interface to our firewall, so I apply a slightly less restrictive set of rules to that connection than I do to the default external interface. Giving someone keys to your network just because they are an authenticated VPN user is not a very good idea.

                  My main complaint with DNS tampering is the outright DNS hijacking that Sprint does with their AirC

                • Re: (Score:3, Interesting)

                  by sjames ( 1099 )

                  Machines that connect through a VPN client are only behind your firewall some of the time. They cannot be trusted to be virus free. The firewall needs to keep them, the LAN clients and the servers separate anyway.

                  Another point is that if the machine has been infected, that means that the software on it has been altered. The VPN client software is not immune to this. You may THINK split tunneling is disabled, but are you sure?

                  There may be other issues as well. If you WANT people to come in through their pers

            • MOD PARENT UP: Re:could someone explain what th... (Score:5, Informative)

              by HappyDrgn ( 142428 ) on Wednesday May 13, 2009 @04:39PM (#27943499) Homepage

              This is in fact why NXDomain breaks things in the way the poster describes, however, unless you're the kind of employer who wants to see EVERYTHING your subordinates are doing it's not actually the best practice to filter everything through the VPN.

              Filtering everything through their VPN increases overall costs in bandwidth and hardware as Intron indicated. These are very real, very costly expenses that many employers overlook when implementing broad policies... and it's a fantastic point you raised that all too many companies forget.

              Why should my connection to slashdot.org, for example, be secure on the company VPN? My ssh and nfs connections have very real reasons to be secure however!! On the other hand you could fix this by filtering DNS traffic through the VPN, but not web traffic. The cost of DNS traffic is marginal comparatively to other services, but the benefit for companies facing these specific issues is obvious.

              • Re: (Score:2, Informative)

                by blingingToad ( 787967 )
                I do not think your ssh connection needs to tunneled through a VPN at all. Ssh is a secure way to transmit and recieve information without a VPN. I suppose you could use a VPN with ssh, but it seems redundant. NFS is another matter, though.

                • Re: (Score:2)

                  by Twanfox ( 185252 )

                  Not all systems that a technician might SSH into are visible from the outside world. Sometimes, VPN gets you more than just encryption. It gets you visibility to far more systems than those on the Internet get to see.

                  • Re: (Score:3, Informative)

                    by Big Boss ( 7354 )

                    SSH tunnels get around that without difficulty. If you know the address, it's as simple as assigning local port 2222 to 10.1.0.100:22 and you can now SSH to that machine by connecting to localhost:2222. Get a SOCKS capable SSH client, and you don't need to set up the tunnel for each connection.

                    • Some systems (e.g. PCI DSS controlled systems) are forbidden to be directly exposed in that sort of manner - in which case a VPN with two factor authentication would be required.

              • As another poster in this thread pointed out...security threat allowing you to connect to multiple networks at once.

                Every vpn setup I've had...locks down all network connections, and all ..through the vpn connection only while it is connected. Indeed all traffic goes through it.

                This is just the security measures they have had...they do not want to risk having machines connected into their networks, that are simultaneously connected to other networks or the internet...I kinda figured most any setup would w

        • Re:could someone explain what the issue is here? (Score:5, Insightful)

          by omnichad ( 1198475 ) on Wednesday May 13, 2009 @03:25PM (#27942249) Homepage
          Unless it's set to send ALL traffic over the VPN, you have to resolve the hostname in order to decide if the DNS name is on the VPN or on the Internet.

          Even if all traffic goes down the VPN wire, it's probably making those requests to the same DNS servers OVER the VPN. Bust since it's still the same DNS servers, it still gets the same results.

          The IT guy would have to intercept all DNS requests over the VPN and proxy them to his own DNS server. That's not a bad answer. Too bad I'm buried in the middle of this thread.
          • Luckily, it isn't that busy a thread.

            The IT guy would have to intercept all DNS requests over the VPN and proxy them to his own DNS server. That's not a bad answer. Too bad I'm buried in the middle of this thread.

            You're right. If the VPN is set-up to send all traffic over the tunnel, then the host *should* resolve using the company DNS servers. If the VPN is set-up for split tunneling, then the DNS will goto the ISP DNS. However, few VPN clients have the option to capture all DNS requests.

            The sol

            • Re: (Score:3, Insightful)

              by omnichad ( 1198475 )
              Putting your internal server records in public DNS is a security risk, since it exposes details of the internal network layout. I guess the best answer is to use any reliable DNS server out on the Internet that *doesn't* mangle its results. 4.2.2.1 or another major ISP's DNS servers.

            • Re: (Score:2)

              by mellon ( 7048 )

              You didn't understand the point in the comment you're replying to. Suppose you have a VPN setup. Starting from not being connected to the VPN, you plug your laptop into an internet connection somewhere. You get an IP address and DNS server IP addresses from DHCP. The DHCP client configures your host to resolve DNS using that IP address.

              Now you turn on the VPN. This does not (necessarily, and clearly does not in the case we're discussions at the moment) change the IP addresses your laptop is config

              • If it's able to do this reliably, this isn't a bad solution, but it sounds like the VPN software we're talking about at the moment doesn't do this, because if it did, the person who posed the original question wouldn't be having this problem.

                I'm not a VPN expert, but if there is VPN software which does this, then maybe they should just require all employees (or at least ones with the crappy ISPs) to use this software, instead of VPN software which doesn't have this feature.

        • Some VPNs only route traffic meant for certain destinations through the VPN as one network interface and allow traffic to the public Internet use the actual established connection. Further, it sounds as if he's placing DNS servers for the VPN-connected network in the adapter confirguration in addition to any DNS servers that were assigned by DHCP or PPoE from the ISP.

          This setup will work if the client machine sees failures from the ISP's DNS then checks the VPN's configured DNS, but it will still always cre

          • Re:could someone explain what the issue is here? (Score:5, Insightful)

            by pthisis ( 27352 ) on Wednesday May 13, 2009 @03:48PM (#27942667) Homepage Journal

            Some VPNs only route traffic meant for certain destinations through the VPN as one network interface and allow traffic to the public Internet use the actual established connection.

            They should be checking the internal DNS servers first (which should not promulgate requests up to public servers), and then the public servers.

            Doing in the other order sends internal information (server names) over the public network.

            • Doing in the other order sends internal information (server names) over the public network.

              I'm not an expert. Isn't such information usually not routable (did I spell that right?) anyway?

        • Re: (Score:2)

          by Malc ( 1751 )

          I've had problems with Cisco's VPN client where it was using a local DNS server rather the remote one on the work network. It's possible that it might have been when the local network had a similar network (e.g. at an airport, on a 10.0.0.0/24, versus the work network of 10.0.0.0/16), but I don't remember. The version I have now works.

          The story description sounds like the VPN client uses local DNS unless look-up fails, and then it goes to DNS server at the other end of the VPN tunnel. This is clearly a s

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      Good luck in finding an ISP that doesn't screw up the DNS in some way.

      • Re: (Score:2)

        by vlm ( 69642 )

        apt-get install bind9
        echo nameserver 127.0.0.1 > /etc/resolv.conf

        Trivial, takes about two minutes, easily scriptable, blah blah

        • Re: (Score:2)

          by Z00L00K ( 682162 )

          Unfortunately you will have to address forwarders too for access to the world and then you are toast again.

          Unless you have your own directory or can find an open DNS that isn't messed with.

    • Re:This is an easy one. (Score:5, Insightful)

      by TheLink ( 130905 ) on Wednesday May 13, 2009 @02:48PM (#27941669) Journal
      Actually, the VPN config is insecure (screwed up?) - when you are using the VPN the DNS requests should be going through the VPN tunnel, and not in plaintext to the ISP.

      • Re: (Score:3, Informative)

        by hey ( 83763 )

        Good point. They should thank the ISP for this alert.

      • Exactly. When I connect (using Checkpoint, but most other VPN software will do it as well) it changes the resolver configs on my system so that now I'm using the internal company DNS.

        If his VPN solution doesn't offer this to him, he needs to get one that does.

      • Re:This is an easy one. (Score:5, Informative)

        by IceCreamGuy ( 904648 ) on Wednesday May 13, 2009 @04:06PM (#27942943) Homepage
        You are referring to what is known as "Split Tunneling;" which is a legitimate, albeit less secure, VPN configuration. Basically when split tunneling is enabled the client workstation's default gateway is still it's local gateway and DNS requests get routed by the client to the appropriate DNS server, whereas in a non-split tunnel the default gateway is the remote gateway (which obviously has no way of routing to the local network) and all DNS requests go encrypted through that. There are several reasons someone would want to do this:
        • You need people to access their local printers/network resources and don't have some kind of pass-through ability
        • You have limited bandwidth at your remote site and cannot handle the Internet usage that would be NATed through
        • Your gateway does not support NAT on VPN tunnels and your clients need Internet access
        • You don't realize what you're doing

        Either way, what I do when I have some kind of weird situation where a user needs to change their TCP/IP config routinely is just put a couple shortcuts with pretty icons on their desktop that point to batch scripts that run a netsh script. You should be able to completely change an IP configuration on a Windows box with this utility, the user just runs "home.bat" when they're home and then "office.bat" when in the office. A Google for "netsh exec" should give enough info to get started.

        • Re: (Score:2)

          by Malc ( 1751 )

          This also makes a lot of sense if you're a long way away from the VPN end-point at the corporate network. Yes, it is a little less secure, but probably a reasonable compromise. We have people who VPN in to the corporate network in California from Australia, China and Europe. There's no need to route all internet traffic over the VPN as it adds hundreds of ms of unneeded latency. All DNS should go over the VPN, which still seems to give poor results for DNS lookups that attempt to return IP addresses to

        • Re: (Score:2)

          by ei4anb ( 625481 )
          If he needs Split Tunneling to access local resources or do web surfing outside the VPN then he can use a reliable external DNS like 4.2.2.2 instead of his (small) ISP DNS.

    • I suspect many people don't have a choice. Of the two broadband providers who serve me, all three do this. The local cable company (Charter) turned it on. When their tech support proved unable to even understand my complaint, let alone fix it, I bailed. Months later the new company (TDS Telecom) started doing it. At least their tech support understood me, but they were unable to turn it off. Sure, I can use OpenDNS, or pinch DNS service from elsewhere, but providing functional DNS is a reasonable base

  • Provide your own DNS? (Score:5, Informative)

    by QuantumRiff ( 120817 ) on Wednesday May 13, 2009 @02:21PM (#27941191)

    Last time I setup a VPN, was with a Cisco PIX firewall, (its been awhile) but there was a spot to specify which DNS servers to use when connected to the VPN. I had specified that when connected, they would use our DNS, since they otherwise couldn't resolve \\file-server\share or whatever..

    • Re:Provide your own DNS? (Score:5, Informative)

      by nine-times ( 778537 ) <nine.times@gmail.com> on Wednesday May 13, 2009 @02:30PM (#27941337) Homepage
      Yeah, honestly I'm a little confused by the question. If you want to use DNS to connect to internal servers via VPN, then don't you want to route your DNS traffic through the tunnel to use internal DNS servers? And once you're doing that, how could the ISP possibly hijack that DNS traffic? It's encrypted.

      • Re:Provide your own DNS? (Score:5, Insightful)

        by Bandman ( 86149 ) <`bandman' `at' `gmail.com'> on Wednesday May 13, 2009 @02:35PM (#27941427) Homepage

        You're right. It all boils down to misconfigured VPN

      • Re: (Score:2)

        by flajann ( 658201 )

        Yeah, honestly I'm a little confused by the question. If you want to use DNS to connect to internal servers via VPN, then don't you want to route your DNS traffic through the tunnel to use internal DNS servers? And once you're doing that, how could the ISP possibly hijack that DNS traffic? It's encrypted.

        It may be that the list of DNSes for the computer to check starts with ISP DNS first, then if that fails it next tries the VPN's DNS.

        Of course, if the ISP is hijacking lookups instead of letting them fail, that's going to screw everything up.

        Verizon and FairPoint does this. Alas, there's no other option I know of that can beat the fibre-optics to the last mile. But at least the aformentioned provides an opt-out DNS server to use. Good luck getting it out of their tech support, as you will spend 10-15 mi

        • Re: (Score:2)

          by pthisis ( 27352 )

          It may be that the list of DNSes for the computer to check starts with ISP DNS first, then if that fails it next tries the VPN's DNS.

          That's a misconfiguration. You can't route any internal traffic outside of the VPN. You're publicizing internal server names if you set it up that way.

        • It may be that the list of DNSes for the computer to check starts with ISP DNS first, then if that fails it next tries the VPN's DNS.

          If the client computer is set up that way, that's the user's (or administrator's) fault. You can't really blame is ISP.

    • Re: (Score:2)

      by cenc ( 1310167 )

      Honestly, I too don't understand the problem. In what world would you want to use your ISP DNS for a VPN or anything else for that matter. You should be running your own private DNS for all kinds of reasons, and they are fairly trivial to implement.

      Even the cheapest routers allow you to set the DNS server you use. Most have caching DNS of some sort built in.

    • --Last time I setup a VPN, was with a Cisco PIX firewall,--

      They are still in use. I think they still make them. I know we have one and have not had that problem. I guess I just don't understand why it wouldn't work either.

  • Change VPN settings . . . (Score:5, Insightful)

    by val123456 ( 141284 ) on Wednesday May 13, 2009 @02:21PM (#27941203)

    to force use of internal DNS servers while connected.

    Done.

    • Re: (Score:3, Insightful)

      by KevMar ( 471257 )

      I guess I did not know there was an option not to use the internal servers.

      Our unit has its own domain and dns servers. The zone does get replicated to the central dns servers, but we have to use the Fully Qualified Domain Name of our servers when on computers outside our unit.

      Have the users try the full name of the server and see if that helps.

    • Re: (Score:2, Insightful)

      by Vrtigo1 ( 1303147 )
      We do configure internal DNS servers on the VPN profile (obviously), but we also split-tunnel since we don't want to push all traffic over the VPN (only traffic destined for the internal LAN). If you do an ipconfig/all, it lists both the ISP and internal DNS servers. Normally this works fine because the ISP's DNS server will return an invalid hostname response and the client will query the internal DNS server.
    • Exactly what I came here to say. Your VPN config is broken. Your IT department is doing it wrong. Even without the NXDomain, you wouldn't get there. I'm not sure how you think this has anything to do with your problem. The only way it would work without NXDomain crap would be if you someone has your corp DNS servers inserted AFTER whatever DNS server you got in DHCP from the ISP and waited around for 2 or 3 timeouts before it got to yours. And even then its not going to be 100% consistent behavior dep

  • Use Full Tunnels (Score:5, Informative)

    by Bandman ( 86149 ) <`bandman' `at' `gmail.com'> on Wednesday May 13, 2009 @02:21PM (#27941207) Homepage

    If you're splitting your connection between a VPN tunnel and a non-VPN protected internet connection, you're a security risk to your infrastructure.

    Have your administrator configure full tunnel support where ALL of your traffic goes through the encrypted tunnel. That solves a security problem AND it fixes your DNS problem because you don't use your local internet provider's DNS servers.

    • Re:Use Full Tunnels (Score:5, Informative)

      by L0stm4n ( 322418 ) on Wednesday May 13, 2009 @02:26PM (#27941271) Homepage

      This is called split tunneling. If he disables split tunneling and specifies the DNS servers in the VPN config his problems would go away.

      His users however would tunnel all their traffic through the corporate lan while connected so you may need to setup some kind of filtering or route the traffic through whatever filters you already have. Otherwise these remote workers in hotel rooms will be pulling buckets-o-pr0n through your corp network.

      • Re: (Score:2, Informative)

        by Bandman ( 86149 )

        But that's only a problem when they're connected to the VPN. Don't surf porn while on the VPN, don't get fired. Win/Win

        Just disconnect to download your porn and you're good.

      • Re: (Score:2)

        by TheLink ( 130905 )
        "His users however would tunnel all their traffic through the corporate lan while connected"

        This is not a problem. This is how it should be.

        VPN = Virtual Private Network.

        It's not private if your traffic leaks out to somewhere else.

        When you use your office VPN, you should use it for work related stuff only. If you want to do personal stuff (e.g. download non-work-related porn, MP3s), don't use the office VPN.

      • They should just set up some really draconian rules for VPN users regarding which websites they can surf. Basically, lock out all pr0n, and just about everything else popular too (Amazon, Ebay, news sites, slashdot, Facebook, etc.). Even if the popular sites are allowed for workers at the office, they should be disallowed for people on VPN. Instead, they can be redirected to a page telling them they're wasting company resources, and if they want to surf the web, to simply disconnect from the VPN and use

    • This is true and I every time I set up of a VPN for someone I mention this. That said, for many people, they are likely VPN'd in order to access certain files while needing access to the internet. Browsing through most company VPN connections is painfully slow and inefficient.

    • Re: (Score:3, Insightful)

      by oolon ( 43347 )
      The down side of this is people cannot use their local printers/file servers. I find it really annoying having to reverse tunnel out of corporate VPNs to get access to my local systems. Clearly as others have said any VPN client should change the DNS settings to use the internal DNS before any external one, I didn't know some didn't.

    • Split tunneling is a pretty trivial risk. Your typical home computer doesn't do forwarding (not to mention nothing would know how to route) and if the box is a zombie, it's a zombie - not talking to the C&C servers directly instead of via the corpnet isn't going to impair the bot software.

      Split tunneling has nothing to do with the DNS issue. Configuring internal DNS servers is 100% solid if not essential advice for any VPN.

  • Split-horizon DNS (Score:3, Informative)

    by Dishwasha ( 125561 ) on Wednesday May 13, 2009 @02:23PM (#27941227)

    http://en.wikipedia.org/wiki/Split-horizon_DNS [wikipedia.org]

  • Failing that...

    Why does manually changing DNS servers work only temporarily? Can't you just host a DNS server and give your employees the IP for that? It'd mean having to service DNS requests for all your employees private internet usage plus it might break some CDNs but it seems like the simplest solution.

    You could also loan employees suitable ADSL / cable routers that you configure, something with a decent small DNS server in it that you can configure to serve your intranet hostnames but defer to the user

    • Failing that...

      Why does manually changing DNS servers work only temporarily

      Perhaps that's the reason cron exists: to make sure your DNS servers are reset to your preference despite DHCP mangling them.

  • Our Company webserver and mailservers serve as DNS servers as well.

    There are four in total. We are an ISP, but we are dependant on a larger backbone - so we registered our own DNS servers.

    Also, DHCP on the lan with your own DNS server on LAN side should be fine, and you can also edit the hosts file if all else fails. We have a few (Vista) laptops where we needed to hardconfig LAN side server addresses in the hosts file - but I suspect this has less to do with nxdomain problems than with a larger config issu

  • Stop filtering your DNS, or run a local cache. (Score:4, Insightful)

    by mellon ( 7048 ) on Wednesday May 13, 2009 @02:32PM (#27941355) Homepage

    What's the benefit of blocking your internal DNS? You're firewalled off, or they wouldn't need the VPN. What's going on here is that you're doing something broken - you must have some kind of NXDOMAIN redirector running on the remote machine, and the ISP is doing something wrong, because its NXDOMAIN redirector is fooling your NXDOMAIN redirector. If you just follow the standards, the fact that they have a broken NXDOMAIN redirector wouldn't affect you.

    Another option is to set up a DNS resolver that's reachable from outside your network, and also inside your network, but only answers for your internal names if the query comes from inside. Then configure all your VPN machines to always use that nameserver, and not use your ISP's nameserver.

    Even if your ISP filters DNS and answers in place of your nameserver, you're okay, because as soon as the VPN is set up, all the queries will go across the VPN (since this server is on your local network). At that point you'll start getting answers for local domains because now the query is coming from a local (VPN) IP address.

    This second solution is a bit more work, and of course being a DNS geek I'm biased toward just doing the right thing in the first place, so I recommend just opening up your DNS, but either way ought to work.

  • What small ISPs? (Score:5, Funny)

    by bzzfzz ( 1542813 ) on Wednesday May 13, 2009 @02:32PM (#27941383)

    There are still small ISPs left where you live?

    • I was going to laugh because this is probably true for most people in the US... then I realized that this wasnt funny because this is probably true for most people in the US. I think we need a "Sadly, humorously, funny" Mod...

  • You can run your own DNS servers... (this opens a lot of other possibilities for it's use as well - such as blocking certain sites at the DNS level, or setting up local domain entries for your internal network (without the expense of registering a domain name or three): just make sure you dont set such up using a real, existing domain name that you may at some time want to visit.

    A Linux box with BIND or similar can be a cheap, old box and perform fantastically in this respect. An OS/2 box (if you've got so

  • No VPN software or hardware I ever used does this. It always checks the VPN DNS server first before going to the main one.

    Reconfigure your VPN software, something is wrong.

    YES, NXDOMAIN redirection sucks, but it does not by default interfere the way you think it does.

    If it's servers on your network you need, you could just stick a hosts file entry on their computers to resolve "webserver" to 10.1.200.34 etc.

    • Re: (Score:3, Insightful)

      by tthomas48 ( 180798 )

      I wonder if the actual problem is this:

      1. User goes to internal site, gets ISP not found page.
      2. User goes "Whoops, need to turn on VPN". Turns on VPN
      3. User hits refresh. Still goes to ISP not found page.

      Is he sure this isn't an issue of just needing the user to close their browsers to clear the browser dns cache?

  • and you won't have to worry about it. Your DNS needs to be coming across your VPN tunnel, not from your ISP. Done.
  • I seriously don't understand this. Presumably when users are connected to the VPN then there must be some way of resolving internal names, and this can only be done via your own internal DNS. You can't have the DNS of users' ISPs resolving internal names because that would be silly and would obviously fail. Therefore.......use your own DNS while users are connected to the VPN. A lot of VPN software will do this automatically, but I've done this with OpenVPN by pushing down DNS through DHCP and changing the

    • To add to seqedunum's post. I use OpenVPN too. You don't HAVE to push anything through DNS but can and is probably the easiest. OpenVPN GUI for windows makes it easy for even the dumbest (marketing/sales department) people in the office to use. You can hard code the ip address as the destination in the config. All the user has to do is double click on an icon on their toolbar, login (or use a shared key), and p00f they are connected.

  • This is an unethical practice (Score:3, Insightful)

    by Jane Q. Public ( 1010737 ) on Wednesday May 13, 2009 @03:15PM (#27942071)
    ... and it should be stopped. Forced to stop if no other approach works.

    Redirecting my web request to somewhere else, as far as I am concerned, is equivalent to re-routing my snail mail to their own office if someone has moved. That is not acceptable. I want a "not at this address" notice, nothing else.

  • hosts file? (Score:3, Informative)

    by i.r.id10t ( 595143 ) on Wednesday May 13, 2009 @03:22PM (#27942211)

    A logon script here loads a hosts file that null-routes a lot of known bad (spyware, etc) sites.

    Could you do the same for your internal hosts so that when on the VPN it doesn't even need to do a DNS lookup?

  • Some ISPs already won't let you connect to port 25 on any server that isn't theirs (forcing you to relay outgoing mail through them), ostensibly to prevent zombies from sending spam. The ones that monetize NXDOMAIN could easily do the same for DNS. All they'd need is some flimsy pretext, and maybe not even that.

  • Your VPN is busted (Score:3, Insightful)

    by brunes69 ( 86786 ) <`gro.daetsriek' `ta' `todhsals'> on Wednesday May 13, 2009 @03:53PM (#27942759)

    The first thing your secure VPN tunnel should be doing is altering the client's DNS profile to only use the DNS servers on the other side of the tunnel. Anything else is totally insecure.

  • My ISP recently started pulling this crap.

    In response, I installed bind9 and resolvconf to get data directly from the authoritative name servers.

    It's the old adage "If you want something done right, do it yourself"

  • What you are describing is one part of a general problem. When users are moving around using different networks, various tweaks to the network settings on the computer are often needed. A user-oriented tool to switch networks is needed. Some notebooks (e.g. Thinkpads) already come with such a tool. Otherwise, NetSwitcher is about US$20 a copy. Someone technical sets appropriate settings for each location the user visits. Subsequently, the user just calls up the configuration for 'Home', 'Office', 'Cus

  • Large ISPs (cough, verizon, cough) lie about it? (Score:3, Informative)

    by Medievalist ( 16032 ) on Wednesday May 13, 2009 @05:48PM (#27944583)

    Large ISPs typically provide an opt-out on their sponsored links page that immediately opts you out of the DNS redirection, but I've noticed that some smaller ISPs and CLECs have opt-out links that don't actually appear to do anything. I don't have a good solution for employees using these ISPs, and our employees are getting frustrated because the problem is becoming more prevalent and we can't fix it for them. I've tried calling a few of these smaller ISPs for help, but it's been like talking to a wall.

    That's not limited to small ISPs. Verizon FiOS, for example:

    "Oh, sure, we will let you opt out - just click on the link that shows your router"
    BROKEN LINK
    Hmmm, guess I will click on a similar router...
    THEY ARE ALL BAD LINKS
    Gee, I guess I will click on the "change OS settings" link then...
    BAD LINK

    Somebody's going to point out that you can Google and find where helpful geeks have posted the instructions to opt-out without Verizon's assistance. But that's not the point, really, is it? Verizon had working opt-out links exactly long enough to get a favorable review in Consumer Reports, and then it all mysteriously broke. I cannot explain this coincidence, personally, you will have to come to your own conclusions.

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close