draft-ietf-dnsop-root-loopback questions

[Robert Edmonds]

Hi,

draft-ietf-dnsop-root-loopback
(https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-05)
specifies a technique to run a copy of the root zone on a loopback
address in order to "decrease the round trip time and prevent
observation of requests".

Appendix B shows an example configuration for Unbound:

B.2.  Example Configuration: Unbound 1.4 and NSD 4

   Unbound and NSD are separate software packages.  Because of this,
   there is no "fate sharing" between the two servers in the following
   configurations.  That is, if the root server instance (NSD) dies, the
   recursive resolver instance (Unbound) will probably keep running, but
   will not be able to resolve any queries for the root zone.
   Therefore, the administrator of this configuration might want to
   carefully monitor the NSD instance and restart it immediately if it
   dies.

   Using this configuration, queries for information in the root zone
   are returned with the AA bit not set.

   # Configuration for Unbound
   server:
       do-not-query-localhost: no
   stub-zone:
       name: "."
       stub-prime: no
       stub-addr: 127.12.12.12

   [...]

Is there any reason not to add "stub-first: yes" to the stub-zone
declaration?

   stub-first: <yes or no>
          If  enabled,  a query is attempted without the stub clause if it
          fails.  The data could not be retrieved and  would  have  caused
          SERVFAIL  because  the  servers  are  unreachable, instead it is
          tried without this clause.  The default is no.

If Unbound failed back to full recursion, it would negate the benefits
of having a root zone server on loopback but would otherwise continue to
resolve normally, right?  For many (most?) users that may be preferable
to losing resolution service completely.

Does Unbound generate log messages when stub-zone servers become
unreachable, or become reachable after being unreachable?  If not, it
would seem like this would be a desireable feature to have for those
wanting to deploy this configuration.

Also, is "stub-first" reachability information stored in the infra
cache?

-- 
Robert Edmonds
edmonds at debian.org