We advertise labs-ns0.wikimedia.org and labs-ns1.wikimedia.org as nameservers for the wmflabs.org., 128-25.155.80.208.in-addr.arpa., and now 56.15.185.in-addr.arpa. zones when delegating to them. But when you actually query NS records for those zones from labs-ns*, two extra ones are revealed by Designate: labs-ns2.wikimedia.org and labs-ns3.wikimedia.org. This was brought up in #wikimedia-traffic:
<bblack> Krenair: re the right/wrongness of listing labs-ns[23] in the local zone data NS records: I don't know designate well, but it could be tacking that information onto lots of responses, which will pollute caches with it quickly. <bblack> Krenair: but even if it doesn't include unecessary NS records with normal responses, if anyone does an explicit query for NS records through a recursive cache, it may learn them that way and try to use them. Depends on the cache implementation. <bblack> Krenair: so if ns[23] aren't meant to be used yet (testing and/or unreliable), they probably shouldn't be there JIC <paravoid> Krenair: the disparity between what labs-ns think it's their NSes, and what .org and now RIPE think is a bug either way, so I'd open a task :)
<Krenair> andrewbogott, what's the deal with labs-ns0[23] ? <Krenair> It seems they're not advertised but designate has them as nameservers for stuff <andrewbogott> 2 and 3 are cloudservices1003 and 1004. They're a designate cluster that gets notifications for VMs created in eqiad1-r (by listening to the 1-r rabbit) <andrewbogott> So when we turn off eqiad they'll become the main cloud nameservers. I might rename them to labs-ns0 and labs-ns1 when that happens. <Krenair> okay <Krenair> so at some point it's planned for them to disappear? <andrewbogott> probably <andrewbogott> but their state should be consistent with 0 and 1
(there's also talk about them becoming cloud-ns instead of labs-ns later)