querying SPF record - Githubissues

skarnet / s6-dns

A complete DNS client library (synchronous and asynchronous) with related command-line tools

https://skarnet.org/software/s6-dns/

ISC License

46 stars 8 forks source link

querying SPF record #2

Closed grobian closed 2 years ago

grobian commented 2 years ago

I'm wondering if you would be open to adding support to query the SPF record (next to TXT).

Background, libspf2 currently uses res_query from libc to do resolving. When using musl libc, this means resolutions are restricted to the first 512 bytes of DNS response. With SPF being in TXT records, nowadays a lot of extra info gets in there, easily exceeding this limit. (As a result spf validation fails.) s6-dns appears to be able to handle this scenario just fine, but it cannot do the SPF queries that it would do (at least I cannot find any notion of them in the s6-dns code).

I have no idea if it really is going to be feasible to plug s6-dns into libspf2, but I'm looking for possible options here to make spf validation work on musl systems.

skarnet commented 2 years ago

As I understand it, the POSIX API only mandates A, AAAA and PTR query support, so that's what musl does. It does not provide a full resolver for any qtype; this is why libspf2 fails. If libspf2 wants to use res_query to query TXT records, it should explicitly link against a libresolv implementation that is guaranteed to work with any qtype.
SPF queries are just TXT queries, so s6-dns can perform them just fine. The s6-dnstxt command will list all the TXT records of a domain; the related primitive is s6dns_resolve_txt(). It's up to the application to parse the list of TXT records for one containing valid SPF syntax.

grobian commented 2 years ago

Whatever musl does is fine for txt queries, in fact libspf2 can do spf queries as well. musl is just limited to the first 512 bytes, which is not enough for domains like unilever.com, oracle.com, etc. (Try a TXT resolve on that.)

SPF records are not the same as TXT records. ns_t_spf appears to be 99, not 16.

skarnet commented 2 years ago

What I mean is that musl currently only supports UDP queries because 512 bytes are enough for A, AAAA and PTR queries, so UDP support is enough to implement POSIX. But Rich is aware that TCP support is wanted by a lot of users, and is currently working on it, so longer records will be supported in the next version of musl. Could still be a few months away though.

Section 3.1 of RFC 7208 says: "SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) only.", and goes on to say that support for the SPF RR should be dropped from SPF version 1. I'm not aware of a version 2 of SPF that would make new use of the SPF RR.

grobian commented 2 years ago

Agreed that SPF record should be old/cruft.

If musl really will grow support for retrieving larger responses (e.g. fall back to TCP) then there's indeed nothing to do here. This is "broken" for a long while, so just some longer is not going to make a difference here.

That said, I think closing this issue is the correct action here, SPF record is legacy, and the whole musl argument is/was just background that seems to get resolved in the future.

Thanks!