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@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:
