exentriquesolutions / nip.io

http://nip.io
Other
1.39k stars 148 forks source link

IP Range support #23

Open weltonrodrigo opened 3 years ago

weltonrodrigo commented 3 years ago

Hi.

It would be great to have something like 10.0.12.155-160.nip.io resolve to:

Better yet, besides ranges, a list like 10.0.12.155-10.0.12.161-10.0.12.163.nip.io which would resolve to:

That would be great for a poor man's load balancer.

Thansk for the great service!

normanr commented 3 years ago

Supporting ranges would make it really easy to use nip.io for DNS reflection attacks, so while it sounds like a nice idea, it's really hard to implement safely.

In what of scenario's would you utilize ranges or lists? For most of the scenarios that I can think of, there's already sufficient control over the DNS servers in use that you can just configure multiple A records for an internal domain, or an already owned publicly reachable domain.

weltonrodrigo commented 3 years ago

My use case is nip.io (previously xip.io) in Kubernetes ingresses. In case you are not familiar, you can think of it as just a cluster of load balancers in front of a group of services.

Problem is: there is no virtual ip, no cluster coordination. Just a bunch of instances (one per cluster node). So, when generating a nip.io domain for it, you have to choose one of the load balancer instances IP. The perfect would be being capable of creating a round-robin dns entry (several A entries under the same name) pointing to all instances. That way, if one is down, you can at least find the others.

So, to clarify, say my Kubernetes cluster has 3 nodes: 10.0.0.1, 10.0.0.2, 10.0.0.3. Now I have 3 nginx instances, each listening on port 80. And my workload, which is, say, a python flask with 3 instances spread over the cluster (Kubernetes make it easy so nginx automatically finds flask under the hood). Another workload would be a java web application.

To make my service available outside of the cluster, I could give users one of nginx instances ip (http://10.0.0.1). But this won't work because then nginx won't know which backend workload I'm trying to talk to. So we need a hostname.

I give users http://10-0-0-1.nip.io and configure nginx to point this hostname to the python application.

A better solution would be to give users a http://10.0.0.1-10.0.0.2-10.0.0.3.nip.io.

Anyways, I totally understand if this is tangential to the primary user case you are solving here. Thanks for this great service.

johnwyles commented 4 months ago

Stumbled upon this older issue and it seems like this could be resolved fairly easily if the user, @weltonrodrigo, doesn't mind a random entry plucked from the array of IPs given. I think roundrobin would be too much for nip.io to keep track of. Would that solve the problem? I could submit a PR for this if I hear feedback on whether that would solve this use case.

rses commented 4 months ago

Thanks for getting in touch.

Roopinder took unwell 30th April and was taken to hospital. Despite the best efforts of his medical team, it is with great sadness that I must inform you that he passed away on 3rd May 2024.

As a family, we would like to preserve Roopinder’s legacy in the form of xp.dev and all he built, but as you may know xp.dev was Roopinder and Roopinder was xp.dev. As such we do not know when, or if xp.dev and Mobius Hosting and all the other products Roopinder created will be actively managed in the future.

As you will appreciate, this is a difficult time and we have only just begun understanding Roopinder’s business. At this time, we do not have access to his bank accounts or customer lists. Therefore, we are responding to each of you as you raise queries / support tickets. We know that he had different subscription models, if you have recurring payments set up, we suggest that you cancel them as we do not know when we will be able to issue refunds.

We apologise for any inconvenience or negative impact that this may have on your own work / business but as you will appreciate, we are powerless to help at this time.

In the last week, our key focus has been organizing Roopinder's funeral. He was laid to rest on Friday 17th May 2024 and will remain forever in our hearts.

We have also been in discussion with lawyers and IT consultants in order to restore services, however the position is not straightforward. Due to the company structure, we are currently unable to directly engage professionals to restore access. This is a legal issue which we are working to resolve.

A number of you are anxious to get access to data, but we have also been contacted by an equal number of clients whose main concern is data security. We take this very seriously (as Roopinder did) and as such we have not made any attempt to access any data until the proper professionals can be engaged with appropriate safeguards in place.

We appreciate this will be disappointing for many of Roopinder's clients but legally, there is nothing we can do at this point in time. I appreciate that it looks like nothing is moving, but there has been a significant number of discussions and meetings to get us to this point*. *In the meantime, we hope that you are able to function with your own backups while we attempt to restore access.

Software development was Roopinder’s passion and xp.dev was his baby. Thank you all for supporting his dream, for however long you did so.

Status updates will be found here: https://xp-dev-recovery.boards.net/thread/3/status-update

On behalf of the family of Roopinder Singh

@. @. XP-Dev.com (Project Hosting): https://xp-dev.com/ Blog: https://roopindersingh.com/ Web Hosting: https://mobiushosting.net Exentrique Solutions Ltd. Tel 0208 1444 014

On Wed, 22 May 2024 at 17:17, John Wyles @.***> wrote:

Stumbled upon this older issue and it seems like this could be resolved fairly easily if the user, @weltonrodrigo https://github.com/weltonrodrigo, doesn't mind a random entry plucked from the array of IPs given. I think roundrobin would be too much for nip.io to keep track of. Would that solve the problem? I could submit a PR for this if I hear feedback on whether that would solve this use case.

— Reply to this email directly, view it on GitHub https://github.com/exentriquesolutions/nip.io/issues/23#issuecomment-2125192302, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMDII3EMOOSXOXH7TGZJB3ZDTAJNAVCNFSM44A4Q3OKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGUYTSMRTGAZA . You are receiving this because you are subscribed to this thread.Message ID: @.***>