<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Thu, 19 Jul 2018 at 14:56, Calvin Browne <<a href="mailto:calvin@orange-tree.alt.za">calvin@orange-tree.alt.za</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Seems it is an issue with Afrinic's anycast and an older version of NSD <br>
- Afrinic said they'll fix it shortly.<br><br></blockquote><div><br></div><div>Hmm, not exactly.</div><div><br></div><div>Indeed we did pick up an issue with some nodes. However, it is, I believe, a *different* issue to what Viktor posted (based on looking in detail at his dnsviz links). I stand to be corrected.</div><div><br></div><div>We also serve what we're given with NSD. In some locations 4.1.16. In "older" locations, 4.1.3.</div><div><br></div><div>What we've identified thanks to Calvin is that, although the zone data is identical, the 4.1.16 nodes are consistent with all other NS's for this zone, whereas the 4.1.3 locations serve up less NSEC3 RRs to the same query.</div><div><br></div><div>This does seem to be a bug in the older NSD version. The use-case here is NSEC3 non-existence proofs in an opt-out signed zone. We've not yet tested other sorts of queries/zones. However we will (as Calvin mentioned), be upgrading the NSD version on the "troublesome" instances early next week.</div><div><br></div><div>Cheers,</div><div>Daniel Shaw</div><div>(AFRINIC)</div><div><br></div><div><br></div><div> </div></div></div>