Bug 567 - there's no way to ask unbound whether a forward zone is secure or insecure
there's no way to ask unbound whether a forward zone is secure or insecure
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
unspecified
Other Linux
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-19 11:51 CET by Pavel Šimerda (pavlix)
Modified: 2014-06-06 17:05 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Šimerda (pavlix) 2014-03-19 11:51:54 CET
unbound-control list_forwards prints the list of forward zones and their respective name servers but doesn't indicate whether the forward zones are secure or insecure. For integration between unbound, dnssec-trigger and other tools including networkmanager, this is critical information which allows to check and update unbound's configuration only when a change is needed.
Comment 1 Wouter Wijngaards 2014-03-19 12:05:53 CET
Hi Pavel,

That seems to be missing, would you like a listing that lists all the domain-insecure elements, or some sort of +i style annotation ; I would like to keep the output of the forwards_list easily parsable and backwards compatible ...

Best regards, 
   Wouter
Comment 2 Tomas Hozza 2014-03-19 12:09:35 CET
(In reply to comment #1)
> That seems to be missing, would you like a listing that lists all the
> domain-insecure elements, or some sort of +i style annotation ; I would like
> to keep the output of the forwards_list easily parsable and backwards
> compatible ...

Hi Wouter.

I'm "voting" for some "+i" notation, to keep it consistent with the way
how forward zones are configured.
Comment 3 Pavel Šimerda (pavlix) 2014-03-19 12:11:57 CET
(In reply to comment #2)
> Hi Wouter.
> 
> I'm "voting" for some "+i" notation, to keep it consistent with the way
> how forward zones are configured.

+1 from me
Comment 4 Wouter Wijngaards 2014-03-19 12:59:02 CET
Thanks for the votes :-) (setting bug status which was missing)
Comment 5 Wouter Wijngaards 2014-04-10 12:55:43 CEST
Hi Pavel, Tomas,

Implemented.  In svn trunk.  Prints +i  (example.net. IN forward +i: 192.0.2.1).

Best regards, Wouter
Comment 6 Tomas Hozza 2014-04-10 13:11:15 CEST
(In reply to comment #5)
> Hi Pavel, Tomas,
> 
> Implemented.  In svn trunk.  Prints +i  (example.net. IN forward +i:
> 192.0.2.1).
> 
> Best regards, Wouter

Thank you very much Wouter...
Comment 7 Pavel Šimerda (pavlix) 2014-04-10 13:22:22 CEST
Thanks, I'll sent the related patch to dnssec-trigger ASAP.
Comment 8 Wouter Wijngaards 2014-04-10 13:24:26 CEST
The patch is svn diff -r 3108:3109 daemon/remote.c
Index: daemon/remote.c
===================================================================
--- daemon/remote.c	(revision 3108)
+++ daemon/remote.c	(revision 3109)
@@ -1948,10 +1948,23 @@
 	/* since its a per-worker structure no locks needed */
 	struct iter_forwards* fwds = worker->env.fwds;
 	struct iter_forward_zone* z;
+	struct trust_anchor* a;
+	int insecure;
 	RBTREE_FOR(z, struct iter_forward_zone*, fwds->tree) {
 		if(!z->dp) continue; /* skip empty marker for stub */
-		if(!ssl_print_name_dp(ssl, "forward", z->name, z->dclass,
-			z->dp))
+
+		/* see if it is insecure */
+		insecure = 0;
+		if(worker->env.anchors &&
+			(a=anchor_find(worker->env.anchors, z->name,
+			z->namelabs, z->namelen,  z->dclass))) {
+			if(!a->keylist && !a->numDS && !a->numDNSKEY)
+				insecure = 1;
+			lock_basic_unlock(&a->lock);
+		}
+
+		if(!ssl_print_name_dp(ssl, (insecure?"forward +i":"forward"),
+			z->name, z->dclass, z->dp))
 			return;
 	}
 }
@@ -1961,9 +1974,24 @@
 do_list_stubs(SSL* ssl, struct worker* worker)
 {
 	struct iter_hints_stub* z;
+	struct trust_anchor* a;
+	int insecure;
+	char str[32];
 	RBTREE_FOR(z, struct iter_hints_stub*, &worker->env.hints->tree) {
-		if(!ssl_print_name_dp(ssl, 
-			z->noprime?"stub noprime":"stub prime", z->node.name,
+
+		/* see if it is insecure */
+		insecure = 0;
+		if(worker->env.anchors &&
+			(a=anchor_find(worker->env.anchors, z->node.name,
+			z->node.labs, z->node.len,  z->node.dclass))) {
+			if(!a->keylist && !a->numDS && !a->numDNSKEY)
+				insecure = 1;
+			lock_basic_unlock(&a->lock);
+		}
+
+		snprintf(str, sizeof(str), "stub %sprime%s",
+			(z->noprime?"no":""), (insecure?" +i":""));
+		if(!ssl_print_name_dp(ssl, str, z->node.name,
 			z->node.dclass, z->dp))
 			return;
 	}
Comment 9 Pavel Šimerda (pavlix) 2014-05-05 10:26:41 CEST
Just tested....

# unbound-control list_forwards
lan. IN forward +i: 2a00:1268:1ff:f001::1 84.246.161.81

Before, there was a colon (:) after forward, now it's after +1. When it's parsed by e.g. dnssec-trigger, we will need to strip it anyway. I think it would be nice if the colon was removed from the output in unbound.

Cheers,

Pavel
Comment 10 Pavel Šimerda (pavlix) 2014-05-05 11:46:26 CEST
I'm also curious whether 'IN' and 'forward' are necessary at all.
Comment 11 Wouter Wijngaards 2014-05-05 16:47:52 CEST
Hi Pavel,

The : is removed from the output, also for stub listings.

Best regards,
   Wouter
Comment 12 Wouter Wijngaards 2014-05-05 16:48:49 CEST
The IN and forward are there to tell you that this is not a stub.  Class IN is because unbound supports the DNS classes, even though this is unused.

Best regards, Wouter
Comment 13 Pavel Šimerda (pavlix) 2014-05-05 16:59:02 CEST
(In reply to comment #11)
> Hi Pavel,
> 
> The : is removed from the output, also for stub listings.
> 
> Best regards,
>    Wouter

Thanks!

(In reply to comment #12)
> The IN and forward are there to tell you that this is not a stub.  Class IN
> is because unbound supports the DNS classes, even though this is unused.
> 
> Best regards, Wouter

Sure. I was just comparing the commands to add forward zones with the listing.
Comment 14 Pavel Šimerda (pavlix) 2014-06-06 17:05:39 CEST
With the : removed from the output, I consider this fixed.