My previous change did not fix the flake, it moved it. Asserting on a
CLIENT-SUBNET option in the client's answer still depends on whether the
authority echoes ECS back, which is the same coin flip the original
`grep edns0-client-subnet` rode on. Two runs of that assertion, same
branch, minutes apart: amd64 saw `answer has edns subnet 203.0.113.0/24`
twice and passed, arm64 saw it zero times and failed.
Two mistakes. 203.0.113.0/24 is TEST-NET-3, so it is no more routable
than the RFC1918 address it replaced and authorities decline it just the
same -- the failing job still got "edns0-client-subnet was not used".
And unbound does not echo CLIENT-SUBNET to a client that sent one in
general: subnetmod.c gates that on the client having sent a /0 prefix, so
with a /24 the generate_lookup_without_subnet() fallback returns the
answer with no option at all.
There is no client-visible ECS signal that survives an authority
declining, so assert only local state: the build links subnetcache, the
mounted example config puts it in the module chain, and send-client-subnet
was parsed. The active unbound.conf sets no module-config, so
"init module 0: subnetcache" appears only when the example file loaded --
which is what this test existed to check.
Verified by matching each pattern against captured output from seven real
jobs, across four platforms and unbound 1.25.2 and 1.26.0, passing and
failing. Testing an actual round-trip would need an authoritative server
in the compose file; that is a larger change than this test has had.
Signed-off-by: Kyle Harding <kyle@balena.io>
The ECS assertion grepped for `edns0-client-subnet`, which matches the
substring inside Google's *negative* reply "edns0-client-subnet was not
used". So the test's green state was Google telling us ECS was not used,
and it never verified ECS at all.
The sut container's address is 172.18.0.2, so unbound forwards
172.18.0.0/24 upstream. Authorities won't use an RFC1918 prefix, hence
the "was not used" answer. Whether that answer reaches the client is up
to Google's anycast fleet: if the reply echoes the ECS option unbound
keeps it and the substring matches, but if the reply omits the option
unbound logs "Authority indicates no support", re-resolves without the
subnet, and returns a single TXT record with no substring to match.
Both are RFC 7871-legal, so re-running just rolled the dice again --
roughly half the Test docker jobs failed on this line, on every
platform.
Have the client supply a routable prefix via +subnet instead, and assert
that unbound echoes the option back. unbound returns a CLIENT-SUBNET
option whenever the client sent one -- with the upstream scope, or
scope 0 via cp_edns_bad_response when upstream declines -- so the
assertion no longer depends on any authority's ECS policy. It also
fails when the subnet module is absent, which the old one could not.
Signed-off-by: Kyle Harding <kyle@balena.io>
bump-unbound opens a weekly PR updating the Dockerfile version+SHA256
ARGs and regenerating the conf-example; tag-unbound tags vX.Y.Z on the
content commit when that PR merges. Mirrors the dnscrypt-proxy-docker
workflows. Documented in CONTRIBUTING.md.
Signed-off-by: Kyle Harding <kyle@balena.io>
