mirror of
https://github.com/pi-hole/docs.git
synced 2024-12-06 19:27:12 +01:00
Update unbound.md (#613)
I guess this should be "traverse" instead of "transverse".
This commit is contained in:
@@ -47,7 +47,7 @@ You can easily imagine even longer chains for subdomains as the query process co
|
||||
|
||||
- Benefit: Privacy - as you're directly contacting the responsive servers, no server can fully log the exact paths you're going, as e.g. the Google DNS servers will only be asked if you want to visit a Google website, but not if you visit the website of your favorite newspaper, etc.
|
||||
|
||||
- Drawback: Traversing the path may be slow, especially for the first time you visit a website - while the bigger DNS providers always have answers for commonly used domains in their cache, you will have to transverse the path if you visit a page for the first time. The first request to a formerly unknown TLD may take up to a second (or even more if you're also using DNSSEC). Subsequent requests to domains under the same TLD usually complete in `< 0.1s`.
|
||||
- Drawback: Traversing the path may be slow, especially for the first time you visit a website - while the bigger DNS providers always have answers for commonly used domains in their cache, you will have to traverse the path if you visit a page for the first time. The first request to a formerly unknown TLD may take up to a second (or even more if you're also using DNSSEC). Subsequent requests to domains under the same TLD usually complete in `< 0.1s`.
|
||||
Fortunately, both your Pi-hole as well as your recursive server will be configured for efficient caching to minimize the number of queries that will actually have to be performed.
|
||||
|
||||
## Setting up Pi-hole as a recursive DNS server solution
|
||||
|
||||
Reference in New Issue
Block a user