When a record is defined locally, eg an A record for one.two.example then
we already know that if we forward, eg an AAAA query for one.two.example,
and get back NXDOMAIN, then we need to alter that to NODATA. This is handled
by check_for_local_domain(). But, if we forward two.example, because
one.two.example exists, then the answer to two.example should also be
a NODATA.
For most local records this is easy, just to substring matching.
for A, AAAA and CNAME records that are in the cache, it's more difficult.
The cache has no efficient way to find such records. The fix is to
insert empty (none of F_IPV4, F_IPV6 F_CNAME set) records for each
non-terminal.
The same considerations apply in auth mode, and the same basic mechanism
is used there too.
The option was already described in the original manual page but was not
replicated in the french translation.
Reviewed-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
The use of "peut-être" should be spelled "peut être" (without the
hyphen) unless it can be replaced by "sans doute".
It is roughly the same difference between "maybe" and "may be".
As for "doit-être", it should always be spelled "doit être".
Reviewed-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Various typos were present along with spelling mistakes and grammar
errors. Some sentences were missing a few words to be easily
understandable.
Many of them probably remain though.
Reviewed-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
When inserting new cache records, we first delete existing records
of the same name/type, to maintain consistency. This has the side effect
of deleting any CNAMES which have the records as target. So
cname1.example CNAME record.example
cname2.example CNAME record.example
looking up cname2.example will push it into the cache, and also
push record.example. Doing that deletes any cache of cname1.example.
This changeset avoids that problem by making sure that when
deleting record.example, and re-insterting it (with the same name -important),
it uses the same struct crec, with the same uid. This preserves the existing cnames.
Dnsmasq does pass on the do-bit, and return DNSSEC RRs, irrespective
of of having DNSSEC validation compiled in or enabled.
The thing to understand here is that the cache does not store all the
DNSSEC RRs, and dnsmasq doesn't have the (very complex) logic required
to determine the set of DNSSEC RRs required in an answer. Therefore if
the client wants the DNSSEC RRs, the query can not be answered from
the cache. When DNSSEC validation is enabled, any query with the
do-bit set is never answered from the cache, unless the domain is
known not to be signed: the query is always forwarded. This ensures
that the DNSEC RRs are included.
The same thing should be true when DNSSEC validation is not enabled,
but there's a bug in the logic.
line 1666 of src/rfc1035.c looks like this
if ((crecp->flags & (F_HOSTS | F_DHCP | F_CONFIG)) || !do_bit || !(crecp->flags & F_DNSSECOK))
{ ...answer from cache ... }
So local stuff (hosts, DHCP, ) get answered. If the do_bit is not set
then the query is answered, and if the domain is known not to be
signed, the query is answered.
Unfortunately, if DNSSEC validation is not turned on then the
F_DNSSECOK bit is not valid, and it's always zero, so the question
always gets answered from the cache, even when the do-bit is set.
This code should look like that at line 1468, dealing with PTR queries
if ((crecp->flags & (F_HOSTS | F_DHCP | F_CONFIG)) ||
!do_bit ||
(option_bool(OPT_DNSSEC_VALID) && !(crecp->flags & F_DNSSECOK)))
where the F_DNSSECOK bit is only used when validation is enabled.
I noticed that dnsmasq often wasn't sending any unsolicited RAs for me.
This turned out to happen when the interface (a bridge interface) wasn't
created yet at the time dnsmasq started. When dnsmasq is started after
the interface is created, it sends RAs as expected. I assume this also
extends to other types of virtual interfaces that are created after
dnsmasq starts.
Digging into the source, it seems to be caused by a missing call to
ra_start_unsolicited for non-template contexts in construct_worker from
src/dhcp6.c. The attached patch adds that call, but only if the
interface index or address changed to prevent doing fast RAs for no reason.
I tested it on my own server and it appears to work as expected. When
the interface is created and configured, dnsmasq does fast RAs for a
while and then settles into slow RAs.
