You're a bit mixed up on the roles and nomenclature involved, let's try
to sort it out.
On 01/31/2016 11:57 AM, bruce wrote:
Hi.
Researching dns/naming. (sortof fed!!)
Assume I have a server -rackspace/digitalocean/etc.. And I and I want
to serve the DNS via something like cloudflare.
CloudFlare does provide authoritative DNS services, but their bread and
butter is a distributed cache layer in front of your web application.
If you're using the cache functionality, the DNS A records for your site
will point at CloudFlare, and users will mostly be served content from
the cache; the cache is transparently populated from your real server.
Authoritative DNS service works the same way regardless of the provider,
so they really only differentiate on implementation details and the
robustness of their infrastructure. Something, somewhere, needs to be
the source of truth for
example.com records. Some providers provide
some special sauce on top, typically reporting functionality.
The test server(s) aren't going to be webservers, they're
going to be
used to test apps..
You don't need the cache thing at all then. You need a globally
verifiable way to associate
foo.example.com or
example.com with the
relevant servers' IP addresses.
As far as I can tell, most of the sites say you need to already have
a
"name" from a domain name provider. That can't be right, can it!! One
can have a dns process internal to an org, providing dns names to
machines all over the place. Granted, those machines/names might be
internal/private.
That's right. You must obtain a domain name from a registrar, who may
or may not also provide an authoritative DNS server for you. You
shouldn't be surprised by the registration requirement; we can't all
start spinning up
foo.google.com or
foo.fedoraproject.org sites.
You're right that devices that are not public facing do not need public
DNS. You can also choose to run a DNS resolver inside your environment
that provides authoritative name services for a domain name that's not
publicly registered; it's routine for ActiveDirectory or IPA deployments
to do this. Whatever names you set up there are resolvable from the
inside, but the general internet doesn't know or care that you're using
bruce-example.com unless you do public registration and public dns too.
So, does one need an "actual" real name for an externally
facing
server in order to process the DNS so one can do a "ssh test(a)foo.com"
or can you use something like "ssh test(a)foo.example.com"
Right. I can't resolve
foo.com unless you register a public domain name,
set up authoritative DNS servers with the registrar, and establish an A
record for
foo.com with the authoritative DNS service.
If you personally are the only person that cares that
foo.example.com is
at 265.17.34.2, then using letters instead of number is for your
personal convenience and you could put the info in /etc/hosts instead of
paying for domain registration and DNS.
That said, cloud providers often offer authoritative DNS services in
addition to virtual machine instances, and both are accessible through
an API. If you want an instance to be globally name resolvable, a
typical workflow would both instantiate the server *and* set dns records
programatically, via API calls or various API clients. \
When configuration is in code like this, you can use ie the ansible rax
module to spin up new servers, and metadata for the new servers, such as
their IP address, is available for use in subsequent steps of your
deployment process. You could use IP addresses to set up DNS records,
or you could plug IPs or hostnames directly into configuration file
templates used in your environment. The application doesn't care if it
makes internal API calls to
beehive.example.com or 10.34.128.7, as long
as communication is possible.
At the same time.. if you do need a real/actual "domain name" for the
externally facing box, digitalocean provides for both public/private
networks for the linux instances. If you run a private network, would
you then be able to create your own name for the internal instances
that would be available to the other instances on the private
network??
You could set up an internal authoritative nameserver that operates
inside your private network, but I think it's overkill. If you already
own a domain name for the application, and have some externally
resolvable names, you may as well use it everywhere; if you'd prefer to
scale out configuration changes like /etc/hosts then you can do it with
orchestration tools.
You might also be interested in the ssh client "ProxyCommand" directive
for accessing hosts that are only on the private network. You still
need something to do name resolution inside, but you can hop your ssh
connections through one of the public facing instances to access
anything inside. This would naturally use private IPs; public DNS is
moot at this point, and you need something to authoritatively associate
names with internal IPs.
I've tried asking IRC/support forums, etc.. but not getting any
progress..
Thanks for helping me get my head around this..
I'm honestly not sure what the question is! You want DNS functionality,
but you don't want to pay for the services involved because you only
really need them *inside* your environment? You can do that, but you
need to replicate that functionality inside your environment. I think
you have a solid understanding of what DNS does, but I'm not sure where
you're seeing incongruity with your use case. Unless I'm missing
something, you need to either manage a bind instance inside your
environment, or you need to manage /etc/hosts/ across the environment,
or you need to use the public DNS infrastructure everywhere.
-- Pete