0

When trying to construct a long SPF record in the form:

example.com.               86400  IN  TXT  "v=spf1 ip4:1.2.3.0/24 include:example.net include:_my_whitelist.example.com -all"
_my_whitelist.example.com. 86400  IN  TXT  "v=spf1 ip4:... " " ip4:..."

... such that the whitelist record is longer than 255 bytes. I understand that this is a valid way to construct longer DNS responses (http://www.openspf.org/RFC_4408#multiple-strings says they should be concatenated together and treated as one) and some resolvers are happy with this. Some, however, fail to resolve - for instance Ubuntu 18.04's resolver which claims there's no TXT record present.

This exibits when using the host command as:

$ host -t txt _my_whitelist.example.com
_my_whitelist.example.com has no TXT record
  1. Is this a bug in Ubuntu/systemd?
  2. Is there a better way to construct a long TXT/SPF record?
Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
foo
  • 66
  • 5
  • Can you provide an example of the behavior in Ubuntu 18.04? It appears to be a 2018 release, and it would be very strange indeed were that to be the case. – Andrew B Jun 04 '18 at 22:36
  • Added example using host. Suspect issue is compatibility of "host" command run against systemd resolver requesting long DNS response. dig command seems to work fine. – foo Jun 05 '18 at 10:58
  • 3
    Give the true name if you relevant troubleshooting help. Did you try with `dig`? – Patrick Mevzek Jun 05 '18 at 13:37
  • @PatrickMevzek yes, further testing shows that dig seems to work. I think we've identified two possible issues which I'm going to write up as an "answer" – foo Jun 07 '18 at 07:34
  • 2
    My guess is that this results in the DNS response being too large for simple UDP. The resolver should then switch to TCP. Or the resolver could use EDNS0 to signal acceptance of larger packets. See also [Why DNS through UDP has a 512 bytes limit?](https://serverfault.com/questions/587625/why-dns-through-udp-has-a-512-bytes-limit). – Steffen Ullrich Jun 07 '18 at 08:03

1 Answers1

0

Two possible issues seem to have come to light:

  1. Slightly broken DNS record (too long?)
  2. Ubuntu's systemd DNS resolver not being very nice

The DNS records we'd created were split on the 255 byte boundary. Dropping this to 248 bytes seems to have fixed the issues.

The Ubuntu resolver has expected behaviour where it doesn't offer a local TCP resolution service by default so host falling back to TCP to do the lookup was failing -- I think! https://github.com/systemd/systemd/issues/6520

foo
  • 66
  • 5