Multiple IPV4 address - ipv4

The IPV4 address is exhausted and IPV6 is being deployed. My question is why should some interface be provided with multiple IPV4 addresses ? If one interface is restricted with one IP address then would not that be efficient usage of limited resources ?

Interfaces can have multiple IPv4 addresses since one interface can host many things. A single physical server can host many virtual servers. Each virtual server can have its own public facing IPv4. There is a lot of inefficient usage of IPv4 addresses. Companies and universities that started using IPv4 early on own huge address blocks but might only have a few public facing IPv4 addresses in use. They are a limited resource which is why we are moving to IPv6.

The main reason that people use multiple addresses on one interface is for protocols that don't support some kind of virtual-host function.
For example it used to be normal to have a separate IP address for each website in the HTTP/0.9 times. Then virtual hosting became possible with HTTP/1.0, but not for SSL, so most websites on one server started sharing an IP address except for SSL enabled websites. And now with SSL-SNI even that is not necessary anymore.
But there are still other protocols that don't support virtual hosting multiple instances on one IP address. So even though putting multiple addresses on one interface is less common than it used to be, the need for it hasn't disappeared completely.

Related

Solution for 1 GCP network-to-many GCP networks VPN topologies that addresses internal IP ambiguity

I have a problem where our firm has many GCP projects, and I need to expose services on my project to these distinct GCP projects. Firewalling in individual IPs isn't really sustainable, as we dynamically spin up and tear down hundreds of GCE VMs a day.
I've successfully joined a network from my project to another project via GCP's VPN, but I'm not sure what the best practice should be joining multiple networks to my single network, especially since most of the firm has the same default internal address subnetwork range for the project's default network. I understand that doing it the way that I am will probably work (it's unclear if it'll actually reach the right network, though), but this creates a huge ambiguity in terms of IP collisions, where potentially two VMs could exists in separate networks and have the same internal IP.
I've read that outside of the cloud, most VPNs support NAT remapping, which seems to let you remap the internal IP space of the remote peer's subnet (like, 10.240.* to 11.240.*), such that you can never have ambiguity from the peer doing the remapping.
I also know that Cloud Router may be an option, but it seems like a solution to a very specific problem that doesn't fully encompass this one: dynamically adding and removing subnets to the VPN.
Thanks.
I think you will need to utilize the custom subnet mode network (non-default), specify non-overlapping IP ranges for the networks to avoid collision. See "Creating a new network with custom subnet ranges" in this doc: https://cloud.google.com/compute/docs/subnetworks#networks_and_subnetworks

Using an IP-Address in URL to HTML Linked Resources (CSS, ...)

A well-known technique is to link resources (CSS, JavaScript, ...) with a separate DNS name for various reasons. Like this:
GET http://stackoverflow.com/
GET http://cdn.sstatic.net/stackoverflow/all.css
(Two different domain names)
Instead:
GET ...
GET http://92.60.242.2/stackoverflow/all.css
(One DNS lookup)
This means that two DNS lookups are required. Couldn't we just use an IP address instead of cdn.sstatic.net in order to save one DNS lookup?
Please assume that it is possible to use an IP host from the point of view of the server. Assume, that there is a dedicated resource serving server with a dedicated IP.
Content delivery networks usually employ some sort of load balancing, often implemented at the DNS level (e.g. the name cdn.sstatic.net resolves to different IP addresses, based on the geographical location of the requester). Hard-coding the IP address would be counter-productive, as the request will always go to the same server (which might still be a load balancer in front of several backend servers, but all of them will be in the same location).

One Server, one domain Many Reverse DNS

I have a dedicated server to host one domain. I have lots of ips. Is it possible theese ips reverse dns ?
Example :
On One Server, and domain
127.0.0.1 Reverse DNS : a1.xyz.com
127.0.0.2 Reverse DNS : a2.xyz.com
127.0.0.3 Reverse DNS : a3.xyz.com
Based on http://en.wikipedia.org/wiki/RDNS you can have multiple reverse DNS IP address with different hostnames. "While most rDNS entries only have one PTR record, DNS does not restrict the number.". It is said not recommended since it depends on programs to really read all replies. there is a discussion in talks on the wiki page about that subject http://en.wikipedia.org/wiki/Talk:Reverse_DNS_lookup "Multiple records".
I might be that in future, program should adapt to this since it is very usual to have many virtual hosts / web servers on the same host.
Yes, you can set a reverse DNS name per IP address. If you have multiple IPs then you can set multiple reverse DNS names.

