DNSSEC in stub resolver from scratch

DNSSEC in stub resolver from scratch

[Petr Špaček via Libc-alpha]

Hello everyone,

this is follow-up to
https://sourceware.org/pipermail/libc-alpha/2020-May/114224.html
as requested by Carlos O'Donell.

On 21. 05. 20 17:23, Carlos O'Donell wrote:
> I've updated the wiki to indicate the RES_TRUSTAD feature was released
> in glibc 2.31 on 2020-02-01.
> 
> We should start a distinct thread to discuss specific issues.
> 
> Such discussions should start from first principles, point out relevant
> standards (as are pointed out in this discussion, thank you Petr), and
> why the glibc implementation has a particular failing, and what an
> alternative solution would look like.

Let's start from the very the beginning:

0] DNS conflates two _distinct_ protocols on port 53. Protocols between:
 a) stub (i.e. libc) <-> recursive resolver, and
 b) resolver <-> authoritative server
are _different_ despite being sent on port 53 using the same on-the-wire format. Fields have different meaning so care needs to be taken when reading DNS RFCs.


1] Historically there were two versions of DNSSEC. One obsolete and one is current. Anything DNSSEC-related which comes from RFC < 4033 or predates 2005 is obsolete and should be ignored as it was never deployed.


2] Basic assumption about DNSSEC from stub's point of view is defined here:
https://tools.ietf.org/html/rfc4033#section-7

7.  Stub Resolver Considerations

   Although not strictly required to do so by the protocol, most DNS
   queries originate from stub resolvers.  Stub resolvers, by
   definition, are minimal DNS resolvers that use recursive query mode
   to offload most of the work of DNS resolution to a recursive name
   server.  Given the widespread use of stub resolvers, the DNSSEC
   architecture has to take stub resolvers into account, but the
   security features needed in a stub resolver differ in some respects
   from those needed in a security-aware iterative resolver.

   Even a security-oblivious stub resolver may benefit from DNSSEC if
   the recursive name servers it uses are security-aware, but for the
   stub resolver to place any real reliance on DNSSEC services, the stub
   resolver must trust both the recursive name servers in question and
   the communication channels between itself and those name servers.
   The first of these issues is a local policy issue: in essence, a
   security-oblivious stub resolver has no choice but to place itself at
   the mercy of the recursive name servers that it uses, as it does not
   perform DNSSEC validity checks on its own.  The second issue requires
   some kind of channel security mechanism; proper use of DNS
   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
   Particular implementations may have other choices available, such as
   operating system specific interprocess communication mechanisms.
   Confidentiality is not needed for this channel, but data integrity
   and message authentication are.

   A security-aware stub resolver that does trust both its recursive
   name servers and its communication channel to them may choose to
   examine the setting of the Authenticated Data (AD) bit in the message
   header of the response messages it receives.  The stub resolver can
   use this flag bit as a hint to find out whether the recursive name
   server was able to validate signatures for all of the data in the
   Answer and Authority sections of the response.

   There is one more step that a security-aware stub resolver can take
   if, for whatever reason, it is not able to establish a useful trust
   relationship with the recursive name servers that it uses: it can
   perform its own signature validation by setting the Checking Disabled
   (CD) bit in its query messages.  A validating stub resolver is thus
   able to treat the DNSSEC signatures as trust relationships between
   the zone administrators and the stub resolver itself.

In short the stub resolver either:
a) implements DNSSEC validation, or
b) trusts configured recursive resolver and path to it and looks at AD bit.


3] Definition of AD bit:
https://tools.ietf.org/html/rfc4035#section-3.2.3:

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic. ...

It was later clarified (but not changed since 2005) in https://tools.ietf.org/html/rfc6840#section-5.8 but that does not change its meaning on receiving side.

In short AD=1 means that the resolver did DNSSEC validation and it the result is SECURE as defined in:

https://tools.ietf.org/html/rfc4033#section-5
   A validating resolver can determine the following 4 states:

   Secure: The validating resolver has a trust anchor, has a chain of
      trust, and is able to verify all the signatures in the response.


4] When can stub trust AD bit?
https://tools.ietf.org/html/rfc4035#section-4.9.3

4.9.3.  Handling of the AD Bit

   A non-validating security-aware stub resolver MAY chose to examine
   the setting of the AD bit in response messages that it receives in
   order to determine whether the security-aware recursive name server
   that sent the response claims to have cryptographically verified the
   data in the Answer and Authority sections of the response message.
   Note, however, that the responses received by a security-aware stub
   resolver are heavily dependent on the local policy of the
   security-aware recursive name server.  Therefore, there may be little
   practical value in checking the status of the AD bit, except perhaps
   as a debugging aid.  In any case, a security-aware stub resolver MUST
   NOT place any reliance on signature validation allegedly performed on
   its behalf, except when the security-aware stub resolver obtained the
   data in question from a trusted security-aware recursive name server
   via a secure channel.

   A validating security-aware stub resolver SHOULD NOT examine the
   setting of the AD bit in response messages, as, by definition, the
   stub resolver performs its own signature validation regardless of the
   setting of the AD bit.

In short this restates the same as https://tools.ietf.org/html/rfc4033#section-7 but in reverse order + explicitly mentions that stub resolver should ignore AD bit if either recursive resolver or path to it is not trusted. The stub resolver can either:
a) trusts configured recursive resolver and path to it and looks at AD bit, or
b) implements DNSSEC validation in stub,
c) ignore AD bit if none of options above applies.


Is this tour de RFCs sufficient?

I'm happy to answer questions.

-- 
Petr Špaček  @  CZ.NIC