TechnitiumSoftware / DnsServer

Technitium DNS Server
https://technitium.com/dns/
GNU General Public License v3.0
4.47k stars 431 forks source link

[Feature Request] Add Cache prefilling module #1054

Closed 9bingyin closed 1 month ago

9bingyin commented 1 month ago

Support prefilling the DNS cache by importing root zone data obtained over HTTPS, which reduces the latency of recursion

https://www.knot-resolver.cz/documentation/latest/config-cache-prefill.html

ShreyasZare commented 1 month ago

Thanks for the post. Knot resolver feature to obtain root zone over HTTPS is since its just a resolver and cannot host authoritative zones. With Technitium DNS server, there is even better option available, that is to run the root zone locally. You can read this blog post to create a locally running root zone.

Note that with the current v13 release, you can just create the secondary root zone on the same DNS server instance and enable the ZONEMD validation and thus there is no need to run a separate instance of DNS server to run the root zone as described in the blog post. The blog post will soon be updated with this instruction.

zs311521 commented 1 month ago

Thanks for the post. Knot resolver feature to obtain root zone over HTTPS is since its just a resolver and cannot host authoritative zones. With Technitium DNS server, there is even better option available, that is to run the root zone locally. You can read this blog post to create a locally running root zone.

Note that with the current v13 release, you can just create the secondary root zone on the same DNS server instance and enable the ZONEMD validation and thus there is no need to run a separate instance of DNS server to run the root zone as described in the blog post. The blog post will soon be updated with this instruction.

Wow and here I thought it couldn’t get any better. Should this be run on both recursive and upstream dns resolver for resilience and lower latency?

ShreyasZare commented 1 month ago

Should this be run on both recursive and upstream dns resolver for resilience and lower latency?

If you create a local root zone, forwarding stops working since local zones have higher preference and the root zone would cause the DNS server to force recursive resolution even when you have forwarders configured.

So, you can do this only on your recursive resolver.

zs311521 commented 1 month ago

Should this be run on both recursive and upstream dns resolver for resilience and lower latency?

If you create a local root zone, forwarding stops working since local zones have higher preference and the root zone would cause the DNS server to force recursive resolution even when you have forwarders configured.

So, you can do this only on your recursive resolver.

Thank you.

Will I be able to do XFR over TLS for the instructions posted in the guide / XFR over QUIC? I try the options and it says SOA is not configured for root zone. It works just for the standard Zone transfer (unencrypted). I presume it doesnt matter for root servers?

zs311521 commented 1 month ago

Ah, it let me change it (add QUIC) after adding the zone first via standard zone xfer. I then applied ZONEMD. Thank you!

ShreyasZare commented 1 month ago

Root servers support only UDP and TCP transports. They do not support TLS/QUIC transports and they do not have any plan to support encrypted protocols.

Ah, it let me change it (add QUIC) after adding the zone first via standard zone xfer. I then applied ZONEMD. Thank you!

You need to revert back to TCP otherwise the zone transfer will fail and the zone will expire in few days due to this.

zs311521 commented 1 month ago

Root servers support only UDP and TCP transports. They do not support TLS/QUIC transports and they do not have any plan to support encrypted protocols.

Ah, it let me change it (add QUIC) after adding the zone first via standard zone xfer. I then applied ZONEMD. Thank you!

You need to revert back to TCP otherwise the zone transfer will fail and the zone will expire in few days due to this.

Thank you. You are right.

Very easy to set up in v13.0.

Do I still need to follow 'Now, open the first instance web console at http://:5380/ and go to the Zones section. Click on the Add Zone button to create a Conditional Forwarder Zone for . as the zone name and with the Use "This Server" option enabled. Once the zone is created, click Add Record to add a record of NS type, with localhost as the Name Server, and 127.0.0.2 as the Glue Address. You can now delete the FWD record that you see. Once done, you should have the conditional forwarder zone config as shown below:' to forward from secondary zone, if I setup the root servers via adding it directly into 'secondary'? Or will it root automatically be queried?

In which case the article will be cut down from several paragraph to literally a few paragraphs! Very very easy. Much appreciated.

ShreyasZare commented 1 month ago

