Announcement

Collapse
No announcement yet.

Make clients to look for root DNS first.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Make clients to look for root DNS first.

    Hello !

    Our domain is xxx.com (example) and we have a DNS zone named xxx.com .
    also there are true real urls with xxx.com .
    The problem is that my internal xxx.com records are incomplete and every time the client tries to access a true url like mail.xxx.com (which I don't have in my internal DNS, but it's a real address) they receive "page not found".

    I want my DNS/or the clients to first look at the root DNS servers for xxx.com and only then look at the local dns for xxx.com.
    OR if they can't find the address at the local DNS records then look at the root DNS.

    I already have the forwarder to "All other DNS domains" setup already, I've also included my ISP.
    But it doesn't seems to work as I need.

    Please Help
    Thanks a head
    Maxim.

  • #2
    Re: Make clients to look for root DNS first.

    Regardless of what you do it will still never get the correct address. This is because your DNS server is authoritative for the xxx.com domain and as such it will always go there.

    Easiest thing to do in my opinion would be to add the required 'A' records into your exisitng DNS server.

    Comment


    • #3
      Re: Make clients to look for root DNS first.

      Thanks for your haste reply, although a bit disappointing...
      Someone told me that I should use "Split DNS", on first try it didn't help but can it solve my problem ?

      Comment


      • #4
        Re: Make clients to look for root DNS first.

        Not quite sure what the haste reply remark is all about.

        Split Brain DNS

        From Mark Minasi

        Using Split-Brain DNS

        Take a look at a DNS zone in an AD domain, and you'll notice two things. First, AD stores a lot of stuff in DNS. Second, much of that stuff is information that you wouldn't want anyone outside the organization to see. In particular, a zone in an AD domain contains the names and addresses of your DCs, and you probably don't want the world to have that information.

        One way to avoid running a too-visible network is to keep two sets of DNS books: one DNS zone that the outside world can see and another DNS zone that only the internal organization can see. Some people call this arrangement split-brain DNS. Here's how it works.

        When you ask your preferred DNS server to resolve a name for you, the server first looks in its cache. Then, if the name isn't in the cache and the DNS server holds any zones, it looks in those zones to try to resolve your request. The server goes to a forwarder or to the Internet only if it can't answer the request from its cache or its zones. The key to split-brain DNS is that the DNS server favors the information in its zones over information it can find on the Internet.

        Let's look at an example to see how to set up these two sets of books. Suppose we have a domain named acme.com. On that domain, we have a few DNS addresses that we want the outside world to be able to see—two DNS servers (ns1.acme.com and ns2.acme.com), a mail server (mail.acme.com), and a Web server (www.acme.com). Our externally visible acme.com zone, then, is slim—fewer than a dozen records, all of which refer to routable IP addresses accessible through the public Internet. We create that zone file and put it on our two externally visible DNS servers, ns1.acme.com and ns2.acme.com. (We might not even run our own DNS servers—for a zone that small, many firms simply let their ISP host the files.) Network Solutions has the addresses of ns1.acme.com and ns2.acme.com in its database of all DNS servers, and any DNS server outside of Acme—the kind that a user on the Internet might query—will need to ask Network Solutions' DNS servers where to find the acme.com servers. Consequently, the only servers that outsiders will see are ns1 .acme.com and ns2.acme.com.

        Inside Acme, however, we have an intranet built on nonroutable addresses—perhaps a 10.x.x.x network—that uses some kind of port address translation scheme to connect to the Internet. Anyone inside Acme can initiate communication to the Internet, but people on the Internet can't initiate communication to our internal 10.x.x.x addresses. (To keep this example simple, the port address translation is the only "firewall" that we'll imagine for Acme.)

        On the intranet, we set up a group of DNS servers that act as preferred DNS servers for other machines on the intranet. Those DNS servers use the external acme.com DNS servers as forwarders, enabling people within the intranet to resolve names and surf the Internet. The internal DNS servers aren't simply caching-only DNS servers; those internal servers also hold a copy of an acme.com zone. However, that zone isn't the externally visible acme.com zone that ns1 .acme.com and ns2.acme.com hold. Rather, the internal DNS servers hold an acme.com zone that AD and DDNS built. If that internally visible acme.com zone is an AD-integrated zone, then the internal DNS servers are Win2K DCs for the acme.com AD domain.

        If you've never set up a split-brain DNS structure, you should take a minute to review and think about what's going on. None of the systems within the Acme intranet use the external DNS servers as their preferred DNS-name resolvers—rather, the machines on the intranet look to the intranet's DNS servers to resolve names. Those internal servers hold copies of a zone called acme.com. But the acme.com zone that the internal servers hold is different from the acme.com zone that the outside world sees (although the zone on the internal servers presumably contains the same records that the external servers' zone contains—records that point to the Web and perhaps to mail servers). Instead, the internal zone contains the information that Win2K systems need to locate DCs.

        The outside world will never find or refer to those intranet DNS servers because Network Solutions' DNS servers don't know about Acme's intranet DNS servers. So, an attempt to resolve an acme.com name from the Internet never reaches an intranet DNS server. Even if a user from outside Acme were to attempt to use an internal DNS server, that attempt would fail because the internal server has a nonroutable IP address.
        What you decsribed above comes across as your internal users are unable to access your external resources. Is this correct???

        Adding the relevant 'A' (host) records to your internal DNS structure will allow your internal users to access those external resources when required. Its a very common problem when your internal DNS namespace is the same as your external DNS namespace.

        If your problem is the other way around, external users trying to access internal resources then you need to update your external DNS records to have the correct external address so that people can access it.

        A bit more clarification would be appreciated.

        Comment


        • #5
          Re: Make clients to look for root DNS first.

          Originally posted by wullieb1 View Post
          Not quite sure what the haste reply remark is all about.

          What you decsribed above comes across as your internal users are unable to access your external resources. Is this correct???

          Adding the relevant 'A' (host) records to your internal DNS structure will allow your internal users to access those external resources when required. Its a very common problem when your internal DNS namespace is the same as your external DNS namespace.

          A bit more clarification would be appreciated.
          That is correct.

          So is the only solution is to add those records one-by-one into our internal DNS ?

          Comment


          • #6
            Re: Make clients to look for root DNS first.

            Yes, that is correct
            Tom Jones
            MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
            PhD, MSc, FIAP, MIITT
            IT Trainer / Consultant
            Ossian Ltd
            Scotland

            ** Remember to give credit where credit is due and leave reputation points where appropriate **

            Comment


            • #7
              Re: Make clients to look for root DNS first.

              Yes it is.

              It won't take long to add the relevant records into your DNS structure.

              Comment


              • #8
                Re: Make clients to look for root DNS first.

                Originally posted by Wullieb1
                Not quite sure what the haste reply remark is all about.
                You replied to the OP only 3 minutes after they posted. I'm impressed!!
                1 1 was a racehorse.
                2 2 was 1 2.
                1 1 1 1 race 1 day,
                2 2 1 1 2

                Comment


                • #9
                  Re: Make clients to look for root DNS first.

                  If you don't want to host the entire zone and use split DNS, you can individually add DNS zones internally such as called mail.xxxx.com and add a Host (A) record with an IP address only. However, if you have a number of Hosts to be added and all services for xxx.com are hosted internally, you may as well keep is as split DNS for the xxx.com zone.

                  Comment

                  Working...
                  X