[Unbound-users] Is It Correct Unbound Config as Validating DNS Server/Resolver ?

Mon May 27 03:37:02 UTC 2013

I'm having few problems, you may skip below, and please goto
PROBLEM(s) section in below.

CORRECTION & MORE INFO:

I need to correct few information, and add more info:

(When I copy-pasted config here, from real config, i had to change
IP, to not disclose actual IP, and removed my own test related
comments, test-config-lines, etc, so there were some mistakes, sorry).

In my 1st message, i wrote:

> 
> Windows DNS Client service is set onto "Manual Startup" mode, so it
> is not running, and, local network adapter/interface is configured
> to use 127.0.0.1 as it's DNS-Server, in this (Win7) computer.
> 

Sorry, it was wrong info. This service is kept in "Disabled"
state/mode in those computers, which are using that Unbound
DNS-Server (on Win7) computer which has 192.168.0.10 IP-address.

Adding more info, related to Unbound DNS-Server on Win7 computer:

Windows Firewall in that Win7 computer was further configured : to
allow Unbound DNS-Server (192.168.0.10) service software to create
incoming connections (from any Internet or LAN IP-address) to local
UDP & TCP port 53 and to 1025-65535 port-range, and incoming was
allowed toward only "unbound.exe" based service software, and
outgoing connections (from Unbound service software) was allowed
toward (TCP & UDP) port 53 of any (internet bound) IP-address (to NS
/ DNS Servers).

Similar firewall rules (like above) were created for Mozilla
"firefox.exe" and firefox "Plugin-Container.exe" file, so that it's
DNSSEC based addons can use local DNS-Server (127.0.0.1) properly.

In my 1st message, i wrote:

> 
> And other computer's in LAN, VMs are configured to use 192.168.0.10
> as their's DNS-Server.
> 

But i did not explain HOW other computers were configured to use
that 192.168.0.10 Unbound DNS-Server, so here it goes:

Other computers, VMs which were configured to use that Win7 based
Unbound DNS-Server computer, are "client" of that Win7 based
DNS-Server computer.

These "client" computers had/running their own locally installed
Unbound software/service, and client side's Unbound software was
configured to work as a local validating DNS-Client or as a local
validating DNS-Resolver. Running as a service software/program. And
Unbound was running on local 127.0.0.1 (loopback) IP-Address.

(Here, "validating" means : doing DNSSEC based verification on chain
of domains/zones signing codes from DNS RR = Resource Records, to
obtain very accurate/authentic DNS records).

Windows, MacOSX's built-in DNS-Client or stub-resolver service
software was kept into "Disabled" state/mode, as these are not yet
able to do full DNSSEC based DNS resolving.

Network adapter/interface in client computers, were configured to
use local loopback IP-address 127.0.0.1 as their primary DNS-Server.

Those client side Unbound DNS-Resolvers, were configured to connect
with the Unbound DNS-Server (Win7) computer, which had 192.168.0.10
IP-address.

Client-side Unbound DNS-Resolvers had sightly different config lines:

(1) Root Zone forwarding section was enabled/activated. To goto this
section, find the line which has these "." <-- three exact
characters, aka root-zone. And DNS query were forwarded toward the
192.168.0.10 IP address. In clients, this section looked like below
3 lines now:

forward-zone:
	name: "."
	forward-addr: 192.168.0.10

(2) Config line "interface: 192.168.0.10" was disabled/de-activated.
(When a # hash symbol is placed in front a sentence or command (in
left-most side) in unbound/service config file, then it is
disabled/de-activated).

(3) Config line "outgoing-interface: 192.168.0.10" was disabled /
de-activated.

(4) Config line "access-control: 192.168.0.0/24 allow" was disabled
/ de-activated.

