SV: SV: Many A-records

[fih]

Hello thanks for your response.

See my comments below!

Br
fih

-----Ursprungligt meddelande-----
Fr=E5n: John S. Giltner, Jr. [mailto:giltjr at earthlink.net]=20
Skickat: den 6 april 2004 05:48
Till: fih
=C4mne: Re: SV: Many A-records




fih wrote:
> Hello thanks for your response.
>=20
> Yes of cource i was not thinking i must correct my statement. Every IP

> should have only one A-record.
>=20
> Web hosting companies should use one A-records with many Cnames.=20
> Exception to this is when you want to point a whole zone to an IP. ( I

> could be wrong here but i think pointing a whole zone to an IP is=20
> something that will work but I'm not sure it was ment to be)

That may be fine, if the Web hosting company runs and manages the DNS=20
servers for the zone that the hosts they are hosting are in.  However I=20
am not sure how often that occurs.  My guess is that more often than not

things are like at my company.  We have an ISP that runs the DNS servers

for our zones.  We manage the zones ourselves.  We have another company=20
that runs one Web server for us.

If you run and manage the DNS servers and zones, then using CNAME's=20
instead of A records is fine.  But in the end you still have multiple=20
records pointing to a single address.  Using CNAME's can make life=20
easier, as if you change a hosts IP address, you update one record and=20
you are done.  If you move a virtual web site to another host, you just=20
change the CNAME.
>> i agree with you totally. We both hosts web-servers and manage our
own DNS.
>> But i have lerned from this discussion that there is no error in
using A records
>> instead of Cnames. Have a look at RFC2181 section 10.

>=20
> About the dual naming. If i have a certificate protecting www.www.com=20
> and i rename that service for another customer and call it maybe=20
> www.customerzone.com he will get a lot of warnings when trying to=20
> reach that site using https since the certificate was made for=20
> www.www.com. Maybe webservers can have more than one certificate but=20
> then it will be more expensive. If we rename our services so that=20
> different names will be used depending on which customer is asking we=20
> will have to make sure the Href tags does not include FQDN's from the=20
> namespace the customer can't see. We will also have to tell all our=20
> customers to update their DNS zones every time we change an IP. I'm=20
> not saying this is impossible i'm just saying that it's more easy to=20
> instead lift in our external zone on our customers Intranet so that we

> can keep to our SSL certificates and don't worry about remember to=20
> contact all our 50 customers to change the IP on our application when=20
> we change IP.

I'm a little confused on this.  So my comments may not make sense.

If you have a current service www.www.com, you should have a certificate

for this service.  If you get another customer, you should not rename=20
www.www.com, you should create a new service and get a new certificate.=20
  The customers should pay for the certificate, as it is related to
them.

>> I agree with you again and you are pointing right at the problem.
>> My boss wants us to sell our services under different names depending
>> on what customer we have. And i tell him that we will among other
things
>> have problems with certificates. If our service is called www.www.com
and
>> we tell our customer to reach that service using the name
www.customerzone.com
>> it will not work since the certificate was made for www.www.com which
is the
>> proper name for our service. Instead we must sort of create a uniq
custmoer service
>> for all our customers that cannot resolve external DNS names from
thier inside and
>> buy new certificates.

Web servers can have more that one certificate.
>> I know they can if you fire up a WEB server on subinterfaces
>> but I'm not sure it will work with many certificates on
>> one web server listening on only one interface. (i could be totally
wrong here).

As for customers updating their DNS zones every time you change an IP,=20
this goes back to my ealier point.  If you do not manage the zone, then=20
you can not control what the person that does manage it put in.  Even if

you use CNAME's if you move the customers web site to another server,=20
they have to update their record to point to the new CNAME.  Unless you=20
create a unique CNAME for every host you serve, then tell your customers

to create a CNAME to that CNAME.  CUSTCNAME --> YOURCNAME --> A record=20
--> IP address.  This way, you can update "YOURCNAME" and the customer
does nothing

>> The problem I'm trying to describe here is that. We have customers
with internal
>> root nameservers. They can't of course see external DNS names from
their inside.
>> I have suggested that we help our customer to either forward queries
or slave
>> our external zone on thier Intranet so that every time we do a change
they will
>> also see it. And all our certificates will work and so on. But my
boss have asked me
>> if we instead can add names in our custonmers internal zones. So that
www.www.com will
>> for one particular customer be named www.customerzone.com and this i
don't like at all.

>=20
> Please continue the discussion!
>=20
> Br
> fih
>=20
> -----Ursprungligt meddelande-----
> Fr=E5n: John S. Giltner, Jr. [mailto:giltjr at earthlink.net]=20
> Skickat: den 4 april 2004 17:38
> Till: fih
> =C4mne: Re: Many A-records
>=20
>=20
> fih wrote:
>=20
>>Hello guys!
>>
>>I was once told that a network interface should have only one A-record
>=20
>=20
>>and a corresponding PTR record. Since you probably know many people=20
>>likes to tweak this and I'm doing my best to fight it.
>>
>>While fightning it i also gets alot of questions about why we can't=20
>>have many A-records pointing to the same IP. Does any body know if=20
>>there is a RFC or Best practise DNS documentation that i can refer to=20
>>or am I totally wrong??
>>
>>Also if my company likes to sell services based on DNS names and we=20
>>have customers that can't see the external namespace we use for our=20
>>services. They want me to add fake A-records in the customers=20
>>namespace so our services will have different names depending who is=20
>>asking. This i don't like at all and i allready know that i will get=20
>>in trouble with  SSL certificates.
>>In my world we should instead make our service zone available
>>for the customer.
>>
>>In my world a Network interface should have one but only one A-record.
>>
>>Comments please!!!
>>
>>
>=20
> My opinion:
>=20
> When you say "network interface" are you talking logically or=20
> physically?  Or do you really mean IP address?  I hope that you are
not=20
> still just assigning a single IP address to a single NIC.
>=20
> As you seem to be hosting multiple domains on a single host and you
want
>=20
>   one IP address per interface, I assume that this means you are=20
> assigning multiple IP addresses to a single NIC.
>=20
> This may have been fine 10 years ago, possibly even 5 years ago,
today,=20
> no way.  Virtual hosts on Web servers allow a single IP address to=20
> respond to multiple host domain names.  Why have 10, 100, or 1,000 IP=20
> addresses on a single box when one or two can do.
>=20
> As for SSL certificates, get them assigned based on the host name and=20
> not the IP address.  This gives you flexibility in that you can move
the
>=20
> host name from box to box as required.
>=20
> Internal name spaces vs. external name spaces.  That is a preference.=20
> Hiding your internal name spaces allows you more flexibility.  It also

> could help in the security arena, as you are not publishing your=20
> internal name space to the world (depending on how you provide DNS=20
> services).  This also makes it look as if you are providing a=20
> customized, and isolated, environment for your customers.  Publishing=20
> your internal name space externally is less maintenace, as you define=20
> something once and that is it.  But everybody can now see it.
>=20
>  From what little I know, what you are being asked todo is the "norm"
> today.
>=20
>=20
>=20