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@xxxxxxx" > or can you use something like "ssh test@xxxxxxxxxxxxxxx" 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
