IP Range support

[exentriquesolutions]

IP Range support

[normanr]

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]

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.