[Yeti DNS Discuss] Yeti priming consistency

[Shane Kerr]

All,

Here's the second issue with our Yeti root servers: wildly differing
answers to priming queries.

Lets use bii.dns-lab.net as a starting point:

$ dig +tcp +noall +answer . -t ns @240c:f:1:22::6 | sort
.			518400	IN	NS	bii.dns-lab.net.
.			518400	IN	NS	dahu1.yeti.eu.org.
.			518400	IN	NS	ns-yeti.bondis.org.
.			518400	IN	NS	yeti.bofh.priv.at.
.			518400	IN	NS	yeti-ns.as59715.net.
.			518400	IN	NS	yeti-ns.ix.ru.
.			518400	IN	NS	yeti-ns.tisf.net.
.			518400	IN	NS	yeti-ns.wide.ad.jp.

These are the 8 that are currently in our named.cache file.

At all of the name servers *except* bii.dns-lab.net we see the
following difference:

+.			518400	IN	NS	ns2.ipv6.ernet.in.
-.			518400	IN	NS	yeti.bofh.priv.at.

Neither the ns2.ipv6.ernet.in nor the yeti.bofh.priv.at servers seem to
currently be answering, which seems bad.

So, we currently seem to have 3 (or maybe 4) problems:

1. bii.dns-lab.net disagrees with all other Yeti servers when
   responding to a priming query (this also happens to be the contents
   of named.cache) 

2. ns2.ipv6.ernet.in is in most answers to the priming query, but does
   not respond

3. yeti.bofh.priv.at is in the answer to the bii.dns-lab.net priming
   query, but does not respond


I admit I don't know where this difference comes from. This comes at
least partially because I don't know what the process is for onboarding
a new Yeti root. :(  Is this documented anywhere? If not, this seems
like a high priority.

A secondary priority is to automate checks for priming query
consistency.

Cheers,

--
Shane