cloud-init team mailing list archive

[Florian Weimer <fw@xxxxxxxxxxxxx>]

glibc 2.31 has support for recognizing that the name servers listed in
/etc/resolv.conf are reached over a trusted network path and implement
DNSSEC correctly (but do not necessarily perform validation):

* The DNS stub resolver will optionally send the AD (authenticated data) bit
  in queries if the trust-ad option is set via the options directive in
  /etc/resolv.conf (or if RES_TRUSTAD is set in _res.options).  In this
  mode, the AD bit, as provided by the name server, is available to
  applications which call res_search and related functions.  In the default
  mode, the AD bit is not set in queries, and it is automatically cleared in
  responses, indicating a lack of DNSSEC validation.  (Therefore, the name
  servers and the network path to them are treated as untrusted.)

I think cloud-init needs a way to propagate this information the
instance data injection.  It may make sense to set trust-ad by default
for certain injection methods, but I am not sure.  In order to get the
desired AD bit semantics, two things are required:

  * When sending and receiving packets to the addresses indicated in
    /etc/resolv.conf, the communication must happen with the DNS
    resolver on these IP addresses.

  * The DNS resolver uses a subset of the expected DNSSEC trust
    anchors and sets the AD bit according to RFC 4035 section 3.2.3.
    Roughly, this means that if the bit is set, the data in the
    response is DNSSEC-signed.  It is valid for the DNS resolver never
    to set the AD bit (e.g., if it does not perform DNSSEC
    validation).

I expect that most environments where network-based injection methods
are used have the second property (just because such environments are
relatively new and use industry-standard resolver implementations),
but I have no hard data on that.

I don't know how strict the anti-spoofing provisions in typical cloud
environments are.  One can hope that they are airtight, but maybe not.

On the other hand, if cloud-init is used to configure a pre-built
QCOW2 image in a workstation virtualization context, it's hard to tell
if the environment can be trusted to perform DNSSEC validation
securely.

Thoughts?