Bringing DNS In-house

Discussion in 'DNS Server' started by K, Nov 5, 2008.

  1. K

    K Guest

    I am looking to move the DNS name servers for our registered domain name
    in-house away from our ISP as we are doing some resilience work and the ISP
    cannot give me a better TTL than 4 hours, which is not conducive to good
    failover (potential 8 hour update depending on when we register change).

    I have 2 servers in my DMZ (Server 2003 SP2) which I have installed DNS on
    and have created a primary zone named domainname.com on one and a secondary
    zone named domainname.com on the other with transfers between them.

    Do I need to set forwarders on these DNS servers to our ISP DNS servers?
    Why or why not?

    Also, when I populate this DNS with records, for example one of my web
    servers in the DMZ, do I populate with the private address of the server or
    the public address?

    I assume the public addresses so that they are the ones handed out in
    requests. But if this is the case, do I also need a CNAME for the private
    address?

    Apologies if these are basic questions but I have only ever worked with DNS
    on private networks where resolution was internal only.
     
    K, Nov 5, 2008
    #1
    1. Advertisements

  2. I think you need to re-analyze the situation.
    I don't think what you are blaming is the problem
    I don't think your solution is the solution
    And I don't think DNS should have anything to do with your "failover".

    When the ISPs adds a Record it is there as soon as the mouse goes "click".
    The time lag comes from other DNS Servers out in "internet-land" because
    they cache the resolutions and they don't "ask" your ISP again until their
    TTL runs out. There is nothing your ISP (or you) can do about that.

    Failover with servers is done through server clustering (such as Windows
    NLB). You are supposed to use the NLB virtual IP# in DNS and not the IP# of
    any specific machine,...then it only needs one machine to still be alive for
    the Cluster to respond to a request.


    --
    Phillip Windell
    www.wandtv.com

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
     
    Phillip Windell, Nov 5, 2008
    #2
    1. Advertisements

  3. K

    K Guest

    I may have not written my OP very well. I am talking about failover on the
    internet feed not the hardware. Hardware is already covered.

    For failover I have 2 seperate internet feeds with 2 seperate suppliers. As
    a result each has different IP address ranges. This means that when one
    fails, the A records pointing to my servers will no longer be valid. That
    means I need to update the A records at the ISP (as we use their name
    servers for our domain name). Their TTL is 4 hours - so worldwide, DNS
    servers will cache this I am looking at a potential 8 hour change time.

    If I bring the DNS in house, I can set a short TTL (our ISP will not change
    this on their servers), and either perform a manual A record change or run a
    script to do so when the primary internet link fails. With a short TTL the
    DNS servers around the world who cached our records will update quicker and
    therefore I can reduce the time before requests go via the backup net link.

    Hope this makes more sense in the context of my OP.
     
    K, Nov 6, 2008
    #3
  4. Hello K,
    I would handle all of you internal dns resolutions internally and those addresses
    that you can't resolve forward to your isp. We have an Exchange geo-cluster
    internally where the ttl is 5 minutes and we are looking at possibly shortening
    that. It is a good practice to forward all requests to your isp thereby
    having the ISP do all the lookup work and not expose your internal ip addresses.


    --
    Paul Bergson
    MVP - Directory Services
    MCTS, MCT, MCSE, MCSA, Security+, BS CSci
    2008, 2003, 2000 (Early Achiever), NT4


    http://www.pbbergs.com

    Please no e-mails, any questions should be posted in the NewsGroup This posting
    is provided "AS IS" with no warranties, and confers no rights.
     
    Paul Bergson [MVP-DS], Nov 6, 2008
    #4
  5. Hello K,
    I would handle all of you internal dns resolutions internally and those addresses
    that you can't resolve forward to your isp. We have an Exchange geo-cluster
    internally where the ttl is 5 minutes and we are looking at possibly shortening
    that. It is a good practice to forward all requests to your isp thereby
    having the ISP do all the lookup work and not expose your internal ip addresses.


    --
    Paul Bergson
    MVP - Directory Services
    MCTS, MCT, MCSE, MCSA, Security+, BS CSci
    2008, 2003, 2000 (Early Achiever), NT4


    http://www.pbbergs.com

    Please no e-mails, any questions should be posted in the NewsGroup This posting
    is provided "AS IS" with no warranties, and confers no rights.
     
    Paul Bergson [MVP-DS], Nov 6, 2008
    #5
  6. That is why you aren't supposed to use two different suppliers. You are
    doing this "home user style" where it is assumed that there is never any
    resources "published" to the Internet therefore the IP of the "home user"
    does not matter. Outbound usage is not effected by the IP change and that
    is the focus of the "home user" way of doing things.

    The proper way to do this is get two *commercial* links (not DSL, not
    CableTV) from the same provider. The links both come into the same router.
    Dynamic Routing protocols on the routers at each end (yours and the ISP) are
    configured to work together to make the failover happen. The Public IP#s of
    the Customer do not change during the process so nothing is effected and the
    fail over is completely transparent. Since both links can be used at the
    same time (when they are both up) you get double the bandwidth while both
    lines are functional.

    This is in fact,..how we are running now right now at this moment. However,
    even at that, this only makes it redundant between us and the local
    "Head-in" at the other end of the lines. If the problem is upstream (and it
    has been every time) then we still go down,...so we went down. But we have
    a very good ISP that has always got things going again in usually less than
    an hour and most of the time less than 30 minutes if the problem was within
    their realm of influence. True perfect redundancy is just a *fantasy* and
    redundancy attempts usually only serve to make the CEOs and the Executive
    feel better emotionally.
    And how is the public going to get to this DNS Server when the IP# gets
    changed on it as well when the failover happens? It will be just as equally
    "unavailable" as the web servers for the same reason.

    I think you may be missing the point of the whole original problem. The
    original problem is your Internet Service is not dependable if it keeps
    going down. The solution is to get a depenable, reputable, internet service
    from a line provider that does not go down because the provider has already
    built the proper redundancy into their service so that it doesn't go down to
    begin with.

    Remember that the ISP (except CableTV) does not typically own or maintain
    the actual line to your location,..that is usually the major phone companies
    and they are pretty solid most of the time in most places. When an internet
    service goes down it is usually not the line or line provider,..it is
    usually something at the ISP's facility. So an ISP that has properly built
    thier facility with proper redundancy and a supply of "replacement"
    equipment kept on site for quick swaps is what you want.


    --
    Phillip Windell
    www.wandtv.com

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    -----------------------------------------------------
     
    Phillip Windell, Nov 6, 2008
    #6
  7. K

    K Guest

    For failover I have 2 seperate internet feeds with 2 seperate suppliers.
    We have a high capacity leased line to a major commercial ISP. To
    elliminate the problem of single point of failure (the ISP) we have gone
    with a different provider. The provider is a national commercial microwave
    ISP - this link is provided over the air.
    The public get the new address because if the TTL is set low enough on the A
    records, it will expire and need to be resolved again. When it does it will
    get the new IP addresses.
    As I have said above, we have a high capacity leased line with a major
    commercial ISP. Their service is not a problem but we are in the middle of
    a major city with A LOT of construction work going on, which has on a couple
    of occasions affected out service - enough to make management decide to
    mitigate against this in future.

    To do this we have gone with a microwave commercial wireless ISP. This
    allows us to mitigate against the physical links being damaged from
    construction.
     
    K, Nov 6, 2008
    #7
  8. I can only "call it" based on my understanding of the environment according
    to the details of your post and how well I understand them. I trust Paul
    Bergson's judgment and he has posted in this too, so if I am way off
    base,..then straighten me out guys :)

    Anyway,....

    No matter what the TTL is set to isn't going to let the Public "get to" your
    DNS because you have moved it behind your Line that has just (theoretically)
    "gone down". The DNS machine itself has an IP#,...that IP# is only going
    to be available from one line or the other,...not both. So it falls victem
    to the same series of events that caused the primary Resource to become
    unreachable by its expected IP#.

    To be able to deal with this at all you will need two DNS Servers,...one
    available from the Lease Line,...and one available on the Microwave Link.
    Then setup your Authoritative DNS Records at your Record Holder (Internic,
    Godaddy, Net Sol,..whatever) to list both of these DNS IP#s with the primary
    one you want used listed first. Then at this point the TTL is irrelevant
    because all they need is the "resolution" from the "perspective" of
    whichever DNS Server they happen to be using at that moment.

    So, you finally accomplish resolution from each line,...then what? What
    is the public connecting to? There has to be something there that the
    public needs to connect to making you want to do this. Will it respond to
    the public no matter which line they come in through?...probably not. The
    Resource (let's say it is a web server) has a Default Gateway that
    associates it with only one line or the other,...not both. When it gets a
    response it does *not* respond out the same path the the request came in
    on,...it responds out the path determined by its own Routing Table with
    respect to the Destination IP# that it needs to reach.

    Now there is Dead Gateway Detection built into Windows but it may not work
    very well or not at all,...I believe it is expected that your "list" of
    Gateways be in the same subnet, although I am not sure about that.

    Q128978 - Dead Gateway Detection in TCP/IP for Windows NT
    http://support.microsoft.com/support/kb/articles/Q128/9/78.ASP

    Q171564 - TCP/IP Dead Gateway Detection Algorithm Updated for Windows NT
    http://support.microsoft.com/support/kb/articles/Q171/5/64.ASP

    159168 - Multiple Default Gateways Can Cause Connectivity Problems
    http://support.microsoft.com/kb/159168/EN-US/

    It is great that you have commercial grade links,...but I think the only
    sure way to make this work is to have both from the same ISP so that Dynamic
    Routing will function properly. It is up the the Line Owners (usually the
    Phone Companies) to make sure they have the redundancy to keep things
    working if a line is cut by construction. So you get two Lease Lines and
    try to arrange with the Phone Company to see to it that each comes to your
    building from a different direction so that a single cut is not likely to
    take out both.

    I'm not trying to be a stick-in-the-mud, but it sounds like you guys went
    out and spent a bunch of money on a second Internet connection without
    determining if it would even serve the intended purpose properly and how
    that would even properly be accomplished. You really have to reaseach this
    stuff out and find out what works (and how) and what doesn't work before you
    commit to spending the money on something.

    If this were water pipes it would work great,..water flows wherever there is
    an opening,....but TCP/IP does not. I know people sometimes call TCP/IP
    links "pipes",...but it is a bad analogy.

    --
    Phillip Windell
    www.wandtv.com

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    -----------------------------------------------------
     
    Phillip Windell, Nov 7, 2008
    #8
  9. In
    <snipped>

    I agree, Phillip with understanding the issue as presented by the OP, as
    well as with what will happen in a 'down' scenario. One thing I would like
    to point out that I have never experienced such an issue with all the
    customers I've ever dealt with, small and large.

    Nonetheless, extrapolating on what you said, the major issue here is if the
    one line were ever to go down, and his public nameservers are published
    based on that specific ISP that went down, there will be a LONGER delay
    changing the IP addresses of the published hostname servers, so the TTL of a
    record becomes a moot point. If redundancy and immediate failover for the
    company's circuit is crucial, te best way to avert this is to keep DNS
    maintained offsite with a reliable hosting company. The OP can even setup
    two DNS servers at a rack-hosted company. They usually have multiple DS3 or
    possibly OC circuits to the backbone, so downtime is highly unlikely. Of
    course there's budget to consider.

    I also like your setup with two separate leased lines with the same ISP.
    Many routers will accomodate multiple WICs (Cisco's terminology) with lines
    coming in from multiple smart jacks from either the same ISP or different
    ISPs. But all in all, keep DNS offsite.

    I was also going to question that if he brings DNS inhouse, he would need
    two separate DNS servers completely segregated from AD and possibly in a DMZ
    (not hosting both internal private and public records, and can be
    problematic especially if the domain names are the same), to protect the
    internal infrastructure as well as allow proper resolution based on the
    'view' of the querying host (whether internal or external). In this fashion,
    he can forward from internal to these servers in the DMZ, then those would
    forward out to something else reliable on the internet.

    But all in all, I agree. Keep DNS offsite.

    --
    Ace

    This posting is provided "AS-IS" with no warranties or guarantees and
    confers no rights.

    Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
    Microsoft Certified Trainer

    For urgent issues, you may want to contact Microsoft PSS directly.
    Please check http://support.microsoft.com for regional support phone
    numbers.
     
    Ace Fekay [Microsoft Certified Trainer], Nov 8, 2008
    #9
  10. K

    K Guest

    Thanks all for replies.

    My idea is 2 DNS servers in teh DMZ to allow name resolution. Each
    published as nameservers using an IP from each line. That would show up for
    all intents and purposes as 4 nameservers but in a failover situation 2 of
    them would become unresponsive as the IP range for them would be down. As
    with any nameserver failure, after a small delay I would expect incommimng
    requests to try the next nameserver which would be accessible down the other
    link.

    These are not public facing web servers - they are puresly for staff to
    access when at other offices, home, on the road etc. We can live with a a
    few minutes of downtime. What we can't live with is the 14 hours it took to
    repair our leased line last time a digger went through it. All the SLAs in
    the world are useless if they have to physically repair something they
    didn't break.

    The default gateway of the web servers is a set of Cisco ASA boxes in
    failover pairing. This deals with in/out traffic - when one line goes down
    it jumps traffic to the other. As far as web servers are concerned the
    default gateway stays the same.

    If it transpires that routing tables are an issue on the servers, then as
    our users will be aware that 10 minutes or so downtimes is possible, I can
    have the servers flush the routing table when the link goes down using a
    script.
     
    K, Nov 9, 2008
    #10
  11. In
    <snipped>

    I'm not sure if this will work as planned due to not only caching of the
    records, but caching of the hostname servers themselves by DNS servers and
    the local resolver service. You would need to test this failover to ensure
    it works as planned.

    I've never had a problem hosting hostname servers offsite whether with the
    registrar or DNS servers at a rack hosting company. Honestly it sounds like
    additional overhead to maintain, but if your test results indicate it's a
    viable option, you may have something. Test it first!

    Ace
     
    Ace Fekay [Microsoft Certified Trainer], Nov 9, 2008
    #11
  12. Hi, Ace
    You reinforced and clarified just what I was thinking. I just didn't know
    about the multiple WIC thing with different ISPs. But I don't think I would
    want to do it anyway,..dunno,..it just doesn't "feel" right to me. And then
    there is the flawed premise that two ISPs means the two lines will
    physically come to the building from two different directions. In reality
    the lines are owned by the Line Providers (typically phone companies) and
    not the ISPs,...and at that it would be the *same* phone company even if it
    was two different ISP and therefore the lines would probably come in the
    same way and would get cut at the same time in a construction accident. The
    Satelite Link was a good way to dodge that one, but then they create their
    own problems such as "lag" caused by distance, rain fade, and heavey cloud
    cover blockage.

    --
    Phillip Windell
    www.wandtv.com

    The views expressed, are my own and not those of my employer, or Microsoft,
    or anyone else associated with me, including my cats.
    -----------------------------------------------------
     
    Phillip Windell, Nov 10, 2008
    #12
  13. In
    Good point about satellite and lag. And yep, if there were two providers,
    they still use the same Layer 2 infrastructure from the CO in the local
    area, with the only difference having their own PVC to their respective
    carriers. So if the physical line goes down from the pole, etc, both are
    done. Rackspace... :)

    Ace
     
    Ace Fekay [Microsoft Certified Trainer], Nov 12, 2008
    #13
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.