Can I use IP address as Name Server instead of creating custom Name Server [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I've just bought a VPS to host my website.
One of the problems I've faced during migration from shared hosting to VPS is to setup a Private Name Server.
I've instructed to create two Private Name Servers with the IP I've provided.
Example: ns1.mydomain.com points to 127.0.0.1 (say)
ns2.mydomain.com points to 127.0.0.1
My doubt is, instead of creating such name servers why I'm not allowed to use my IP as name server
I'm trying to enter IP address(of my website) in field where I've instructed to enter Name Servers. (
Enter Your Name Servers:
Name Server 1 :- 123.4.5.6
Name Server 2 :- 123.4.5.6 (see the picture here)
(if I enter ns1.mydomain.com(custom Name Server) which also points to the same IP 123.4.5.6)
if 'X' equals 'Y', why I cannot use the same 'Y' instead of 'X'
if ns1.domain.com wears the IP 123.4.5.6 , why I cannot fill 123.4.5.6 instead of (name Server)ns1.domain.com?
OR If one can access his site through IP and domain.com (where domain.com = IP) why this is not applicable in case of name server (where ns1.domain.com = some IP. and hence I can fill that IP instead of ns1.domain.com)
why this is not possible?
(PS: my question is NOT how to create Name Servers. I could do it.)
1) Questions such as this should really be on ServerFault.
2) 127.0.0.1 is localhost, not a publicly accessible address. Respectfully, if you didn't understand this, you should go back to shared hosting... you will end up spending more time learning to run a VPS than making your site work. (If you were just using 127.0.0.1 as a placeholder, then this doesn't apply.)
3) Most individuals who don't have complex needs should probably just opt to use their domain registrar's DNS servers if available (e.g. NameCheap). If your registrar doesn't offer free DNS, your VPS provider almost certainly does (I know both Linode and Rackspace Cloud do). Regardless of where you are having DNS hosted, you need to use their name servers in your configuration, not addresses you invent. (You're not actually going to run your own name server with djbdns or BIND, right?)
EDIT: Attempt to explain DNS after question clarification.
Your question still isn't really clear, and I think it's because we aren't using the same terminology. DNS is a complicated system and you have to be very precise.
Let me try to explain the how DNS hierarchies are arranged as relates to your situation.
1) You register a domain, example.com. It is in the .com top-level domain (TLD). Each TLD has a single entity who manages the root nameserver for that TLD. In the case of .com, this is Verisign. When someone goes to look up www.example.com, they first talk (through a process that isn't really relevant here) to the TLD's root nameserver.
2) The root nameserver returns the authoritative nameserver(s) for the domain (example.com). This is what I believe you are trying to set. According to the DNS specification, the authoritative nameservers are given by name, not IP. Since you (hopefully) aren't trying to run your own authoritative nameserver, you should give your registrar (who in turn tells the TLD root nameserver) the nameservers designated by your hosting company; these were supplied in the link I gave you in the comments (ns1.ixwebhosting.com, etc.). The reason these need to be names, not IPs, is that your hosting company may need to move IP addresses later. If you were allowed to enter an IP, and they switched IPs, your record would be out of date. By entering a name, the DNS system can properly resolve the authoritative nameserver name to an IP.
3) The client interested in www.example.com, having obtained the name (and resolved the IP) for the authoritative name server for example.com (i.e., ns1.ixwebhosting.com), contacts the authoritative name server and requests the IP for www.example.com. The authoritative name server checks its records and returns the IP that you have told it. That is, you will use your hosting provider's interface (probably a web page you login to... contact them for assistance) to manage the subdomains for example.com, such as www.example.com.
If you don't use hosted DNS, you have to run your own DNS server (e.g. BIND or djbdns). This introduces a whole set of other complications that are beyond the scope of your question. Please just use hosted DNS and let your provider deal with these issues.
You will notice that nowhere here did I mention ns1.example.com. You only need to deal with such records if you are running your own DNS server, which you probably shouldn't be doing.
So in summary:
1) Tell your registrar that your domain uses your hosting provider's DNS servers (from the link I gave you).
2) Tell your hosting provider to use your VPS' IP address for actual host names for your domain.
Does that clear things up?
I had a similar question to this one over at serverfault, but it got voted down but no one offered to explain why it can't be done. After researching the web looking for DNS principles, here is my answer as to why you can't substitute IPs for nameservers. It is long, but it also helps me understand the convention.
Let's say you registered the domain abc123.com, the "com" is the top level domain, the "abc123" part is the second level domain.
When a web user wants to visit abc123.com, he types in abc123.com into his web browser. The browser then contact the DNS resolver (such as google DNS, level3, or opendns -- which is acting as a cache) to query if the DNS resolver has the IP address for abc123.com previously saved. If some one had tried to reach abc123.com previously through this resolver, the resolver should have the IP address for the abc123.com domain name and return the IP to the browser. But if no has ever queried the DNS resolver for abc123.com, the resolver does not have the IP cached. The resolver then need to contact the root DNS server for that information.
The root DNS server works in a way that explains why you can't substitute IP for conventional alphanumeric nameserver names. The root DNS server gets its info from the domain registrars. When you register the abc123.com domain, abc123.com is recorded by the root DNS server; along with the nameservers/IP (optional).
I think why the nameserver names have to follow the FQDN (fully qualified domain name) format is because of the way the root DNS server is designed to work. Example, for ns1.mynameserver.com nameserver name, the guess is that the "mynameserver.com" must exist in the root DNS server for it be able to logically say that ns1.mynameserver.com to be valid. If mynameserver.com does not exist in the record, then ns1.mynameserver.com must not be valid. The same goes for the IP as nameserver name, the root DNS server can never have your IP on record as a valid domain name (because the IP is not a valid FQDN format, there is no numeric top level domain -- ie .42 is currently not a valid TLD).
Going back to the original question as to whether you can use IP addresses as nameserver names. Even if you choose to ignore convention, it is not possible for you to set IP as nameserver names because your registrar won't allow it. If you own abc123.com and you log into your registrar to register nameserver names, the top (".com") and second ("abc123") level domains are locked. You can only enter values for the sub level domain. So what you could end up with is 12.23.45.33.abc123.com as your nameserver name (that is if your registrar allows you to have that many dots).