Prior to v13, the way to run root zone locally was to have two separate DNS server instances, run secondary root zone on one exclusively, and then use a Forwarder zone with static NS records to allow querying the locally running root zone. This setup was required since root zone contents were not validated and thus kept separate so as to allow DNSSEC validation to work to protect from any bogus record that may get inserted by an attacker during zone transfer.

Now with v13 update and that the root zone now has ZONEMD record support, this complex setup of two instances is not required. You can have the secondary root zone directly on your single instance with ZONEMD validation enabled that would verify all records in the root zone automatically after each zone transfer.

zs311521 commented 1 month ago

Prior to v13, the way to run root zone locally was to have two separate DNS server instances, run secondary root zone on one exclusively, and then use a Forwarder zone with static NS records to allow querying the locally running root zone. This setup was required since root zone contents were not validated and thus kept separate so as to allow DNSSEC validation to work to protect from any bogus record that may get inserted by an attacker during zone transfer.

Now with v13 update and that the root zone now has ZONEMD record support, this complex setup of two instances is not required. You can have the secondary root zone directly on your single instance with ZONEMD validation enabled that would verify all records in the root zone automatically after each zone transfer.

So easy!! Thank you so much.

ShreyasZare commented 1 month ago

So easy!! Thank you so much.

You're welcome!

zs311521 commented 1 month ago

Note: There almost needs to be like a 'optional but suggested list' on the website, or 'further advanced enhancements to DNS server' list. There are so many gems you have spread throughout the wiki, putting it all together in one place such as this zone server and others will be really cool! I may have missed it already though.

ShreyasZare commented 1 month ago

Note: There almost needs to be like a 'optional but suggested list' on the website, or 'further advanced enhancements to DNS server' list. There are so many gems you have spread throughout the wiki, putting it all together in one place such as this zone server and others will be really cool! I may have missed it already though.

Yes, I am planning to update the blog post and put a link for in the DNS admin panel GUI soon.

chmichael commented 1 month ago

Hello, Is this better than using cloudflare's forwarder ?

Thank you

ShreyasZare commented 1 month ago

Hello, Is this better than using cloudflare's forwarder ?

Thank you

@chmichael It depends on your requirements. Without a forwarder, the DNS server does recursive resolution over plain UDP. The root secondary zone just helps to avoid frequent queries to root servers which is useful for medium to large networks. For some users, privacy from their current network is important so they use public DNS with encrypted protocols.

9bingyin commented 1 month ago

Hello, Is this better than using cloudflare's forwarder ?

Thank you

In my opinion, most of the time it won't. My use is to deploy recursive DNS on my own servers and to reduce the latency of resolution Since google dns and cloudflare dns don't have nodes in my area With a local root server, I've been using it for over a week now, and with some amount of caching, the latency of recursion is under 50ms most of the time (unless the latency to NS is high), which works very well

However, if google dns or cloudflare dns has nodes in your area, trust me, they are definitely better because they don't do recursion in most cases, they just give you what's in the cache

chmichael commented 1 month ago

@ShreyasZare @9bingyin Thank you for the respones so i'll stick with the cloudflare/google forwarders

zs311521 commented 1 month ago

Hello, Is this better than using cloudflare's forwarder ? Thank you

@chmichael It depends on your requirements. Without a forwarder, the DNS server does recursive resolution over plain UDP. The root secondary zone just helps to avoid frequent queries to root servers which is useful for medium to large networks. For some users, privacy from their current network is important so they use public DNS with encrypted protocols.

So I have local technitium --> forward queries to VPS technitium via DOH/QUIC. The VPS technitium also hosts the root server zone. Are queries to the root server zone from the local technitium unencrypted, or do they likewise go through the same encrypted forwarding?

indeed, if it was all locally hosted than all queries will be unencrypted including to root zone.

ShreyasZare commented 1 month ago

So I have local technitium --> forward queries to VPS technitium via DOH/QUIC. The VPS technitium also hosts the root server zone. Are queries to the root server zone from the local technitium unencrypted, or do they likewise go through the same encrypted forwarding?

indeed, if it was all locally hosted than all queries will be unencrypted including to root zone.

Your local DNS server does not know what your upstream server is doing. It will just forward the request via DoH/DoQ that you have configured and use the response.

Your upstream DNS server has local root zone so it will just keep it in sync with root servers automatically and use the local root zone to find name servers (NS records) for TLD internally when it does recursive resolution. There is nothing else special about the local root zone.