(5) There were also difference in insecure domain/zone related
configurations, and, stub-zone / forwarding zone related
configurations, in client side config file, than what was used in
server side config file. (Since stub & forwarding zones were already
placed in DNS-Server side config file, which was also using other
dns-resolver and tools for those stub & forwarding zones, ... so
client-side unbound was using simpler forwarding zones. May be i
will explain such config in latter post, if anyone interested.

So in client side software (which had option to specify DNS-Servers)
and client-side network interface, ... all were configured to
resolve DNS via only 127.0.0.1, nothing else. And that 127.0.0.1
based DNS-Resolver was actually connecting with 192.168.0.10 based
DNS-Server.

(Instead of allowing entire range to connect with DNS-Server, i
actually specified fixed IP of actual computers, using multiple
"access-control:" config command lines, but, for this discussion
sake, i will use entire subnet ip 192.168.0.0/24).

Firewall in client-side computers were configured further : to allow
Unbound DNS-Resolver (127.0.0.1) service software to create incoming
connections (from DNS-Server 192.168.0.10 IP-address) to local UDP &
TCP port 53 and 1025-65535 port-range, and incoming was allowed
toward only "unbound.exe" based service software (when firewall
supported such options), and outgoing connections (from Unbound
service software) was allowed toward (TCP & UDP) port 53 of
DNS-Server (192.168.0.10) IP-address. Similar firewall rules were
created for Mozilla Firefox's binary and firefox Plugin-Container
binary file, so that it's DNSSEC based addons can use DNS-Server
properly.

Since, the config is now right for various stub/forwarding zones,
i'm planning to move it onto a Linux/Unix based computer, and then
place it in a chroot/jail environment, and tweak it further with
linux/unix specific configurations. (For initial tests purpose, Win7
was a good candidate).

I hope all these info will clear up related questions and
configuration related understanding on these matters.

- - - - - - - - - -

PROBLEM(s):

On client-side computer,
I tried to visit and do "dig" on such(below) sites/zones/domains, i
observed these:

(These example sites which have .tld at-end actually does not exist,
i'm using such names, so its easier to explain problems).

signed.tld , s.tld (s = signed (DNSSEC signed), tld = top level domain).

unsigned.tld , u.tld (u = unsigned).

(unbound.net domain/zone is DNSSEC signed).

dig @127.0.0.1 ANY unbound.net.
dig @127.0.0.1 ANY unbound.net. +tcp
dig @127.0.0.1 ANY unbound.net. +dnssec

When i tried to "dig" for signed.tld type of sites/domains (from
client-side computer), using it's local dns-resolver 127.0.0.1,
(which actually obtains it's answer over TCP connection from LAN
DNS-Server 192.168.0.10), i observed, when a query's answer/result
had smaller amount of data, then local-side UDP (+tcp option was not
added) query, or, TCP (+tcp option was added) query, both worked.

When UDP or TCP based DNS queries (using "dig") for unsigned.tld
type of sites/zones/domains, then most (but not all), worked.

When UDP (+tcp option is not used) based "dig" DNS query for
unsigned.tld type of sites/domains are done, and if DNS query's
answer suppose to have large (amount of) answer/result data, then
such UDP query did not work some unsigned.tld. But most of the
"+tcp" option based DNS queries for unsigned.tld type of
sites/domains, worked.

I do not know what problems are exactly causing such (as above). If
anyone can shed more light, that would be great.

By using Firefox, which had "Extended DNSSEC Validator"
(www.os3sec.org), and, "DNSSEC Validator" (www.dnssec-validator.cz)
addons, and both were configured to use 127.0.0.1 as their
DNS-Server, ... i was able to visit almost all signed.tld type of
sites/zones/domains. But i could not visit or view webpages or
web-contents coming from some of the unsigned.tld type of
sites/domains. For example: oracle.com , etc. But other unsigned.tld
type of sites/domains were working properly.

I do not know exactly, why only some unsigned.tld type of domains
are not working on Firefox.
( I have been using older Unbound and a config file without any stub
or forwarding zones, in local computer as local DNS-Resolver, and
firefox had older addons, ... then i could visit these sites and
contents from such sites worked. But, once i added stub & forwarding
zones in Unbound and updated to newer Unbound, and firefox addons
were also updated, then these problems are exhibited. It could be
the addons' internal codings, or, newer Unbound, or, new
unbound-config file.)

Are NS / DNS Servers related to resolving those domains/zones were
not allowing TCP ? (as my-side Unbounds are configured to do TCP
based queries). Some type of timeout happening ? where ?

CPU usage of Unbound service software in (Win7) DNS-Server computer
goes very high, (when configured to work as a DNS server for LAN).

By using "Process Hacker" or "Process Explorer" type of tool, i can
see a windows thread having these info :
"sechost.dll!I_ScIsSecurityProcess+0x248" ... using massive amount
of CPU resources.

When Unbound was working as a DNS-Resolver only, and only for the
local computer itself (and using root NS / DNS servers for DNS query
resolving), in such role, Unbound was not causing high CPU usage in
Win7.

In Win-XP computer, when Unbound was used as DNS-Resolver for local
computer only, or, when used as DNS-Server for other computers in
LAN, for both cases CPU usage went very high, but when, at-least one
(or multiple) remote or LAN based DNS-Server is/are specified in
Unbound config (under Win-XP), then CPU usage was reasonable.

A thread with such info : "advapi32.dll!CryptVerifySignatureW+0x17"
using massive CPU resources.

Can unbound source codes be changed further ? not to use/access too
much Windows Registry ? if it is doing so now.

I will also remove all other stub & forwarding zones (other than
'root') and test again, to eliminate if it is factor or not.

- - - - - - - - - -

BENEFIT(s):

When UDP "dig" DNS queries are done for any signed.tld (DNSSEC
signed) type of sites/zones/domains, then answer/result have "AD"
flag and "NOERROR" status, so they are very accurate data, ... even
when "+dnssec" option is not used in "dig" query.

Since, client side local Unbound software is using a (LAN/remote
based) DNS-Server, at-least in Win-XP computers, CPU usage is not
jumping up, so it is now using reasonable level of CPU resources.

And also observed specific config related, other benefits, (as DNS
server assisting in resolving those).

- - - - - - - - - -

IF/WHEN YOU ARE REPLYING, PLEASE MAKE SURE TO
PLACE ONLY ONE/BELOW EMAIL ADDRESS IN THE
"TO:" FIELD/Text-Box:
unbound-users at unbound.net

Please do not send any email directly to me, Thanks.

-- Bright Star (Bry8Star).

Received from Bry8 Star, on 2013-05-23 5:32 PM:
> Hi staticsafe,
> 
> THANK YOU. :)
> 
> Config is updated, and Unbound service is restarted.
> 
> IF/WHEN YOU ARE REPLYING, PLEASE MAKE SURE TO
> PLACE ONLY ONE/BELOW EMAIL ADDRESS IN THE
> "TO:" FIELD/Text-Box:
> unbound-users at unbound.net
> 
> Please do not send any email directly to me, Thanks.
> 
> -- Bright Star.
> 
> 
> 
> Received from staticsafe, on 2013-05-23 4:27 PM:
>> On Thu, May 23, 2013 at 03:21:13PM -0700, Bright Star wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> Hello, Unbound Mailing List users & experts,
>>>
>>> Please check this below configuration, and let me know, IF this is
>>> fit and CORRECTLY CONFIGURED to work as a complete Validating
>>> DNS-Server / DNS-Resolver / DNS-Client for a Windows (7) OS based
>>> computer (which has 2GB RAM, 1 CPU Core), where it is currently
>>> installed and will run, and it will also have to serve, as a
>>> DNS-Server, for other computers and VMs (with different OSes) in
>>> local LAN.
>>>
>>> (Amount of free RAM memory size is large, so not a factor).
>>>
>>> Windows DNS Client service is set onto "Manual Startup" mode, so it
>>> is not running, and, local network adapter/interface is configured
>>> to use 127.0.0.1 as it's DNS-Server, in this (Win7) computer.
>>>
>>> And LAN network adapter/interface of this (Win7) computer is also
>>> using fixed/static IP address 192.168.0.10.
>>>
>>> And other computer's in LAN, VMs are configured to use 192.168.0.10
>>> as their's DNS-Server.
>>>
>>> Most websites/domains/zones are not yet signed with DNSSEC. I want
>>> this DNS-Server, still be able to send DNS query results for such
>>> unsigned websites to its users/clients. (DNS query answer will not
>>> have "AD" flag).
>>>
>>> I do NOT want this DNS-Server to completely block (or stop sending)
>>> DNS query results for ANY sites/zones which are not yet DNSSEC signed.
>>>
>>> Firefox will have DNSSEC Validation based addons which will be
>>> configured to use this DNS-Server. Firefox addons will display
>>> colored icon or message, when a website is visited, and icon will
>>> indicate if a website is signed or secured with DNSSEC yet or not.
>>> (DNS query answer will have "AD" flag and "NOERROR" status for
>>> DNSSEC signed sites/zones).
>>>
>>> There are other software which we are using, they do not have
>>> built-in support for doing any DNSSEC based query and cannot
>>> understand DNSSEC based answer, those software still need to be able
>>> to function (that is: sending regular DNS query, and receiving
>>> regular response via this DNS-Server).
>>>
>>> So IF CORRECTION is NEEDED to be done on this config, please provide
>>> correct + practical + real config line that can be used, please do
>>> not give examples, or confusing comments/response. I'm looking for
>>> practical configuration that will serve my purpose and work right
>>> now.  PLEASE describe ACCURATELY for what reason why a specific real
>>> config line is better or should be used what you are suggesting, and
>>> PLEASE describe what else need to be changed, exactly.
>>>
>>> Please do not assume, i will do or i'm suppose to do something
>>> automatically, so pls describe & explain.
>>>
>>> WHEN YOU ARE REPLYING, PLEASE MAKE SURE TO
>>> PLACE ONLY ONE/BELOW EMAIL ADDRESS IN THE
>>> "TO:" FIELD/Text-Box:
>>> unbound-users at unbound.net
>>>
>>> Please do not send any email directly to me, Thanks.
>>>
>>> PLEASE DO NOT SEND ANY EMAIL DIRECTLY TO ME, THANKS.
>>>
>>> Thanks (again) in advance,
>>> - -- Bright Star (Bry8Star).
>>> <SNIP>
> 
>> Only one thing stood out to me as an obvious error.
> 
>> access-control: 192.168.0.10 allow
> 
>> As you said, other computers in your LAN are supposed to use this DNS
>> resolver.
> 
>> The access-control statement should be as follows:
> 
>> access-control: 192.168.0.0/24 allow
> 
>> Assuming /24 as your LAN subnet mask.
> 
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at unbound.net
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20130526/de83b1db/attachment.bin>