iTHiNDiL Posted December 26, 2020 Share Posted December 26, 2020 Yes, by default it's disabled but i did enable the scope and restart the container just in case. The problem is that the port UDP 67 it's closed when I test the port with PortQryUI, it's a tool that I use at my work with this purpose. That is why the DHCP server can't receive the broadcasts DHCPDISCOVER and respond with an DHCPOFFER message to the client, or at least that is what I thinks it's the problem. I really don't know why it's not maping the port UDP 67 from the container to the Host, this is as far i can go. Maybe it's this? At file Dockerfile.amd64: Only port 5380 and 53/upd are maped here. Quote Link to comment
Roxedus Posted December 26, 2020 Author Share Posted December 26, 2020 As I noted in this PR. Expose is not the issue. https://github.com/Roxedus/docker-TS-DnsServer/pull/2#issuecomment-751127753 Quote Link to comment
Roxedus Posted December 26, 2020 Author Share Posted December 26, 2020 Are you using macvlan? Quote Link to comment
iTHiNDiL Posted December 27, 2020 Share Posted December 27, 2020 Nope, I was using bridge and after your question I did tried to use a manually created network, didnt' work I also tried to use host and curiously port 67 was not maped: Quote Link to comment
faicec Posted January 9, 2021 Share Posted January 9, 2021 (edited) Afternoon, Running two dockers of this application, both updated overnight and neither are functional this morning. Attempted a redeploy, however the same error regarding .net 5 is visible in the logs: It was not possible to find any compatible framework version The framework 'Microsoft.NETCore.App', version '5.0.0' was not found. - The following frameworks were found: 3.1.0 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] You can resolve the problem by installing the specified framework and/or SDK. The specified framework can be found at: - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=5.0.0&arch=x64&rid=alpine.3.12-x64 It was not possible to find any compatible framework version Edit - This has been reported on the project page by another user. Craig Edited January 9, 2021 by faicec found report on github Quote Link to comment
alientim Posted January 10, 2021 Share Posted January 10, 2021 Just a Solution until they Update it, You can Easly downgrad by set a direct release. Edit your Docker Repo from roxedus/ts-dnsserver to roxedus/ts-dnsserver:2021-01-01_22.08 for the last working release as static. Quote Link to comment
iTHiNDiL Posted January 11, 2021 Share Posted January 11, 2021 On 1/9/2021 at 3:03 PM, faicec said: Afternoon, Running two dockers of this application, both updated overnight and neither are functional this morning. Attempted a redeploy, however the same error regarding .net 5 is visible in the logs: It was not possible to find any compatible framework version The framework 'Microsoft.NETCore.App', version '5.0.0' was not found. - The following frameworks were found: 3.1.0 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] You can resolve the problem by installing the specified framework and/or SDK. The specified framework can be found at: - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=5.0.0&arch=x64&rid=alpine.3.12-x64 It was not possible to find any compatible framework version Edit - This has been reported on the project page by another user. Craig Same problem here, but I belive that the issue i'ts not on Technitium DNS Server, the container do not contain Framework 5.0 files. @Roxedus, if you have a moment can you confirm that the problem is on the container? thanks Quote Link to comment
Roxedus Posted January 11, 2021 Author Share Posted January 11, 2021 17 minutes ago, iTHiNDiL said: problem is on the container? It was. They have hid their changelog in a way that there is no reliable way to get notifications. They silently updated the requirements. Runs on latest build 1 Quote Link to comment
iTHiNDiL Posted January 11, 2021 Share Posted January 11, 2021 (edited) On 1/11/2021 at 10:19 AM, Roxedus said: It was. They have hid their changelog in a way that there is no reliable way to get notifications. They silently updated the requirements. Runs on latest build Thanks for your quick response @Roxedus. Folks, until the latest version of the container is updated with the Framwork 5.0 files we must change the tag as @alientim said: On 1/10/2021 at 5:47 AM, alientim said: Just a Solution until they Update it, You can Easly downgrad by set a direct release. Edit your Docker Repo from roxedus/ts-dnsserver to roxedus/ts-dnsserver:2021-01-01_22.08 for the last working release as static. Edit: Already working with "latest" tag Edited January 14, 2021 by iTHiNDiL Quote Link to comment
iTHiNDiL Posted January 16, 2021 Share Posted January 16, 2021 On 12/21/2020 at 9:48 AM, iTHiNDiL said: Hi @Roxedus, After some research I decided to install this container to have an DNS with sinkhole capabilites and DHCP server in single container and not deploying a VM for that but I'm having problems with the DHCP server I deployed the container as Custom:br0 with custom IP 192.168.1.200 but after setting up the DHCP pool no device in my internal network is able to receive any IP configuration from the DCHP server. I tried to add UDP port 67 for the DHCP discovery just in case but it's not working. The DNS server is working without any problems as my internal DNS server but nothing to do with DHCP. I check the port 67 and it's closed/filtered. I'm a newbie with containers but maybe the container needs some modifications for the port 67? You can call me crazy or something worse but after more digging i saw that at the bottom of Dockerfile.amd64 there is a line that looks like "expose" ports for the container: EXPOSE 5380 53/udp, maybe can be changed to add port 67/udp and then DHCP will be accesible? Thanks. After the last update DHCP start working without a problem, looks like they fixed, whatever it was ... Quote Link to comment
erlipton Posted February 4, 2021 Share Posted February 4, 2021 (edited) @Roxedus there's a bug in the ts-dnsserver docker... if I set a specific port on docker initial setup (example 8180) then the server's settings page will not update the auto-filled port from 5380 --> 8180. Result, if you update a setting unrelated to the port, it will actually also update to 5380 & confuse the hell out of me for 20 minutes Edited February 4, 2021 by erlipton so that i sound smarter than i actually am Quote Link to comment
Roxedus Posted February 4, 2021 Author Share Posted February 4, 2021 10 hours ago, erlipton said: settings page will not update the auto-filled This is not a bug. The container has no idea what port you set on the host-side. Quote Link to comment
xPliZit_xs Posted February 5, 2021 Share Posted February 5, 2021 Hi, would it be possible to have this TS-DNSSERVER work together with DNScrypt-Proxy running on another machine? I currently have a unbound dns server forwarding to dnscrypt-proxy on another machine and wanted to give this docker a try but i dont want to miss out on the features of dnscryp-proxy. Thanks. Quote Link to comment
iTHiNDiL Posted February 15, 2021 Share Posted February 15, 2021 (edited) Hi @Roxedus, The DNS resolution stop working last night after updating the container with the latest version. After performing some tests the port 53 is closed from the network to the container. Edited February 15, 2021 by iTHiNDiL Quote Link to comment
Roxedus Posted February 16, 2021 Author Share Posted February 16, 2021 I didnt touch anything, if anything changed it had to be technium pushing a update thats not in the changelog, or that one of the few dependencies broke something. Quote Link to comment
opsec Posted April 11, 2021 Share Posted April 11, 2021 On 2/5/2020 at 2:35 AM, Roxedus said: Let me know what you think. Well actually, I like to explain my users on the network, that a certain page i blocked on my network. So would it be possible to you to maked the dns sinkhole editable to a certain ip address? I think it could be nice to implement a blocked page. Quote Link to comment
xPliZit_xs Posted August 14, 2021 Share Posted August 14, 2021 Hi @Roxedus, a new version has been out for a bit, just a heads up. Thank you. 👍 Quote Link to comment
Roxedus Posted August 14, 2021 Author Share Posted August 14, 2021 5 minutes ago, xPliZit_xs said: Hi @Roxedus, a new version has been out for a bit, just a heads up. Thank you. 👍 I updated it 16 hours ago. Quote Link to comment
xPliZit_xs Posted August 18, 2021 Share Posted August 18, 2021 On 8/14/2021 at 9:34 AM, Roxedus said: I updated it 16 hours ago. What coincidence. Thanks for providing the update to quickly. Thanks! Quote Link to comment
AlainF Posted September 28, 2021 Share Posted September 28, 2021 Good day everyone, Running latest unRAID OS "Plus", and latest version of ts-dnsserver. I have recently starting experimenting with ts-dnsserver, and have come accross a problem I can't properly debug or explain. Every so often I notice that when the ts-dnsserver docker is stopped, and try to start it, the start process exits with an "execution error". Checking the logfiles, I find an error message that it cannot bind to port 53 (which is indeed bad for a DNS server 😁 ). Opening a terminal on the unRAID box and listing processes attached to port 53, I see a "dnsmasq" process. Once I kill this process, the ts-dnsserver docker starts again and all works fine. Any ideas? Sorry to not be clearer or more explicit ; if it helps to provide additional data, please let me know which. Thanks in advance, Alain Quote Link to comment
Tom Sealey Posted September 28, 2021 Share Posted September 28, 2021 16 minutes ago, AlainF said: Good day everyone, Running latest unRAID OS "Plus", and latest version of ts-dnsserver. I have recently starting experimenting with ts-dnsserver, and have come accross a problem I can't properly debug or explain. Every so often I notice that when the ts-dnsserver docker is stopped, and try to start it, the start process exits with an "execution error". Checking the logfiles, I find an error message that it cannot bind to port 53 (which is indeed bad for a DNS server 😁 ). Opening a terminal on the unRAID box and listing processes attached to port 53, I see a "dnsmasq" process. Once I kill this process, the ts-dnsserver docker starts again and all works fine. Any ideas? Sorry to not be clearer or more explicit ; if it helps to provide additional data, please let me know which. Thanks in advance, Alain Hi @AlainF, this is because unRAID runs its own DNS server using dnsmasq. I believe it's used for VMs. Details here of how to disable it: 1 Quote Link to comment
AlainF Posted September 28, 2021 Share Posted September 28, 2021 Thanks @Tom Sealey ! This pointed me towards the solution. I simply bound the ts-dnsserver docker to a different IP address using the "custom" property for network, and now all is well! Cheers mate! Quote Link to comment
DesertCookie Posted April 1, 2022 Share Posted April 1, 2022 (edited) How'd I go about redirecting traffic to the local server instead of it having to take a round-trip through Cloudflare? I've tried to mess with the Zones but cannot get it to forwards all traffic for "mydomain.de" and subdomains to my server's IP which exposes a reverse proxy. Edit: I think I figured it out. Now I finally have a ping of <2ms (5-10ms via WiFi) instead of 20-35ms. Go to Zones and click Add Zone. Use your domain name as zone name, creating the primary zone with Add. Add A/AAAA records pointing to your server. Add CNAMe records for your subdomains (basically mirroring the setup on Cloudflare). Edited April 1, 2022 by DesertCookie added solution Quote Link to comment
jgosnell Posted April 1, 2022 Share Posted April 1, 2022 Hi @Roxedus, just curious if you have any idea if or when this container was going to be updated to the new TDNS version currently at 8.0.1. Quote Link to comment
m4gicfour Posted April 2, 2022 Share Posted April 2, 2022 (edited) @Roxedus It appears a dependency change got missed. With the latest update to the Docker, this error is being spammed in the log and the DNS server is not responding. It was not possible to find any compatible framework version The framework 'Microsoft.NETCore.App', version '6.0.0' was not found. - The following frameworks were found: 5.0.1 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] You can resolve the problem by installing the specified framework and/or SDK. The specified framework can be found at: - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_verrsion=6.0.0&arch=x64&rid=alpine.3.14-x64 .NET 6.0 is now required as of version 8.0 of the software. Quote Technitium DNS Server Change Log Version 8.0.1 Release Date: 29 March 2022 Fixed bug in Conditional Forwarder zones due to zone cut validation causing negative cache entry for CNAME responses which resulted in partial responses. Fixed issue with handling FormatError response that were missing question section for EDNS requests. Fixed minor issue with DNSSEC validation for unsigned zone when forwarder returns empty NXDOMAIN responses. Fixed issue with NODATA response handling for ANAME records. Fixed issue with record comment validation causing error when saving SOA records in zones. Multiple other minor bug fixes and improvements. Version 8.0 Release Date: 26 March 2022 Added EDNS support RFC 6891. Added Extended DNS Errors RFC 8914. Added DNSSEC validation support with RSA & ECDSA algorithms for recursive resolver, forwarders, and conditional forwarders. Added DNSSEC support for all supported DNS transport protocols including encrypted DNS protocols (DoT, DoH, DoH JSON). Added DNSSEC zone signing support with RSA & ECDSA algorithms. Updated DNS Client to support DNSSEC validation. Updated proprietary FWD record which is used with Conditional Forwarder Zones for DNSSEC validation and HTTP/SOCKS5 proxy support. Updated Conditional Forwarder Zones to support working as a static stub zone to force a domain name to resolve via given name servers using NS records. Upgraded codebase to .NET 6 runtime. Query Logs App: Added wildcard search support for domain names. Fixed multiple issues with DHCP server. This release updates many API calls which may cause issues in 3rd party clients if they are not updated before deploying this new version. It is recommended to check the API documentation for changes before deploying this new release. Multiple other minor bug fixes and improvements. Edited April 2, 2022 by m4gicfour typo Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.