[Yeti DNS Discuss] Yeti testbed experience I-D on Github

[Stephane Bortzmeyer]

On Tue, Apr 26, 2016 at 07:12:01PM +0800,
 Davey Song <ljsong at biigroup.cn> wrote 
 a message of 126 lines which said:

> https://github.com/BII-Lab/yeti-testbed-experience

> IPv6 introduces larger IP packet MTU (1280 bytes)

Larger *minimum* MTU.
      
> Is the 512 bytes DNS packet size limitation still observed?

It is not clear why this sentence is in this paragraph, which is abot
KSK rollover.

> How about longer key with different encryption algorithm?

All possible "alternative" algorithms (ECDSA, Ed25519) have *shorter*
keys.

> There is no dynamic update mechanism to inform resolvers and other
> Internet infrastructure relying on root service of such changes.

Priming is such a mechanism and should be mentioned.

> except the top level apex record

"top level" and "apex" are redundant.

> 6 operators use Linux (including Ubuntu, Debian, CentOS).

And ArchLinux !

> Since the DNSSEC key of the Yeti root (the KSK) changes often
> (typically every three months),

This is currently false.

> Traditional ways include using FTP protocol by doing a wget and
> using dig to get the servers' addresses manually.

I don't get it. The hints file contain the IP addresses of the servers
(the glue). What's the purpose of dig?

> This experiment proposal aims to find an automatic way for hint-file
> updating.

As an experimentation, I have no problem with it, but, in production,
it seems way too brittle, specially without proper monitoring
(thinking of it, this is also why I don't use Let's Encrypt).

And the rythm of changes in the root name servers is low enough that
it is not a problem in practice: a hints file of 13 years ago still
works, thanks to priming.

> The question is how can authority server know the resolver is ready
> for RFC5011 some drafts

Also, a big problem is whether it will work or not. Typical example: a
key directory with wrong protections, preventing to write the key. I
just tested the very last Unbound (1.5.8) and, if the
auto-trust-anchor-file is not writable, it does not complain and does
not even warn. (It just tries to open the file for reading.)
<https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=758>

> [RFC1035]specifies DNS massage compression scheme

After a lot of DNS debugging, a massage is nice :-)

> [Hintfile-Auto-Update]
>              "Hintfile Auto Update", 2015,
>              <https://github.com/BII-Lab/Hintfile-Auto-Update>.

Do note the syntax it uses is specific to BIND and Unbound. Knot
Resolver, for instance, uses a completely different syntax for its
hints file (see
<https://github.com/BII-Lab/Yeti-Project/blob/master/README.md>)