can dns take 1 ip and use cname to trans?

[s_m_b]

Problem we have:
We are about to switch web servers and those in power want it to be
'seamless'. For various reasons a short ttl was rejected.
Because we run the two servers in our dmz, the redirect from server (old)
to server (new) has to use the external ip not the internal one.
Whilst the external one works for the internet, we're blind from the
network (again various reasons) whilst its on, so I need to fid a way to
get the redirect ip picked up by our internal dns and somehow translated to
its dmz one.
The obvious solution, I thought, was a cname 'www2' for the internal ip
that could then be used by the A record for the external address.

Seems not, though. Is there another way around this one?
in simple terms we need to do

'new server external address' -> 'new server internal address'
where the external one is used by IIS redirect, and networked PCs cannot
get to this address.

 

[Herb Martin]

Problem we have:
We are about to switch web servers and those in power want it to be
'seamless'. For various reasons a short ttl was rejected.

That was likely an ignorant (meaning without the knowledge to understand
the problem) 'decision'.

What possible reason would this be rejected other than failure to plan
which YOU seem to be doing?

Because we run the two servers in our dmz, the redirect from server (old)
to server (new) has to use the external ip not the internal one.

Just remove the old one, and keep them both online until the (LONG) TTL
expires and no one is still using the old one.

Whilst the external one works for the internet, we're blind from the
network (again various reasons) whilst its on, so I need to fid a way to
get the redirect ip picked up by our internal dns and somehow translated
to
its dmz one.

The way you are TRYING to do it has nothing to do with DNS -- you just
put a redirect in ALL the web pages (someone may be bookmarked deep
inside) of the old web server.

This is not the best way to do it, because playing with DNS records and
reducing the TTL is EASY.

The obvious solution, I thought, was a cname 'www2' for the internal ip
that could then be used by the A record for the external address.

No, CNAME give you two names ro ONE Server IP address.

Seems not, though. Is there another way around this one?
in simple terms we need to do

Yes, do it right -- they way you knew how to do it.

You may have to EXPLAIN this carefully to whoever it making decisions
but that is the best way to get "around this one".

 

[s_m_b]

Well thanks for wonderfully sarcastic post.
I myself am responding to other people's lack of planning, not my lack of
planning.

That was likely an ignorant (meaning without the knowledge to
understand the problem) 'decision'.

What possible reason would this be rejected other than failure to plan
which YOU seem to be doing?

Mainly our ISP cannot guarantee an immediate response for making DNS
updates. They expect notice of several hours.

Just remove the old one, and keep them both online until the (LONG)
TTL expires and no one is still using the old one.

were it that simple. The new one has to be proved (please don't ask)
before we remove the fallback (the old server)

The way you are TRYING to do it has nothing to do with DNS -- you just
put a redirect in ALL the web pages (someone may be bookmarked deep
inside) of the old web server.

Again, were it that simple....

 

[Herb Martin]

Well thanks for wonderfully sarcastic post.
I myself am responding to other people's lack of planning, not my lack of
planning.

Not sarcastic at all. I presumed *YOU* were not the one making this
ignorant decision. Had I believed you were responsible I might have
avoided pointint out the ignorance.

FYI: Sarcasm would be "That is a BRILLIANT <WINK> decision".

Then I went on to explain how you can take the ignorant requirements
and make it work and how CNAMEs have nothing to do with this.

You received the technically correct answer you requested and you
received confirmation that those doing this don't know what they are
doing.

Unless it is YOU there is no reason to be offended -- actually there
isn't really reason if it is you, but that wouldn't stop many people.

 

[ProAm]

Well thanks for wonderfully sarcastic post.
I myself am responding to other people's lack of planning, not my lack of
planning.



Mainly our ISP cannot guarantee an immediate response for making DNS
updates. They expect notice of several hours.





were it that simple. The new one has to be proved (please don't ask)
before we remove the fallback (the old server)




Again, were it that simple....

Hey s_m_b, I and many others here have learned like 'everything' from
these guys [Herb, Kevin, Jorge etc - thanks], never any malice.

If I understand correctly, you [plural] are not in control of your dns
i.e. your ISP is the dns admin? When you say that the ISP needs several
hours notice, is that for one of their tech guys to physically alter the
dns or is that period of notice due to some other reason?

The optimum situation is for you/your tech to have admin access to both
the web and dns servers. Planning ahead would have the new web server
online in the dmz and tested from inside/outside. As Herb says, the dns
changes are very quick and easy to do, provided it's in-house and not
via a 3rd party.

 

[Herb Martin]

s_m_b wrote:
Hey s_m_b, I and many others here have learned like 'everything' from
these guys [Herb, Kevin, Jorge etc - thanks], never any malice.

If I understand correctly, you [plural] are not in control of your dns
i.e. your ISP is the dns admin? When you say that the ISP needs several
hours notice, is that for one of their tech guys to physically alter the
dns or is that period of notice due to some other reason?

The optimum situation is for you/your tech to have admin access to both
the web and dns servers.

This is one of the main reasons that I always suggest the REGISTRAR
is a better place than an ISP to host DNS.

Most registrars give the owner of the name a web page to configure their
own entries.

It isn't perfect for two reasons, but it is under the "owner's control":

1) Most of these have a delay from change to autoupdate of the DNS
servers

2) TTL which is cached by other servers resolving your names.

Planning ahead would have the new web server online in the dmz and tested
from inside/outside. As Herb says, the dns changes are very quick and easy
to do, provided it's in-house and not via a 3rd party.

They can also be automated by a script (DNScmd.exe), and could work
off a "monitor" script that somehow analyzes the paths to/from the
Internet.

This still leaves (at least) the problem of TTL needing to expire on
"foreign
servers".