Skip to content
Snippets Groups Projects
Unverified Commit 543eb178 authored by Matthias Schiffer's avatar Matthias Schiffer
Browse files

gluon-core: remove DNS cache feature

dnsmasq's caching is severly broken and does not handle all answer records
equally. In particular, its cached answers are missing DNSKEY and DS
records, breaking DNSSEC validation on clients.

Remove the cache for now. It may return if dnsmasq is fixed or we switch to
a different resolver.
parent 395266e4
No related branches found
No related tags found
No related merge requests found
DNS caching
===========
User experience may be greatly improved when dns is accelerated. Also, it
seems like a good idea to keep the number of packages being exchanged
between node and gateway as small as possible. In order to do this, a
DNS cache may be used on a node. The dnsmasq instance listening on port
53 on the node will be reconfigured to answer requests, use a list of
upstream servers and a specific cache size if the options listed below are
added to site.conf. Upstream servers are the DNS servers which are normally
used by the nodes to resolve hostnames (e.g. gateways/supernodes).
There are the following settings:
servers
cacheentries
To use the node's DNS server, both options should be set. The node will cache at
most 'cacheentries' many DNS records in RAM. The 'servers' list will be used to
resolve the received DNS queries if the request cannot be answered from
cache. Gateways should announce the "next node" address via DHCP and RDNSS (if
any). Note that not setting 'servers' here will lead to DNS not working: Once
the gateways all announce the "next node" address for DNS, there is no way for
nodes to automatically determine DNS servers. They have to be baked into the
firmware.
If these settings do not exist, the cache is not initialized and RAM usage will
not increase.
When next_node.name is set, an A record and an AAAA record for the
next-node IP address are placed in the dnsmasq configuration. This means that
the content of next_node.name may be resolved even without upstream connectivity.
It is suggested to use the same name as the DNS server provides:
e.g. nextnode.location.community.example.org (This way the name also works if a
client uses static DNS Servers). Hint: If next_node.name does not contain a dot
some browsers would open the searchpage instead.
::
dns = {
cacheentries = 5000,
servers = { '2001:db8::1', },
},
next_node = {
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip6 = '2001:db8:8::1',
ip4 = '198.51.100.1',
}
The cache will be initialized during startup.
Each cache entry will occupy about 90 bytes of RAM.
DNS forwarder
=============
A Gluon node can be configured to act as a DNS forwarder. Requests for the
next-node hostname(s) can be answered locally, without querying the upstream
resolver.
**Note:** While this reduces answer time and allows to use the next-node
hostname without upstream connectivity, this feature should not be used for
next-node hostnames that are FQDN when the zone uses DNSSEC.
One or more upstream resolvers can be configured in the *dns.servers* setting.
When *next_node.name* is set, A and/or AAAA records for the next-node IP
addresses are placed in the dnsmasq configuration.
::
dns = {
servers = { '2001:db8::1', },
},
next_node = {
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip6 = '2001:db8:8::1',
ip4 = '198.51.100.1',
}
...@@ -23,7 +23,7 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre ...@@ -23,7 +23,7 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
features/wlan-configuration features/wlan-configuration
features/private-wlan features/private-wlan
features/wired-mesh features/wired-mesh
features/dns-cache features/dns-forwarder
features/monitoring features/monitoring
features/authorized-keys features/authorized-keys
features/roles features/roles
......
...@@ -88,8 +88,6 @@ New features ...@@ -88,8 +88,6 @@ New features
* Add support for making nodes a DNS cache for clients * Add support for making nodes a DNS cache for clients
(`#1000 <https://github.com/freifunk-gluon/gluon/issues/1000>`_) (`#1000 <https://github.com/freifunk-gluon/gluon/issues/1000>`_)
See also: :doc:`../features/dns-cache`
* Add L2TP via tunneldigger as an alternative VPN system * Add L2TP via tunneldigger as an alternative VPN system
(`#978 <https://github.com/freifunk-gluon/gluon/issues/978>`_) (`#978 <https://github.com/freifunk-gluon/gluon/issues/978>`_)
......
...@@ -67,7 +67,6 @@ need_boolean(in_site({'poe_passthrough'}), false) ...@@ -67,7 +67,6 @@ need_boolean(in_site({'poe_passthrough'}), false)
if need_table({'dns'}, nil, false) then if need_table({'dns'}, nil, false) then
need_string_array_match({'dns', 'servers'}, '^[%x:]+$') need_string_array_match({'dns', 'servers'}, '^[%x:]+$')
need_number({'dns', 'cacheentries'}, false)
end end
need_string_array(in_domain({'next_node', 'name'}), false) need_string_array(in_domain({'next_node', 'name'}), false)
......
...@@ -12,7 +12,7 @@ uci:set('dhcp', dnsmasq, 'localise_queries', true) ...@@ -12,7 +12,7 @@ uci:set('dhcp', dnsmasq, 'localise_queries', true)
uci:set('dhcp', dnsmasq, 'localservice', false) uci:set('dhcp', dnsmasq, 'localservice', false)
uci:set('dhcp', dnsmasq, 'server', dns.servers) uci:set('dhcp', dnsmasq, 'server', dns.servers)
uci:set('dhcp', dnsmasq, 'cachesize', dns.cacheentries) uci:delete('dhcp', dnsmasq, 'cachesize')
uci:delete('firewall', 'client_dns') uci:delete('firewall', 'client_dns')
if dns.servers then if dns.servers then
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment