[GH-ISSUE #544] Resolving DNS names dynamically - similar to NIP.IO but with personally owned domains. #185

Closed
opened 2026-02-26 04:34:19 +03:00 by kerem · 17 comments
Owner

Originally created by @ak2766 on GitHub (Aug 23, 2024).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/544

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!

Originally created by @ak2766 on GitHub (Aug 23, 2024). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/544 ## 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!**
kerem 2026-02-26 04:34:19 +03:00
Author
Owner

@mageddo commented on GitHub (Aug 23, 2024):

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?

<!-- gh-comment-id:2307774677 --> @mageddo commented on GitHub (Aug 23, 2024): 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?
Author
Owner

@ak2766 commented on GitHub (Aug 24, 2024):

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.

<!-- gh-comment-id:2308184463 --> @ak2766 commented on GitHub (Aug 24, 2024): 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.
Author
Owner

@ak2766 commented on GitHub (Aug 24, 2024):

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.

<!-- gh-comment-id:2308286826 --> @ak2766 commented on GitHub (Aug 24, 2024): 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](https://nip.io/). 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.
Author
Owner

@mageddo commented on GitHub (Aug 24, 2024):

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?

<!-- gh-comment-id:2308368165 --> @mageddo commented on GitHub (Aug 24, 2024): 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?
Author
Owner

@ak2766 commented on GitHub (Aug 25, 2024):

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.

<!-- gh-comment-id:2308650712 --> @ak2766 commented on GitHub (Aug 25, 2024): 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](https://community.letsencrypt.org/t/certbot-with-nip-io-or-xip-io/142262/14)) as you can imagine it is being used by loads of people world wide. Having DPS provide this feature bypasses this throttling problem.
Author
Owner

@ak2766 commented on GitHub (Aug 26, 2024):

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
<!-- gh-comment-id:2309188378 --> @ak2766 commented on GitHub (Aug 26, 2024): 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 ```
Author
Owner

@mageddo commented on GitHub (Aug 27, 2024):

@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.

<!-- gh-comment-id:2313124507 --> @mageddo commented on GitHub (Aug 27, 2024): @ak2766 for now, seems like you can use the [Local Solver DB][1] feature, I consider the only difference is that you will need to create the DNS records config file previously. [1]: https://mageddo.github.io/dns-proxy-server/latest/en/2-features/local-entries/
Author
Owner

@ak2766 commented on GitHub (Aug 29, 2024):

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

<!-- gh-comment-id:2316928547 --> @ak2766 commented on GitHub (Aug 29, 2024): Thanks @mageddo. I'm in no particular rush at the moment. Will wait for the feature to testing...
Author
Owner

@mageddo commented on GitHub (Nov 7, 2024):

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

Thanks for the suggestion 🤝 .

<!-- gh-comment-id:2463323910 --> @mageddo commented on GitHub (Nov 7, 2024): Hey @ak2766 feature was implemented at [3.32.2-snapshot][1], can you try it out? Thanks for the suggestion 🤝 . [1]: https://github.com/mageddo/dns-proxy-server/releases/tag/3.32.2-snapshot
Author
Owner

@ak2766 commented on GitHub (Nov 8, 2024):

Christmas has come early this year! Thank you kindly.

I'll test it out over the weekend.

<!-- gh-comment-id:2463572706 --> @ak2766 commented on GitHub (Nov 8, 2024): Christmas has come early this year! Thank you kindly. I'll test it out over the weekend.
Author
Owner

@ak2766 commented on GitHub (Nov 18, 2024):

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.

<!-- gh-comment-id:2484386537 --> @ak2766 commented on GitHub (Nov 18, 2024): 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.
Author
Owner

@mageddo commented on GitHub (Nov 18, 2024):

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

<!-- gh-comment-id:2484392592 --> @mageddo commented on GitHub (Nov 18, 2024): 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
Author
Owner

@mageddo commented on GitHub (Nov 18, 2024):

Not the domain there's a new one

<!-- gh-comment-id:2484395530 --> @mageddo commented on GitHub (Nov 18, 2024): Not the `domain` there's a new one
Author
Owner

@ak2766 commented on GitHub (Nov 19, 2024):

Aha - I see. I had to configure:

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

Noice work!

<!-- gh-comment-id:2484553493 --> @ak2766 commented on GitHub (Nov 19, 2024): Aha - I see. I had to configure: ``` "solverStub" : { "domainName" : "dummy.com" }, ``` Noice work!
Author
Owner

@ak2766 commented on GitHub (Nov 19, 2024):

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

<!-- gh-comment-id:2484554732 --> @ak2766 commented on GitHub (Nov 19, 2024): This is working as I anticipated. Will close this ticket now.
Author
Owner

@ak2766 commented on GitHub (Nov 20, 2024):

@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!

<!-- gh-comment-id:2487183135 --> @ak2766 commented on GitHub (Nov 20, 2024): @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!
Author
Owner

@mageddo commented on GitHub (Nov 21, 2024):

Creating a feature request for it. #607

<!-- gh-comment-id:2491526019 --> @mageddo commented on GitHub (Nov 21, 2024): Creating a feature request for it. #607
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/dns-proxy-server-mageddo#185
No description provided.