dns stub resolver: increase buffer size to handle chained CNAMEs
authorRich Felker <dalias@aerifal.cx>
Wed, 5 Jul 2023 03:11:17 +0000 (23:11 -0400)
committerRich Felker <dalias@aerifal.cx>
Wed, 5 Jul 2023 03:36:05 +0000 (23:36 -0400)
in the event of chained CNAMEs, the answer to a query will contain the
entire CNAME chain, not just one CNAME record. previously, the answer
buffer size had been chosen to admit a maximal-length CNAME, but only
one. a moderate-length chain could fill the available 768 bytes
leaving no room for an actual address answering the query.

while the DNS RFCs do not specify any limit on the length of a CNAME
chain, or any reasonable behavior is the chain exceeds the entire 64k
possible message size, actual recursive servers have to impose a
limit, and a such, for all practical purposes, chains longer than this
limit are not usable. it turns out BIND has a hard-coded limit of 16,
and Unbound has a default limit of 11.

assuming the recursive server makes use of "compression" (pointers),
each maximal-length CNAME record takes at most 268 bytes, and thus any
chain up to length 16 fits in at most 4288 bytes.

this patch increases the answer buffer size to preserve the original
intent of having 512 bytes available for address answers, plus space
needed for a maximal CNAME chain, for a total of 4800 bytes. the
resulting size of 9600 bytes for two queries (A+AAAA) is still well
within what is reasonable to place in automatic storage.

src/network/lookup_name.c

index 4281482..3521818 100644 (file)
@@ -109,7 +109,7 @@ struct dpc_ctx {
 #define RR_CNAME 5
 #define RR_AAAA 28
 
-#define ABUF_SIZE 768
+#define ABUF_SIZE 4800
 
 static int dns_parse_callback(void *c, int rr, const void *data, int len, const void *packet, int plen)
 {