Re: How does networking (communication) work when in the cloud

On Fri, Aug 1, 2014 at 12:11 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

This discussion about terminology has gotten rather pedantic. The
wikipedia article cited previously states the following example:

"west.example.com and east.example.com are subdomains of the
example.com domain, which in turn is a subdomain of the 'com'
top-level domain."

​"east" and "west" are subdomains only if there's a DNS server somewhere
that claims to be authoritative (via SOA) for those domains.​

So if I owned example.com, I'd have three name servers (assuming I delegate
authority to the sub-domains):
- for example.com (ns1.example.com)
- for east.example.com (ns2.east.example.com)
- for west.example.com (ns3.west.example.com)

NS1, NS2, NS3 are the unqualified names of my name servers. They are
resources of their respective domains.

​If I choose to have servers named "east" and "west", then they wouldn't be
subdomains anymore east.exmaple.com and west.example.com would simply be
resources of the example.com domain.

Are Charles and Ken suggesting that blahblah.dilgardfoods.com is not a
subdomain of dilgardfoods.com?

​Correct. It's a resource in the dilgardfoods.com domain.​

​How do we we know? Again because we​ can ping it. There's a physical
device that will respond.

Domains (and subdomains) are just a way to organize resources, logically.
There's nothing physical about them.

You can't ping the .COM domain.

Originally (and even today by most DNS defaults AFAIK), you couldn't ping
the example.com domain either. But now-a-days, you can set up your DNS
server to redirect to a particular host (usually the www host) so you can
for instance ping dilgardfoods.com but the request is redirected to
www.dilgardfoods.com.

Charles suggested that blahblah.dilgardfoods.com might point to a

publicly addressed "server". Jeff indicated that
blahblah.dilgardfoods.com pointed to the IP address of a "firewall" in
his office.

​Originally when the internet was created, blahblah would have been the
actual server name and it would have had a public IP address. That's just
how it worked. The naming conventions reflect that beginning. Thus you
created a resource record, type A for a HOST, in order to direct traffic to
that server.

The fact that the servers now-a-days are hidden behind NATing firewalls
doesn't change the meaning of the names used. Remember, NATing is
transparent. From the outside, I can't tell if blahblah actually has a
public IP or is behind a NATing firewall.

​