unbound API and authenticated data

George Thessalonikefs george at nlnetlabs.nl
Wed Jul 22 16:32:37 UTC 2020


Hi Anthony,

On 22/07/2020 01:05, Modster, Anthony wrote:
> Hello George
> 
> Here are two cases.
> One, Google, which the API reports not secure.
> Two, cloudflare, which the API reports as secure.
> Note: some articles state Google should be supporting DNSSEC by now.
Both Google and Cloudflare *public resolvers* support DNSSEC; that is if
you ask 8.8.8.8 or 1.1.1.1 you will get DNSSEC validated answers.

However cloudflare.net is a DNSSEC signed domain, whereas google.com is not.


> 
> Using the API it would be easy to check the security bit and make a decision on what to allow.
> 
> But what about the below:
> DNS client->unbound recursive resolver->external DNSSEC servers
> In this case how do you control what to allow if you want it secure always ?
You do the DNSSEC validation as close to the client as you can.
It seems that you only want to consider DNSSEC signed domains and ignore
the rest.

> 
> Example Google
> test-unbound: PrintUbResults qname=www.google.com qtype=1 qclass=1 canonname=(null) rcode=0 answer_len=59 secure=0 bogus=0 ttl=300 (domain name=www.google.com).
> test-unbound: ResolveURL IP address 142.250.68.36 (domain name=www.google.com).
> test-unbound: ResolveURL result is insecure (IP address 142.250.68.36, domain name=www.google.com).
secure=0 and bogus=0 means:
- either libunbound was configured without the validator, or
- the domain is not a DNSSEC secured domain (insecure).

In your case you know that the first is false, because you are the one
that configures libunbound.

> 
> Example cloudflare
> test-unbound:[48918]: PrintUbResults qname=cloudflare.net qtype=1 qclass=1 canonname=(null) rcode=0 answer_len=185 secure=1 bogus=0 ttl=300 (domain name=cloudflare.net).
> test-unbound:[48918]: ResolveURL IP address 104.17.156.85 (domain name=cloudflare.net).
> test-unbound:[48918]: ResolveURL result is secure (IP address 104.17.156.85, domain name=cloudflare.net).
secure=1 and bogus=0 means that the domain is DNSSEC signed and passes
DNSSEC validation.

So in conclusion the following states are available if libunbound is
configured to do DNSSEC validation (default):
secure | bogus | verdict
0      | 0     | domain is not signed (insecure)
0      | 1     | domain is signed and bogus
1      | 0     | domain is signed and secure
1      | 1     | -; can't happen

Best regards,
-- George

> 
> Another example
> Strongswan resolver->unbound recursive resolver->external DNSSEC servers
> If we want to use DNSSEC for OCSP and CDP, we would need to use both the "strongswan plugin resolver" and "unbound recursive resolver".
> 
> 
> -----Original Message-----
> From: Unbound-users <unbound-users-bounces at lists.nlnetlabs.nl> On Behalf Of George Thessalonikefs via Unbound-users
> Sent: Tuesday, July 21, 2020 9:05 AM
> To: unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound API and authenticated data
> 
> ---External Email---
> 
> Hi Anthony,
> 
> It would be better if you give an example of what you are trying to achieve.
> 
> If you trust your upstream (e.g., forwarding to a trusted resolver that checks DNSSEC) you can disable validation by not including `validator` in the modules configuration (`module-config:`).
> 
> If validation is disabled, unbound cannot check the DNSSEC state.
> 
> Best regards,
> -- George
> 
> 
> On 15/07/2020 18:51, Modster, Anthony wrote:
>> Hello George
>>
>> So for this case, the AD state is ignored by unbound.
>> - If unbound receives the AD, it means that the upstream *signals* that
>>   it has verified the query response. Unbound will not trust this and
>>   will always do validation (unless not configured).
>>
>> What configuration parameter can be used to disable validation ?
>>
>> If validation is disable will unbound check the AD state ?
>>
>> Note: we are using unbound as a client resolver.
>>
>> -----Original Message-----
>> From: Unbound-users <unbound-users-bounces at lists.nlnetlabs.nl> On 
>> Behalf Of George Thessalonikefs via Unbound-users
>> Sent: Wednesday, July 15, 2020 8:04 AM
>> To: unbound-users at lists.nlnetlabs.nl
>> Subject: Re: unbound API and authenticated data
>>
>> ---External Email---
>>
>> Hi Anthony,
>>
>> It is not clear to me by your text but:
>> - If unbound receives the AD, it means that the upstream *signals* that
>>   it has verified the query response. Unbound will not trust this and
>>   will always do validation (unless not configured).
>> - If unbound sets the AD, unbound itself has verified the response.
>>
>> I can't give one answer for the other values because it depends on the response.
>> Information for the values you asked can be found in your local man page for libunbound or online at https://www.nlnetlabs.nl/documentation/unbound/libunbound/ for the latest version.
>>
>> Best regards,
>> -- George
>>
>> On 14/07/2020 20:20, Modster, Anthony via Unbound-users wrote:
>>> Does anyone have the information below ?
>>>
>>>  
>>>
>>> *From:* Modster, Anthony
>>> *Sent:* Wednesday, July 8, 2020 11:53 AM
>>> *To:* Modster, Anthony via Unbound-users 
>>> <unbound-users at lists.nlnetlabs.nl>
>>> *Subject:* unbound API and authenticated data
>>>
>>>  
>>>
>>> Hello
>>>
>>>  
>>>
>>> We are using unbound API for DNSSEC resolve.
>>>
>>>  
>>>
>>> If the Authenticated Data (AD) flag is received and is set to "not 
>>> validated" 0.
>>>
>>> What would be the states of the following flags:
>>>
>>>   * havedata
>>>   * secure
>>>   * bogus
>>>
>>>  
>>>
>>> Thanks
>>>
>>>  
>>>
>>
> 
> 
> 
> 




More information about the Unbound-users mailing list