config zone
option enabled '1'
option zone_type 'forward_zone'
option tls_upstream '1'
option tls_index 'dns.google'
list zone_name '.'
list server '8.8.8.8'
list server '8.8.4.4'
list server '2001:4860:4860::8888'
list server '2001:4860:4860::8844'
unfortunately they use only google dns servers. afaik unbound uses root dns servers per default.
My question is 1. are the root dns servers able to do dns over tls? 2. where do i get a list of the root dns servers to be able to add them to this config so that i am not dependant on google only.
config zone
option enabled '1'
option zone_type 'forward_zone'
option tls_upstream '1'
option tls_index 'dns.google'
list zone_name '.'
list server '8.8.8.8'
list server '8.8.4.4'
list server '2001:4860:4860::8888'
list server '2001:4860:4860::8844'
unfortunately they use only google dns servers. afaik unbound uses
root dns servers per default.
Concept confusion alert!
By default unbound does not do query forwarding, and instead does its
own recursive query resolution, caching results, nesting its way down
the name hierarchy, and speaking directly to the publishing name
servers for each domain in the naming hierarchy in order to resolve a
given query.
Query forwarding relies on *other* recursive resolvers to perform
this function.
However, please do note that the root name servers do not provide
recursive resolution to *ANYONE*! They are publishing name servers,
not recursive resolvers!
my question is 1. are the root dns servers able to do dns over tls?
Not that it matters, given the above, but I would think "no"; the root
name servers typically require the efficiency provided by the reduced
number of packets and the statelessness provided by the UDP-based DNS
service.
2. where do i get a list of the root dns servers to be able to add
them to this config so that i am not dependant on google only.
This question does not make sense, given the above. You cannot
configure unbound to do "query forwarding" to the root name servers
and expect to get a useful result.
ok maybe i do not understand how unboud or even any DNS server works. let me rephrase my questions:
in default unbound config i do not define any DNS servers.
in the openwrt/luci config for unbound i had to define 8.8.8.8 and tls_index to google.
is there any way to configure this to use unbound with the default config + dns over tls but not to define google dns servers?
ok maybe i do not understand how unboud or even any DNS server works. let
me rephrase my questions:
in default unbound config i do not define any DNS servers.
Right. You can specify the hints for where to find the root name
servers in the DNS via the "root-hints:" unbound.conf option, but
unbound has a built-in default list corresponding to the list of
root name servers on the public Internet.
in the openwrt/luci config for unbound i had to define 8.8.8.8 and
tls_index to google.
is there any way to configure this to use unbound with the
default config + dns over tls but not to define google dns servers?
The correct address to send that question to must be to those who
put the "config framework" on top of unbound for openwrt.
Unbound itself does not require another external recursive name
server, as unbound can itself act as a recursive name server.
Unbound's ability to do so, of course, relies on unbound not
being prevented to talk the DNS protocol directly to the outside
world via e.g. an ACL.
Unbound can do both recursive and forward DNS. DNS-over-TLS is most (only?) used for forwarding configurations, because authoritative servers will not like the TCP load. DoT is a highly desirable feature. Because it may be difficult for some to configure at first, Google's example is provided ready to use but disabled. You can change that forward zone section or replace it entirely (cloudflare, quad9, ...). You can also choose to make such forwarding exclusive, or allow Unbound to fall back on recursion, if forward destinations do not respond.
After you give that a read through and maybe a few tries, I will be happy to help you further.
A recursive resolver sends queries to many authoritative servers,
following referrals where they happen, in order to find answers to the
questions sent to them by clients. They start with knowledge of how to
reach the root servers acquired through the priming process and
discover everything else as they go. This is arguably an iterative
process but was described as recursive in the original specification
and the name has stuck.
A forwarder receives queries from clients and sends the questions on
to a locally-configured set of servers which are generally themselves
either forwarders or recursive servers. A forwarder does not send
queries to authoritative servers directly, does not need to prime and
does not (have the opportunity to) follow referrals.
I make a distinction which is a bit more pedantic than usual...
Recursion is about the kinds of queries a server is willing to answer: if
the server sets the RA bit (recursion available) in its responses and is
therefore willing to answer RD (recursion desired) queries. The effect is
that the server will obtain a complete answer and won't return referrals.
This is independent of how the server gets the answers. It can perform
iterative resolution (making queries with RD=0 and chasing referrals) or
it can send recursive queries to another recursive server - which is
called forwarding.
According to this model, saying a server is recursive doesn't imply
anything about whether it forwards queries or does its own iterative
resolution. But usually when a server is described as recursive, that
implies it does iterative resolution.
The way I relate "recursion" in the DNS sense to its usual meaning, is
when one resolver asks another resolver to answer a query on its behalf,
it's a bit (wave hands vigorously) like a recursive call from one function
to another function. (In the DNS case depth of recursion is determined by
the forwarding topology, rather than reducing the complexity of the query
as one would expect from functional recursion.)
What makes the terminology extra confusing is that iterative resolution is
about traversing a tree-shaped namespace (which has a recursive flavour)
and iterative resolution gets explicitly recursive when the resolver has
to resolve a nameserver address in order to follow a referral.
So my rationalizaion is mostly in vain, because it isn't really possible
to relate the DNS uses of recursion and iteration to their non-DNS
meanings.