Can't dig +trace?
I have unbound running and clients using dig seem not to be able to trace? dig +trace www.amiga.com ; DiG 9.6.2-P2 +trace www.amiga.com ;; global options: +cmd ;; Received 12 bytes from MY-UNBOUND-IP#53(MY-UNBOUND-IP) in 0 ms However if I hit Google's lookup servers with the same command from the same client machine, I get the expected response... dig +trace @8.8.8.8 www.amiga.com ; DiG 9.6.2-P2 +trace @8.8.8.8 www.amiga.com ; (1 server found) ;; global options: +cmd . 8647IN NS b.root-servers.net. . 8647IN NS g.root-servers.net. . 8647IN NS c.root-servers.net. . 8647IN NS i.root-servers.net. . 8647IN NS j.root-servers.net. . 8647IN NS h.root-servers.net. . 8647IN NS e.root-servers.net. . 8647IN NS m.root-servers.net. . 8647IN NS f.root-servers.net. . 8647IN NS a.root-servers.net. . 8647IN NS l.root-servers.net. . 8647IN NS k.root-servers.net. . 8647IN NS d.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms com.172800 IN NS h.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. ;; Received 503 bytes from 192.203.230.10#53(e.root-servers.net) in 92 ms amiga.com. 172800 IN NS ns15.domaincontrol.com. amiga.com. 172800 IN NS ns16.domaincontrol.com. ;; Received 115 bytes from 192.12.94.30#53(e.gtld-servers.net) in 126 ms www.amiga.com. 3600IN CNAME amiga.com. amiga.com. 600 IN A 68.115.249.34 amiga.com. 3600IN NS ns16.domaincontrol.com. amiga.com. 3600IN NS ns15.domaincontrol.com. ;; Received 113 bytes from 208.109.255.8#53(ns16.domaincontrol.com) in 24 ms drill -T www.amiga.com seems to do the job these days. I guess I am just mostly curious what about Unbound keeps good ol' dig +trace from working? TIA FONG - shot through the heart ooh baby do you know what that's worth and you're to blame ooh heaven is a place on earth darling you give love they say in heaven love comes first a bad name we'll make heaven a place on earth ORBITAL Halcyon Live
Re: Can't dig +trace?
# control which clients are allowed to make (recursive) queries # to this server. Specify classless netblocks with /size and action. # By default everything is refused, except for localhost. # Choose deny (drop message), refuse (polite error reply), # allow (recursive ok), *allow_snoop (recursive and nonrecursive ok)* # access-control: 0.0.0.0/0 refuse *access-control: 127.0.0.0/8 allow_snoop* On 07/28/2015 04:01 PM, Fongaboo via Unbound-users wrote: I have unbound running and clients using dig seem not to be able to trace? dig +trace www.amiga.com ; DiG 9.6.2-P2 +trace www.amiga.com ;; global options: +cmd ;; Received 12 bytes from MY-UNBOUND-IP#53(MY-UNBOUND-IP) in 0 ms However if I hit Google's lookup servers with the same command from the same client machine, I get the expected response... dig +trace @8.8.8.8 www.amiga.com ; DiG 9.6.2-P2 +trace @8.8.8.8 www.amiga.com ; (1 server found) ;; global options: +cmd . 8647IN NS b.root-servers.net. . 8647IN NS g.root-servers.net. . 8647IN NS c.root-servers.net. . 8647IN NS i.root-servers.net. . 8647IN NS j.root-servers.net. . 8647IN NS h.root-servers.net. . 8647IN NS e.root-servers.net. . 8647IN NS m.root-servers.net. . 8647IN NS f.root-servers.net. . 8647IN NS a.root-servers.net. . 8647IN NS l.root-servers.net. . 8647IN NS k.root-servers.net. . 8647IN NS d.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms com.172800 IN NS h.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. ;; Received 503 bytes from 192.203.230.10#53(e.root-servers.net) in 92 ms amiga.com. 172800 IN NS ns15.domaincontrol.com. amiga.com. 172800 IN NS ns16.domaincontrol.com. ;; Received 115 bytes from 192.12.94.30#53(e.gtld-servers.net) in 126 ms www.amiga.com. 3600IN CNAME amiga.com. amiga.com. 600 IN A 68.115.249.34 amiga.com. 3600IN NS ns16.domaincontrol.com. amiga.com. 3600IN NS ns15.domaincontrol.com. ;; Received 113 bytes from 208.109.255.8#53(ns16.domaincontrol.com) in 24 ms drill -T www.amiga.com seems to do the job these days. I guess I am just mostly curious what about Unbound keeps good ol' dig +trace from working? TIA FONG - shot through the heart ooh baby do you know what that's worth and you're to blame ooh heaven is a place on earth darling you give love they say in heaven love comes first a bad name we'll make heaven a place on earth ORBITAL Halcyon Live
Re: Can't dig +trace?
Fongaboo via Unbound-users writes: I have unbound running and clients using dig seem not to be able to trace? dig +trace www.amiga.com ; DiG 9.6.2-P2 +trace www.amiga.com ;; global options: +cmd ;; Received 12 bytes from MY-UNBOUND-IP#53(MY-UNBOUND-IP) in 0 ms However if I hit Google's lookup servers with the same command from the same client machine, I get the expected response... The +trace option causes dig not to use the local resolver. From the dig manual: +[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup. So it is unlikely that this is related to unbound. jaap
Re: Using unbound-anchor for non-default trust anchor
On Tue, 28 Jul 2015, Edward Lewis via Unbound-users wrote: unbound-anchor, by default, pulls DNSSEC trust anchors from data.iana.org. I am trying to test RFC 5011 capabilities by following these websites: http://keyroll.systems and http://icksk.dnssek.info/fauxroot.html Goal is to run unbound-anchor as a first step before trying to tune unbound to either of those experiments. Have you tried using /etc/hosts entries for data.iana.org pointing to the others? :) More seriously, from the man page: -u name The server name, it connects to https://name. Specify without https:// prefix. The default is data.iana.org. It connects to the port specified with -P. You can pass an IPv4 addres or IPv6 address (no brackets) if you want. -x path The pathname to the root-anchors.xml file on the server. (forms URL with -u). The default is /root-anchors/root-anchors.xml. -s path The pathname to the root-anchors.p7s file on the server. (forms URL with -u). The default is /root-anchors/root-anchors.p7s. This file has to be a PKCS7 signature over the xml file, using the pem file (-c) as trust anchor. Paul
Re: Using unbound-anchor for non-default trust anchor
Edward Lewis via Unbound-users wrote:
unbound-anchor, by default, pulls DNSSEC trust anchors from data.iana.org.
I am trying to test RFC 5011 capabilities by following these websites:
http://keyroll.systems
and
http://icksk.dnssek.info/fauxroot.html
Goal is to run unbound-anchor as a first step before trying to tune
unbound to either of those experiments.
Hi, Ed:
IIRC, the HTTPS fetch from data.iana.org in unbound-anchor is a
fallback, if the RFC 5011 stuff fails. You still ought to be able to
test the RFC 5011 stuff alone, if that's what you're trying to do.
I copied the root.db file at the bottom of
http://keyroll.systems/current into /tmp/root.db (would be nice if this
were downloadable as a separate file), and then tried unbound-anchor
with that root zone against the three most recent key files (at the
time) from the bottom of http://keyroll.systems/historic:
# Most recent key.
edmonds@chase{0}:~$ curl -so /tmp/root.key
http://keyroll.systems/static/K.+008+55039.key
edmonds@chase{0}:~$ unbound-anchor -v -r /tmp/root.db -a /tmp/root.key
/tmp/root.key has content
[1438110527] libunbound[7108:0] warning: root hints /tmp/root.db:16
skipping type SOA
[1438110527] libunbound[7108:0] warning: root hints /tmp/root.db:26
skipping type TXT
success: the anchor is ok
# Second most recent key.
edmonds@chase{0}:~$ curl -so /tmp/root.key
http://keyroll.systems/static/K.+008+27079.key
edmonds@chase{0}:~$ unbound-anchor -v -r /tmp/root.db -a /tmp/root.key
/tmp/root.key has content
[1438110543] libunbound[7113:0] warning: root hints /tmp/root.db:16
skipping type SOA
[1438110543] libunbound[7113:0] warning: root hints /tmp/root.db:26
skipping type TXT
success: the anchor is ok
# Third most recent key.
edmonds@chase{0}:~$ curl -so /tmp/root.key
http://keyroll.systems/static/K.+008+42496.key
edmonds@chase{0}:~$ unbound-anchor -v -r /tmp/root.db -a /tmp/root.key
/tmp/root.key has content
[1438110556] libunbound[7118:0] warning: root hints /tmp/root.db:16
skipping type SOA
[1438110556] libunbound[7118:0] warning: root hints /tmp/root.db:26
skipping type TXT
last successful probe: Tue Jul 28 15:09:16 2015
the last successful probe is recent
fail: the anchor is NOT ok and could not be fixed
edmonds@chase{0}:~$ cat /tmp/root.key
; autotrust trust anchor file
;;REVOKED
; The zone has all keys revoked, and is
; considered as if it has no trust anchors.
; the remainder of the file is the last probe.
; to restart the trust anchor, overwrite this file.
; with one containing valid DNSKEYs or DSes.
;;id: . 1
;;last_queried: 1438110556 ;;Tue Jul 28 15:09:16 2015
;;last_success: 1438110556 ;;Tue Jul 28 15:09:16 2015
;;next_probe_time: 0 ;;Wed Dec 31 19:00:00 1969
;;query_failed: 0
;;query_interval: 0
;;retry_time: 0
. 3600IN DNSKEY 385 3 8
AwEAAct/IgeZiHmphBTGCJUxJNd1hy9uuqUJFtIsdJgyMr+LLnTjbqXkAF47BskHvSIrlQlIc/SDTDLtUktpM/IVWAjolSsP1+oNYwTi56WwW9nyc+vuJkPG8sxza1p7c7PoTegb2JPPEsmkLGMEDz0kliWHSZkinr9yB1/LxI3SBAYq17Od3CuIAWyU0F0pVxqJwJn/jWI4z1FdSwU9cGhx+/g8FvrnrOkOMyj08g4LlYf5PBpopB+Cz2JNOFa6DRr2WyUuVvbTa9ZnBCOTHcUsaoqVdvs3fihvcdpfWonHm7aJvyUnB3CiUQz/iIzvYTtx3+OF8+mOjy0qFX+Zk4KUg6U=
;{id = 42624 (ksk), size = 2048b} ;;state=4 [ REVOKED ] ;;count=0
;;lastchange=1438110556 ;;Tue Jul 28 15:09:16 2015
edmonds@chase{0}:~$
Hope this helps!
--
Robert Edmonds
edmo...@debian.org
