Resolving DNS names dynamically - similar to NIP.IO but with personally owned domains.

[ak2766]

What is Happening

I'm about to teach a TLS course to some students I'm looking for a way to automatically issue SSL certificates using custom DNS records.

What is the actual behavior and lacks which without that feature, and what's the fallback (if there is one) while this feature is not implemented yet.

Without this feature, the students would need to pester the TA to get their custom DNS records entered into a local DNS server.

What is Expected

Before this TLS course, we've been using nip.io with docker containers. Specifically, we've been using this DNS record: <student_id>-7f000001.nip.io. This has been working well since each student desk is labelled with a range of port numbers he/she can use for services they create on docker. So, say student with ID 112244 deploys a web service and exposes port 80 on the local host at port 12345, then they can access that service as follows:

http://112244-7f000001.nip.io:12345

I'm now planning to introduce https and have created the necessary entries to haproxy so that a student can access their secure web service at the following URL:

https://112244-12345-7f000001.nip.io

Currently, I've created a self-signed certificate for *.nip.io which works but has the issue with of presenting the usual self-signed certificate browser warning.

Please describe the wanted behavior with details of how it could work.

I'm hoping that the dns-proxy-server can be enhanced to have this feature so that anyone can use a domain they own and/or control. The issue with nip.io is that we do not own this DNS domain and as such cannot make use of DNS validation when requesting for certificates. This validation method is something I'd like to cover in a future syllabus of the course.

I hope I've been concise enough with this requirement.

I suspect you'd see a huge uptake in the dns-proxy-server user base if you were to implement this feature!

[mageddo]

Hey, I will try to resume what you asked with my own words to check if I understood it well. So are you proposing DPS to register the stored hostnames by the local database and/or by the docker containers/services to a Certificate Authority like Let's Encrypt?

[ak2766]

Sorry - I wasn't clear.

Let me get some diagrams together to help illustrate what this feature request is about.

Cheers, ak.

EDIT: I'm also renaming this to remove Let's Encrypt from the name.

[ak2766]

I was busy creating a whole story line of my curriculum, but figured this is overkill. So here's a quick summary.

Currently, if I want a URL to resolve to my laptop IP address (or any IP address for that matter), I simply prefix the NIP.IO domain name with the IP as indicated in the NIP.IO documentation.

I'm looking for the same feature in DPS. Here are some examples assuming my custom DNS domain is mydomcain.com:

$ dig @dps +short mservice.127.0.0.1.mydomain.com
127.0.0.1

$ dig @dps +short mservice.172-16-24-31.mydomain.com
172.16.24.31

$ dig @dps +short mservice.0a2f250f.mydomain.com
10.47.37.15

I hope this clears up this feature request for DPS.

[mageddo]

Got this, you would want DPS to implement nip.io resolution features, right?

Sounds me like an interesting feature to be implemented, that feature doesn't look complex to me. Never thought or heard of that feature before.

A doubt, is there an use case which nip.io isn't satisfacting you, it would be the fact you can't customize the domain suffix?

[ak2766]

Yep. You got it now.

The one situation where nip.io isn't working is when trying to implement TLS for services. Bringing back Let's Encrypt into the discussion, the problem is that they severely throttle this domain (50 certificates per week) as you can imagine it is being used by loads of people world wide.

Having DPS provide this feature bypasses this throttling problem.

[ak2766]

Additional Note.

Whenever you are implementing this feature, please ensure that we can do this for any and all IP addresses - RFC1918 or otherwise - since the Let's Encrypt servers need to communicate with the certbot process.

If my external IP address is 45.46.47.48, I should be able to do the same thing - i.e.:

$ dig @dps +short mservice.45.46.47.48.mydomain.com
45.46.47.48

[mageddo]

@ak2766 for now, seems like you can use the Local Solver DB feature, I consider the only difference is that you will need to create the DNS records config file previously.

[ak2766]

Thanks @mageddo. I'm in no particular rush at the moment. Will wait for the feature to testing...

[mageddo]

Hey @ak2766 feature was implemented at 3.32.2-snapshot, can you try it out?

Thanks for the suggestion 🤝 .

[ak2766]

Christmas has come early this year! Thank you kindly.

I'll test it out over the weekend.

[ak2766]

Hey @mageddo - not sure how to use this feature.

I've configured domain in the config to be dummy.com. I've then tried to resolve 10-11-12-13.dummy.com but that failed. I expected it to return 10.11.12.13.

You might have to guide me on what to configure.

[mageddo]

It's supposed to work, Take a look at the docs if haven't yet:

http://mageddo.github.io/dns-proxy-server/latest/en/2-features/stub-solver/

http://mageddo.github.io/dns-proxy-server/latest/en/3-configuration/#stub-solver

[mageddo]

Not the domain there's a new one

[ak2766]

Aha - I see. I had to configure:

"solverStub" : {
    "domainName" : "dummy.com"
  },

Noice work!

[ak2766]

This is working as I anticipated. Will close this ticket now.

[ak2766]

@mageddo I just noticed that I cannot instruct DPS on which IP (or interface) to listen on or attach to.

I do a lot of experimentation on my laptop - LXC containers, QEMU/KVM vms, GNS3 network simulator, Kubernetes in docker (KinD), and Docker itself. Additionally, I run DNSmasq as my caching nameserver. DNSmasq is configured to attach to a particular interface I created specifically for it. My hope was to do the same for DPS so that both can run at the same level with DPS being the primary, which then punts stuff it cannot resolve to DNSmasq.

I'm trying to think of a way I can make this work without running DPS as a docker container. If this is the only way, then so be it. I was just hoping to avoid having it run as a docker container.

EDIT:

To put more context here, this is the number of DNSmasq processes running on my laptop at the moment:

$ > sudo ss -plntf inet|grep :53|column -t
LISTEN  0  32  10.4.xx.y:53      0.0.0.0:*  users:(("dnsmasq",pid=2619,fd=6))
LISTEN  0  32  10.13.xx.y:53     0.0.0.0:*  users:(("dnsmasq",pid=2250585,fd=9))
LISTEN  0  32  10.22.xx.yyy:53   0.0.0.0:*  users:(("dnsmasq",pid=2041484,fd=7))
LISTEN  0  32  127.0.0.1:53      0.0.0.0:*  users:(("dnsmasq",pid=2041484,fd=9))
LISTEN  0  32  192.168.xxx.y:53  0.0.0.0:*  users:(("dnsmasq",pid=2580,fd=6))

DPS wants to listen to 0.0.0.0 which is impractical in my setup!

[mageddo]

Creating a feature request for it. #607