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.
The test server(s) aren't going to be webservers, they're going to be used to test apps..
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.
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@foo.com" or can you use something like "ssh test@foo.example.com"
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??
I've tried asking IRC/support forums, etc.. but not getting any progress..
Thanks for helping me get my head around this..
On Sun, 2016-01-31 at 12:57 -0500, bruce wrote:
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.
If it's wholly internal (i.e. any lookups are from machines within the network), you don't need an globally recognized name. You can use /etc/hosts or dnsmasq.
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@foo.com" or can you use something like "ssh test@foo.example.com"
Even if your home network is hidden behind an ISP NAT router, getting your own domain is quite simple. Providers such as DynDNS (www.dyn.com) or NO-IP (www.noip.com) offer DNS registration (either paid or free with restrictions). You also need a dynamic DNS client to keep them up to date, but most modern routers can do that for you.
poc
Hey Patrick.
Thanks for the reply.
The situation will potentially scale/get to: -50-100 instances on the rackspace/digitialocean cloud -the process needs the ability to externally interface with a few of the boxes/instances via name as opposed to ipaddress (thus the DNS) -the internal processes need the ability to be accessible from the other instances via name (again, the reason for dns) I'd prefer not to do ssh test@1.2.3.4 to instances within the internal boxes/instances --names are much easier.. --the internal machines for the most part are connected to other internal instances/boxes.. -- ie, will not be accessed externally
-while one could manage /etc/host files.. not looking to do that for 50/100 instances.. which is why the dns questions are being posed.
On Sun, Jan 31, 2016 at 1:23 PM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2016-01-31 at 12:57 -0500, bruce wrote:
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.
If it's wholly internal (i.e. any lookups are from machines within the network), you don't need an globally recognized name. You can use /etc/hosts or dnsmasq.
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@foo.com" or can you use something like "ssh test@foo.example.com"
Even if your home network is hidden behind an ISP NAT router, getting your own domain is quite simple. Providers such as DynDNS (www.dyn.com) or NO-IP (www.noip.com) offer DNS registration (either paid or free with restrictions). You also need a dynamic DNS client to keep them up to date, but most modern routers can do that for you.
poc
users mailing list users@lists.fedoraproject.org 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
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@foo.com" or can you use something like "ssh test@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
On Sun, 2016-01-31 at 13:49 -0500, bruce wrote:
The situation will potentially scale/get to: -50-100 instances on the rackspace/digitialocean cloud -the process needs the ability to externally interface with a few of the boxes/instances via name as opposed to ipaddress (thus the DNS) -the internal processes need the ability to be accessible from the other instances via name (again, the reason for dns) I'd prefer not to do ssh test@1.2.3.4 to instances within the internal boxes/instances --names are much easier.. --the internal machines for the most part are connected to other internal instances/boxes.. -- ie, will not be accessed externally
-while one could manage /etc/host files.. not looking to do that for 50/100 instances.. which is why the dns questions are being posed.
I think Pete's reply gives a more complete answer. I was thinking more of the typical home network rather than a large-scale cloud deployment.
poc
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@petetravis.com 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@foo.com" or can you use something like "ssh test@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
users mailing list users@lists.fedoraproject.org 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
On 01/31/2016 09: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.
The test server(s) aren't going to be webservers, they're going to be used to test apps..
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.
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@foo.com" or can you use something like "ssh test@foo.example.com"
yes
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??
Pete and Shawn both give good advice. However, if you'd like a quick solution using a fake domain name *internally* I'd recommend djbdns's tinydns. tinydns allows you to declare yourself AUTHORITATIVE for zones without having to connect to the root name servers.
To test this I just created feefle.farfle. and paired it with 53.53.10.in-addr.arpa. and it worked without a hitch. Combined with dnscache, also part of djbdns, you would have a complete authority/recursive name server setup for your private space.
If this interests you let me know and I'll contact you off list.
Mike Wright
Hi Mike.
What you suggest sounds like what I might need. Contact me, get me your contact data, I'll give you a call. I'll gladly pay $$$ to get this right, And for the right person, this is prob pretty straightforward, where for me, it might take some time. !!
THanks
-bruce badouglas@gmail.com
On Sun, Jan 31, 2016 at 4:22 PM, Mike Wright nobody@nospam.hostisimo.com wrote:
On 01/31/2016 09: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.
The test server(s) aren't going to be webservers, they're going to be used to test apps..
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.
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@foo.com" or can you use something like "ssh test@foo.example.com"
yes
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??
Pete and Shawn both give good advice. However, if you'd like a quick solution using a fake domain name *internally* I'd recommend djbdns's tinydns. tinydns allows you to declare yourself AUTHORITATIVE for zones without having to connect to the root name servers.
To test this I just created feefle.farfle. and paired it with 53.53.10.in-addr.arpa. and it worked without a hitch. Combined with dnscache, also part of djbdns, you would have a complete authority/recursive name server setup for your private space.
If this interests you let me know and I'll contact you off list.
Mike Wright
-- users mailing list users@lists.fedoraproject.org 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
Per mike, and others.
If I understand. I can purchase a domain name "foo.com" I can then use that name to have sub domains, which can then be applied to the "boxes" within the internal network. I'm assuming that there's no additional charge to use the "sub domains" but that these domains can then be applied to the target instances/boxes of a digitialocean, mapped to the ip address of the actual instance as defined when the droplet/vm is created.
So as an example I could buy foo.com
name ip address foo.com 1.2.3.4 nfs.foo.com 1.2.3.5 mysql.foo.com 1.2.3.6 app1.foo.com 1.2.3.7
etc... (there would be a bunch more)
with the name/mapping performed via dns of something like a cloudflare..
Is this getting close to being correct?
Thanks guys..
ps. once I get this nailed down, the process will be to auto spin up a given instance, as well as to perform the dns updates, to create additional instances to perform the testing for the overall project.
At that point, I'll look into chef/puppet/ansible/shell scripts/etc to ease the process..
On Sun, Jan 31, 2016 at 4:22 PM, Mike Wright nobody@nospam.hostisimo.com wrote:
On 01/31/2016 09: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.
The test server(s) aren't going to be webservers, they're going to be used to test apps..
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.
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@foo.com" or can you use something like "ssh test@foo.example.com"
yes
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??
Pete and Shawn both give good advice. However, if you'd like a quick solution using a fake domain name *internally* I'd recommend djbdns's tinydns. tinydns allows you to declare yourself AUTHORITATIVE for zones without having to connect to the root name servers.
To test this I just created feefle.farfle. and paired it with 53.53.10.in-addr.arpa. and it worked without a hitch. Combined with dnscache, also part of djbdns, you would have a complete authority/recursive name server setup for your private space.
If this interests you let me know and I'll contact you off list.
Mike Wright
-- users mailing list users@lists.fedoraproject.org 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
On 01/31/2016 02:03 PM, bruce wrote:
Per mike, and others.
If I understand. I can purchase a domain name "foo.com" I can then use that name to have sub domains, which can then be applied to the "boxes" within the internal network. I'm assuming that there's no additional charge to use the "sub domains" but that these domains can then be applied to the target instances/boxes of a digitialocean, mapped to the ip address of the actual instance as defined when the droplet/vm is created.
So as an example I could buy foo.com
name ip address foo.com 1.2.3.4 nfs.foo.com 1.2.3.5 mysql.foo.com 1.2.3.6 app1.foo.com 1.2.3.7
Absolutely. I use subdomains all the time.
etc... (there would be a bunch more)
with the name/mapping performed via dns of something like a cloudflare..
Is this getting close to being correct?
Thanks guys..
ps. once I get this nailed down, the process will be to auto spin up a given instance, as well as to perform the dns updates, to create additional instances to perform the testing for the overall project.
At that point, I'll look into chef/puppet/ansible/shell scripts/etc to ease the process..
Allegedly, on or about 31 January 2016, Shawn Bakhtiar sent:
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.
You *almost* *have* to do that. On just about all DNS and hosting services that I've played with, you have little control over the DNS server - they only give you a limited interface. While it's easy enough to add more sub-domains that point to your web presence, it's often harder to add records for internal LAN IPs, as sometimes they only ask you for the name you want to create, and they fill in the numerical IPs. And probably only the dynamic IP providers would give you any way to deal with LAN PCs that periodically change their IPs. So, it *can* be easier to run your own DNS server, on your own computers, that resolve LAN addresses, then refer to a DNS server on the web to resolve external IPs.
Of course you may find a better DNS provider, who gives you a really good interface for doing what you want with your DNS records. Then all you have to consider is whether you care that the world can find the LAN IPs for your devices. Bearing in mind that any PC you send email from exposes its IPs, anyway.
-
bruce -
Mike Wright -
Patrick O'Callaghan -
Pete Travis -
Shawn Bakhtiar -
Tim