Business website hosted publicly (for APIs, etc) needs to be accessible ONLY from inside office?

Would appreciate your patience with this question; still learning a lot of things.
My Taxi booking start-up has a website (CakePHP) hosted on EC2 (for reliability) which is a ERP of sorts used only by internal employees. This tool also interacts with the Cabs/Taxis' GPS receivers in that these GPS machines send some data to the public server through some APIs which help decide logic for the Booking process. And as we don't have very strong Net on premises, we've kept it all on EC2.
Now, we are increasingly concerned about leaving information (customer data, vehicle info) like this on the public domain and accessible from the internet and outside the premises by a rogue employee. For our implementation, MySQL replication has already been considered with us reading from a local slave, writing to the master and etc. The only issue being, there's no way non-technical employees would know whether the data is new or whether the replication is broken. Also, we'd prefer our servers online as we don't want to invest in physical security for this hardware.
We are thinking of the following:
IP address based auth; those belonging to the local NAT would be allowed. Problem is we have a dynamic IP.
Computername/MacID based auth; almost no-security once the user finds out. Also, can we read these parameters from Chrome?
Storing a list of IP addresses that login and as there are just 6 employees, we'd be able to monitor it for weird IPs. Not scalable or even secure.
Hosts file configuration on employee PC and this "host" would be configured on apache2 so directly hitting the IP address would do no good. Again, needs one smart employee.
Do help us out!
I think you should look at VPC, its Amazon's virtual private cloud. Its the better option for hosting solutions on EC2 that are private to your enterprise.
it would allow you to create a private network that is only accessible from your computers, with internet facing servers in a seperate subnet.
you have a number if ways of connecting the private subnet to your office, a VPN seems the option here for you (low cost, no special h/w required), see http://aws.amazon.com/vpc/ and http://d36cz9buwru1tt.cloudfront.net/Extend_your_IT_infrastructure_with_Amazon_VPC.pdf
I considered writing this as a comment but don't have enough rep...
I'm not sure where you are from, but in my region, the cost of a static IP is negligible ($10-$50) a month, which is a drop considering the risk of liability you are facing. Then you can secure the server with usernames and passwords, and check the originating IP also.
You may also be able to setup a computer to scrape something like whatismyip every hour to see if the IP changes and update the IP if it changes.