Indeed Pete’s explanation was quite extensive and complete. I would just add, since you are going to have (eventually need) an external domain that’s going to host all this i.e. example.com, I don’t see why you simply would no build the infrastructure around it. Imagine a tree with the trunk example.com and you can always delegate a subdomain to internal servers. such as internal.example.com. You can also have different domain servers for authoritative (outward facing), and a different set for the internal (perhaps the recursive servers) that also feed up the domain but provide additional records for the hosts that are not on the external facing domain. In other words there is nothing stopping you from using the same external and internal domain, fed from two different sets of servers, that provide completely different IP information. IE on the authoritative servers you could have www.example.com pointing to an external IP address that points to a globally routable IP address of a session manager or local director, or what ever redundancy method being using, while having the internal facing domain servers pointing to a local IP address, having additional A records for www1 www2 www3, etc… that are the IP addressed of the internal hosts that make up the “service”. > On Jan 31, 2016, at 11:20 AM, Pete Travis <lists@xxxxxxxxxxxxxx> wrote: > > > 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 -- 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
