TR not considering ECS (EDNS0 client subnet) IP for geo-lookup when the queried fqdn has case randomized

[amarbs]

This Bug Report affects these Traffic Control components:

• Traffic Router

Current behavior:

traffic-router doesn’t seem to be considering ECS (EDNS0 client subnet) when the domain name has randomized case.
Below is the TR access log for a ECS query for cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us.
time=1683701671.265 qtype=DNS chi=180.151.43.134 rhi=127.0.0.1 ttms=1.073 xn=45923 fqdn=cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us. type=A class=IN rcode=NOERROR rtype=GEO rloc="48.9,2.42" rdtl=- rerr="-" ttl="10 10 10" ans="159.60.139.64 159.60.139.63 159.60.139.65" svc="73dd3914-76fb-486a-987e-8338fb51870e" podName=traffic-router-756cc7df59-cgrvz
Note that the chi correctly has the ECS IP from the query, which is 180.151… and rhi correctly has TCP/UDP client IP 127.0.0.1. The response also is as per the chi.
Query used for above:
dig @localhost cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us. +subnet=180.151.43.134/32

Below is the same query with randomized case in same domain name cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us. Note cDn and sTaging. Access log:
time=1683701746.164 qtype=DNS chi=127.0.0.1 rhi=- ttms=0.857 xn=27831 fqdn=cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us. type=A class=IN rcode=NOERROR rtype=GEO rloc="37.24,-121.78" rdtl=- rerr="-" ttl="10 10 10" ans="159.60.139.67 159.60.139.66 159.60.139.68" svc="73dd3914-76fb-486a-987e-8338fb51870e" podName=traffic-router-756cc7df59-cgrvz
Note that rhi is empty. And, chi is now the TCP/UDP client IP. It appears that TR is ignoring ECS IP now.
Query used for above:
dig @localhost cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us. +subnet=180.151.43.134/32

Expected behavior:

With case randomized domain also, TR should consider ECS IP for geo-lookup. This should reflect with correct values of chi and rhi populated in access-log.
Now that google DNS has deployed case randomization defence across its sites (news link), this bug become quite evident.

Steps to reproduce:

version - v6.1.0 (not tested yet in 7.x)

1. Make a query to TR with ECS option. Ex: dig @localhost cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us. +subnet=180.151.43.134/32.
2. Observe the access log. chi and rhi are correctly populated. Answer is as per geo-lookup of chi, that is ECS IP.
3. Make the same query as step (1) but with randomized domain name like cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us.. Ensure that the case randomization is in the domain's deliveryservice and its parent parts. Randomization of the routing key (cdn) does not reproduce the bug.
4. Observe the access log. ECS IP is missing. chi instead contains L4 client IP. Answer is as per geo-lookup of L4 client IP.