DNS Resolver - Zephyr handling non-zero ‘Z’ bits in response header

[Gatchers]

Hi!

Mid-term user, new poster, sorry!

Zephyr faults DNS responses with a non-zero ‘Z’ field. Servers such as the Dual DNS/DHCP server currently serve undefined bits in this field, but I guess one day these bits may be defined and used?

I guess I’m wondering what the strategy is here. At the moment, this explains why Zephyr clients can (not always as the bits are undefined!) fail here.

Thanks,

Gareth

[GeorgeCGV]

Maybe Zephyr implementation strictly follows RFC1035:

Z               Reserved for future use.  Must be zero in all queries
                and responses.

that clearly states the requirement of bits to be 0.

Later on RFC2535 uses RFC1035 Z field for security purposes (splits it into AD, CD, and Z bits).

It doesn't look like the implementation considers AD/CD bits described in RFC2535 :

zephyr/subsys/net/lib/dns/dns_pack.h

Lines 234 to 237 in c8942af

	static inline int dns_header_z(uint8_t *header)
	{
	return ((*(header + 3)) & 0x70) >> 4;
	}

The dns_unpack_response_header will result in -EINVAL if Z bits aren't 0:

zephyr/subsys/net/lib/dns/dns_pack.c

Lines 204 to 206 in ac73006

	if (dns_header_z(dns_header) != 0) {
	return -EINVAL;
	}

That leads to DNS_EAI_FAIL within dns_validate_msg:

zephyr/subsys/net/lib/dns/resolve.c

Lines 512 to 516 in c8942af

	ret = dns_unpack_response_header(dns_msg, *dns_id);
	if (ret < 0) {
	ret = DNS_EAI_FAIL;
	goto quit;
	}

[Gatchers]

Thank you - yes, this corresponds with what I found via debugging. I am interested in what the plan is here.

[Gatchers]

Also well done! You traced back exactly what I had to find via debug, thank you!

[GeorgeCGV]

I am not sure if there is a plan beyond RFC1035 support.
Contributions are always welcomed and appreciated.