|
|
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.
|
|
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.
-----------------------------------------------------
"K" <no[ at ]spam.net> wrote in message
news:O58uYSyPJHA.5076[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >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.
>
|
|
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.
[Quoted Text] >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.
>>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" <no[ at ]spam.net> wrote in message
news:ujZYUH%23PJHA.3932[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > For failover I have 2 seperate internet feeds with 2 seperate suppliers.
> As a result each has different IP address ranges.
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.
> 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.
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.
-----------------------------------------------------
|
|
|
[Quoted Text] >> For failover I have 2 seperate internet feeds with 2 seperate suppliers.
>> As a result each has different IP address ranges.
>
> 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.
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.
>
>> 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.
>
> 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.
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.
> 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.
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" <[ at ].> wrote in message news:u7802tEQJHA.5044[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >> 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.
>
> 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.
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.
-----------------------------------------------------
|
|
In news:ulhimEQQJHA.1448[ at ]TK2MSFTNGP04.phx.gbl,
Phillip Windell <philwindell[ at ]hotmail.com> requesting assistance, typed the
following:
[Quoted Text] > "K" <[ at ].> wrote in message
> news:u7802tEQJHA.5044[ at ]TK2MSFTNGP05.phx.gbl...
>
> 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.
<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.
|
|
[Quoted Text] >> 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.
>
> <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.
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.
|
|
In news:%23AuI53kQJHA.1012[ at ]TK2MSFTNGP04.phx.gbl,
K <no[ at ]spam.net> requesting assistance, typed the following:
[Quoted Text] >
> 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.
>
<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]" <firstnamelastname[ at ]hotmail.com>
wrote in message news:uSmHjAdQJHA.444[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > In news:ulhimEQQJHA.1448[ at ]TK2MSFTNGP04.phx.gbl,
> But all in all, I agree. Keep DNS offsite.
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.
-----------------------------------------------------
|
|
In news:uNxuDa3QJHA.1396[ at ]TK2MSFTNGP06.phx.gbl,
Phillip Windell <philwindell[ at ]hotmail.com> requesting assistance, typed the
following:
[Quoted Text] > "Ace Fekay [Microsoft Certified Trainer]"
> <firstnamelastname[ at ]hotmail.com> wrote in message
> news:uSmHjAdQJHA.444[ at ]TK2MSFTNGP05.phx.gbl...
>> In news:ulhimEQQJHA.1448[ at ]TK2MSFTNGP04.phx.gbl,
>
>> But all in all, I agree. Keep DNS offsite.
>
> 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.
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
|
|
|