Fixes TXT query results

[tweltz]

We recently started using Rancher as a replacement to Docker Desktop and I noticed some issues with strange results in some DNS queries in my development environment. When I investigated why Rancher was returning these unexpected results, I identified that the issue was in fact caused by Lima.

There were two specific issues where TXT records are not handled correctly.

Issue 1: Hostname has multiple TXT Records

• Expected Result: There should be a response with multiple TXT Answers returned, the same as any other record type with multiple records.

;; ANSWER SECTION:
multirecord.weltzgrove.com. 5	IN	TXT	"record1"
multirecord.weltzgrove.com. 5	IN	TXT	"record2"

• Actual Result:

;; ANSWER SECTION:
multirecord.weltzgrove.com. 5	IN	TXT	"record1" "record2"

This is happening because the TXT records are not being looped over like the other Record types.

Issue 2: Hostname has a multi-string TXT Record

While there is a 255 byte limitation to string sizes of TXT Records, a single record can be made up of multiple strings. This is necessary to accommodate DKIM Records with 2048 (or larger) keys, and is also common in SPF Records with a lot of entries. This is an example of such a record in a bind dns file format:

selector._domainkey    14400   IN      TXT     ( "123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345"
"678901234567890" )

When the result gets back to the original query client, they are obligated to concatenate the strings and treat that as the actual query result.

• Expected Result: There should be a response with a multiple string TXT Answer returned.

;; ANSWER SECTION:
longrecord.weltzgrove.com. 5	IN	TXT	"123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345" "678901234567890"

• Actual Result:

;; connection timed out; no servers could be reached

The reason this is happening in the lima dns currently, is that it uses the net module to lookup the result to return and the net.LookupTXT function is returning the 'final' concatenated result. As a result, the lima dns resolver is trying to return an oversized and invalid result to the client.

[jandubois]

Thank you for tracking this down. Haven't done a full review yet, but attaching some stylistics suggestions for now.

Please also squash commits together when they are just iterating on the same change.

[jandubois]

Thanks! LGTM

Any reason this is still a draft? Sorry, didn't notice it has changed status.

[jandubois]

@tweltz I would prefer to get the typo corrected. If you do that, please update the regex too.

diff --git pkg/hostagent/dns/dns.go pkg/hostagent/dns/dns.go
index caedb4a..a0dd67c 100644
--- pkg/hostagent/dns/dns.go
+++ pkg/hostagent/dns/dns.go
@@ -179,7 +179,7 @@ func (h *Handler) handleQuery(w dns.ResponseWriter, req *dns.Msg) {
                                                Hdr: hdr,
                                        }
                                        // Per RFC7208 3.3, when a TXT answer has multiple strings, the answer must be treated as
-                                       // a single concatenated string. net.LookupTXT is pre-concatenting such answers, which
+                                       // a single concatenated string. net.LookupTXT is pre-concatenating such answers, which
                                        // means we need to break it back up for this resolver to return a valid response.
                                        a.Txt = chunkify(s, 255)
                                        reply.Answer = append(reply.Answer, a)
diff --git pkg/hostagent/dns/dns_test.go pkg/hostagent/dns/dns_test.go
index 1a5b9b2..28bd563 100644
--- pkg/hostagent/dns/dns_test.go
+++ pkg/hostagent/dns/dns_test.go
@@ -23,9 +23,9 @@ func TestTXTRecords(t *testing.T) {
        testDomains[2] = "multiplerecords.com"

        expectedResults := make([]string, 3)
-       expectedResults[0] = `onerecord.com.\s*5\s*IN\s*TXT\s*"My txt record"`
-       expectedResults[1] = `multistringrecord.com.\s*5\s*IN\s*TXT\s*"1234567890123456789012345678901234567890123456789012345678901234567890123456789012345
-       expectedResults[2] = `multiplerecords.com.\s*5\s*IN\s*TXT\s*"record 1"\nmultiplerecords.com.\s*5\s*IN\s*TXT\s*"record 2"`
+       expectedResults[0] = `onerecord.com.\s+5\s+IN\s+TXT\s+"My txt record"`
+       expectedResults[1] = `multistringrecord.com.\s+5\s+IN\s+TXT\s+"1234567890123456789012345678901234567890123456789012345678901234567890123456789012345
+       expectedResults[2] = `multiplerecords.com.\s+5\s+IN\s+TXT\s+"record 1"\nmultiplerecords.com.\s+5\s+IN\s+TXT\s+"record 2"`

        srv, _ := mockdns.NewServerWithLogger(map[string]mockdns.Zone{
                "onerecord.com.": {

[tweltz]

Thanks @jandubois, regex and typo corrected.

[jandubois]

Can you please resolve the merge conflict by rebasing the PR on latest master?

#774 updated miekg/dns from 1.47 to 1.48, creating a conflict in go.sum.

[jandubois]

Thank you, looks all good now!