9.11.3-S1 totext_nsec3 inserts a redundant white space between next hash and type map [ISC-support #12887]

It now inserts two spaces like this:

1 0 10 333CE2965C8CED75929F 8EJE0O8JKCEL3SGRS8KK18ATDP6EQ270  NS SOA RRSIG DNSKEY NSEC3PARAM

That's still a valid textual representation standard-wise, but would look a bit more awkward. Furthermore, for us specifically it would break an assumption of an RDATA text matching script, so it's not only cosmetic.

The redundant space is inserted because rdata.c:typemap_totext() initializes 'first' to false (which is obviously wrong):

typemap_totext(isc_region_t *sr, dns_rdata_textctx_t *tctx,
	       isc_buffer_t *target)
{
	unsigned int i, j, k;
	unsigned int window, len;
	isc_boolean_t first = ISC_FALSE;

But fixing it would then break totext_nsec(). You'll now need to add a space before calling typemap_totext() as follows:

@@ -65,6 +65,7 @@ totext_nsec(ARGS_TOTEXT) {
 	dns_name_fromregion(&name, &sr);
 	isc_region_consume(&sr, name_length(&name));
 	RETERR(dns_name_totext(&name, ISC_FALSE, target));
+	RETERR(str_totext(" ", target));
 	return (typemap_totext(&sr, NULL, target));
 }

Whether the added space was intentional or not, I'd also point it out it should have been easily detected (in case it was intentional) or assured (in case it was intentional) with a simple test in rdata_test.c (something similar to the 'nsec' test). I'd suggest you adding tests like that whenever you try to tweak textual output.