<div dir="ltr">On Mon, Jan 20, 2014 at 4:11 PM, Matthew Pounsett <span dir="ltr"><<a href="mailto:matt@conundrum.com" target="_blank">matt@conundrum.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Jan 20, 2014, at 11:37 , 🔒 Roy Arends <<a href="mailto:roy@dnss.ec">roy@dnss.ec</a>> wrote:<br>
<br>
> The problem is indeed the absence of type NS in the type bit maps, as you (and Peter van<br>
> Dijk) showed in your previous mail.<br>
<br>
</div>It’s hard to see from outside since its all the same NS set, but I suspect red. and nic.red. are separate zones, but that there is no delegation from red. to nic.red.  I’ve seen that mistake before.  With the same NS set it wouldn’t appear as a problem prior to signing.<br>

<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>That could be the case (the issue appears to be fixed now).  In the past when I've seen this the authoritative server returns NXDOMAIN status, rather than NOERROR, as the name (according the delegating parent zone, which answers for DS) does not exist.  In this case, the name does appear to exist, but with no record types.  I'm guessing that is because there is some "sibling glue" in the "red" zone for another delegation, which NS records include server names in "nic.red".  Interesting find - I hadn't seen this scenario before.<br>
<br></div><div>Casey <br></div></div></div></div>