[Dnsmasq-discuss] dnsmasq and "AD" flag forwarding
simon at thekelleys.org.uk
Tue Dec 17 17:17:06 GMT 2013
On 16/12/13 11:13, Tomas Hozza wrote:
> ----- Original Message -----
>> I can see at least one bug in the code: in the code-path taken to answer
>> a query from the cache, the value of the AD flag is never changed: it
>> simply takes the value that it had in the query. I guess the
>> "authenticated" status of the data should be cached, and used to provide
>> this information.
> I'm sure there is nothing wrong with caching the AD flag. However as stated
> in the --proxy-dnssec documentation, dnsmasq as non-validating resolver should
> not return the AD flag to clients, unless the --proxy-dnssec option is used.
>> I'm currently deep into work to provide DNSSEC validation in dnsmasq,
>> and all of this code is therefore subject to massive revision in the
>> near future. I'll address the behaviour when dnsmasq is NOT validating
>> itself as part of that work.
> I can understand that implementing the DNSSEC validation is hard task
> and requires a lot of time and effort.
> I can try to come up with a patch for the "AD" flag forwarding if you could
> agree with me on what is the correct behaviour here. Also what is the
> role of --proxy-dnssec option.
This is my understanding
If dnsmasq gets a query with the "DO" bit set (ie the client wants
security information). Dnsmasq forwards the query as normal, and gets a
reply which may have the "AD" flag set, indicating that the data is
validated. However, the reply, complete with AD bit, may be a forgery,
so dnsmasq shouldn't return the AD bit to the client, and resets it
before sending the reply to the client.
For the case that it's known that dnsmasq is always forwarding queries
over a trusted channel to a trusted validating nameserver, the user can
configure --proxy-dnssec and then the AD bit in the reply will be
returned to the client.
The relevant bit of standard, according to the dnsmasq source code, is
RFC4035 4.6 para 3.
This is all somewhat academic, since the dnsmasq doesn't currently cache
the value of the AD bit in the reply, so if the answer comes from
dnsmasq's cache, the AD bit will not be meaningful. In fact, as a stated
in my last reply, the value of the AD bit which the client gets back
with an answer from cache is actually the value of the AD bit in the
query, which is nonsense.
More information about the Dnsmasq-discuss