<div dir="ltr">Hi Graham,<br><div><br>On Wed, Nov 19, 2014 at 11:59 AM, Graham Clinch <span dir="ltr"><<a href="mailto:g.clinch@lancaster.ac.uk" target="_blank">g.clinch@lancaster.ac.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Using bind 9.9.5 with inline-signing, I have a test wildcard cname<br>
record in two zones:<br>
<br>
*.<a href="http://cnametest.lancs.ac.uk" target="_blank">cnametest.lancs.ac.uk</a> CNAME <a href="http://www.lancs.ac.uk" target="_blank">www.lancs.ac.uk</a><br>
*.<a href="http://cnametest.palatine.ac.uk" target="_blank">cnametest.palatine.ac.uk</a> CNAME <a href="http://www.palatine.ac.uk" target="_blank">www.palatine.ac.uk</a><br>
<br>
dnsviz is showing the error<br>
"NSEC3 proving non-existence of foo.cnametest.lancs.ac.uk./CNAME:<br>
QNAME_NOT_COVERED"<br>
for the <a href="http://lancs.ac.uk" target="_blank">lancs.ac.uk</a> version (but the <a href="http://palatine.ac.uk" target="_blank">palatine.ac.uk</a> version is fine).<br>
<br></blockquote><div><br></div><div>My apologies - this was actually a bug in DNSViz.  The NSEC3 computation was being performed on the wrong name (the wrong origin was being applied).  It should be fixed now, as shown in:<br><br><a href="http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/" target="_blank">http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/</a><br><a href="http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/" target="_blank">http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/</a><br>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
...<br>
For <a href="http://palatine.ac.uk" target="_blank">palatine.ac.uk</a>:<br>
<br>
<a href="http://AEP7P2GGD4GEBNRMSBP4I97SU0MKR5R9.palatine.ac.uk" target="_blank">AEP7P2GGD4GEBNRMSBP4I97SU0MKR5R9.palatine.ac.uk</a>. 3600 IN NSEC3 1 0 10<br>
BB1150B39E44B92F E92VAEN6BQ1T2N54AA2RSA1V49RM394S<br>
<br>
(AEP... is the hash of <a href="http://cnametest.palatine.ac.uk" target="_blank">cnametest.palatine.ac.uk</a>)<br>
<br></blockquote><div><br></div><div>Yes, but more importantly it happens to be the owner name of the NSEC3 record that covers the NSEC3 hash of the next closest encloser (<a href="http://foo.cnametest.palatine.ac.uk">foo.cnametest.palatine.ac.uk</a>, whose hash starts with E8T9...).  The fact that it also matches the NSEC3 hash of the closest encloser (<a href="http://cnametest.palatine.ac.uk">cnametest.palatine.ac.uk</a>) is coincidental (and also probabilistic, depending on the size of the zone).<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For <a href="http://lancs.ac.uk" target="_blank">lancs.ac.uk</a>:<br>
<br>
<a href="http://RA9FSQ8NSK36A6568UHF8L26UFV2B1PG.lancs.ac.uk" target="_blank">RA9FSQ8NSK36A6568UHF8L26UFV2B1PG.lancs.ac.uk</a>. 3600 IN NSEC3 1 0 10<br>
9B6EFFBA177399A0 RA9V2QS7NE6Q5VLKU2EF4QONHP5CGIJR A RRSIG<br>
<br>
(RA9... isn't the hash of <a href="http://cnametest.lancs.ac.uk" target="_blank">cnametest.lancs.ac.uk</a>, and it's claiming there<br>
are A and RRSIG records!?).<br></blockquote><div><br></div><div>Correct - this is the hash of some other record, the record that covers the hash of the next closest encloser (<a href="http://foo.cnametest.lancs.ac.uk">foo.cnametest.lancs.ac.uk</a>).  The hash of the closest encloser is not necessary as this is for a wildcard response, and the closest encloser (<a href="http://cnametest.lancs.ac.uk">cnametest.lancs.ac.uk</a>) can be inferred from the labels field in the RRSIG.  In this case, the number of labels (i.e., in the RRSIG) is 4, so the closest encloser is <a href="http://cnametest.lancs.ac.uk">cnametest.lancs.ac.uk</a>.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Both cnametest records were added today, so the signature inception time<br>
of the <a href="http://lancs.ac.uk" target="_blank">lancs.ac.uk</a> NSEC3's RRSIG being yesterday (20141118125729), is<br>
very odd...<br></blockquote><div><br></div><div>Again, the NSEC3 in question corresponds to some other (most likely) preexisting name, so it is not surprising that the inception date on its RRSIG is older than today.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What's going on?  Both zones are being signed by the same instance of<br>
bind and there are no interesting log messages.<br></blockquote><div><br></div><div>Hope that helps.<br><br>Cheers,<br>Casey<br></div></div></div></div></div>