resolved: allow the full TTL to be used by OPT records
authorJames Coglan <james@neighbourhood.ie>
Fri, 28 Jun 2024 12:41:31 +0000 (13:41 +0100)
committerJames Coglan <james@neighbourhood.ie>
Fri, 28 Jun 2024 12:41:31 +0000 (13:41 +0100)
commit131787979c700becaf6ec24a810658d1313587cc
treebc8380865bc6bc9810a0bf4109ba2231e83ca5b5
parentc1451cd2a20e0ae88478e787d10ac5047a78280c
resolved: allow the full TTL to be used by OPT records

Whereas RFC 1035 says the TTL field takes the "positive values of a
signed 32 bit number", and RFC 2181 says "Implementations should treat
TTL values received with the most significant bit set as if the entire
value received was zero,", the dns_packet_read_rr() function sets
rr->ttl to zero if the MSB is set.

However, EDNS(0) as specified in RFC 6891 repurposes the TTL field's 4
octets to store other information, c.f.:

                  +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |         EXTENDED-RCODE        |            VERSION            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: | DO|                           Z                               |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

The first octet extends the usual 4-bit RCODE from the packet header by
providing an additional 8 bits of space, extending the RCODE to 12 bits.
But, our handling of the TTL field means that the high bit in the first
octet is not actually usable, since setting it will mean these 4 octets
are replaced with 0. This may have the effect of making us believe a
server does not support DNSSEC when it actually set the DO bit in its
OPT record.

Here we change things so that the TTL is only set to zero for record
types other than OPT.
src/resolve/resolved-dns-packet.c