Many A-records

fih frhak at hotmail.com
Fri Apr 9 18:51:57 UTC 2004


Clarification:

First of all we do everything webhosting, mailrouting, server hosting and so
on and our customers are always direct connected to us.

What i ment in this part of the dicussion was that:

If we have a customer that don't see the external DNS namespace from their
inside. That means they can't resolve external DNS names from their inside
and only sees thier own internal DNS zones and most probably have internal
root nameservers. They will not be able to see the external zones we have
that we use to provide services for our other customers than can resolve
external DNS names from their inside. To solve this i have recomended these
customers to either forward queires about our external zone to a DNS
provided by us or to slave up our external zone on their internal DNS
servers. If they do this they will be able to reach our services using the
same name as everybody else. This will cause all our certificates to
function and when we decide to change an IP of a server they will see that
change without doing anything.

I have been asked if it's OK that our customer adds a DNS record in their
internal namespace pointing out the IP of our service. If they do that our
service will get a different name since that customer (of cource) don't have
the same zone names on their inside as we use for our services. If they do
that our certificates will not work correctly, when we change an IP they
won't see it and if the code in our applications includes references to the
namespace our customer can't see that application will fail.

Happy eastern!

Time for another beer!

fih





"John S. Giltner, Jr." <giltjr at earthlink.net> skrev i meddelandet
news:c56ms2$o5c$1 at sf1.isc.org...
> Jonathan de Boyne Pollard wrote:
>
> > JSGJ> I have a basic understanding of DNS, not really in-depth.  My
> > JSGJ> idea of the:
> > JSGJ>         CUST CNAME --> YOUR CNAME --> A record --> IP address
> > JSGJ> was a attempt to reslove my understanding fih's issue.  Where
> > JSGJ> "YOUR CNAME" was a CNAME in a zone that fih owns and manages
> > JSGJ> Which was basically, he does not want to have to tell his
> > JSGJ> customers to update their DNS entries for host names that
> > JSGJ> point to servers he runs.
> >
> > My reading of
> >
> >     f> They want me to add fake A-records in the customers namespace
> >     f> so our services will have different names depending who is
> >     f> asking.
> >
> > was that the company asked him to set up the company's content DNS
> > servers to provide content DNS service for his customers' domain
> > names, because the company's content HTTP servers supported virtual
> > hosting.  In other words: his company was providing _both_ content
> > HTTP _and_ content DNS hosting services to its customers.
> >
>
> True, that is what he had in the post.  He sent me a private e-mail in
> which he said he did not want to have to tell his customers to update
> their DNS servers when he moved their Web servers from one box to
> another.  I am having trouble following what it is his company does.
> Here is quote from his private e-mail to me.  The last sentence talks
> about notifying his customers to update their zones.  His descriptions
> of what he is attempting to do, or fighting not todo is very confusing.
>
> "About the dual naming. If i have a certificate protecting www.www.com
> and i rename that service for another customer and call it maybe
> www.customerzone.com he will get a lot of warnings when trying to reach
> that site using https since the certificate was made for www.www.com.
> Maybe webservers can have more than one certificate but then it will be
> more expensive. If we rename our services so that different names will
> be used depending on which customer is asking we will have to make sure
> the Href tags does not include FQDN's from the namespace the customer
> can't see. We will also have to tell all our customers to update their
> DNS zones every time we change an IP."
>
>
>



More information about the bind-users mailing list