cid.contact is not accesible for IPv6 only machines

[Jorropo]

I do not find an AAAA record which makes cid.contact unusable from my IPv6 only cluster:

> dig AAAA cid.contact

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> AAAA cid.contact
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13518
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;cid.contact.			IN	AAAA

;; AUTHORITY SECTION:
cid.contact.		489	IN	SOA	amit.ns.cloudflare.com. dns.cloudflare.com. 2314816412 10000 2400 604800 1800

;; Query time: 8 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Jul 19 14:33:48 CEST 2023
;; MSG SIZE  rcvd: 102

It's lacking an AAAA record.
AFAIT the terminator is cloudfront so enabling IPv6 should be as easy as hitting a checkmark and adding an AAAA (or ALIAS). 🙂

[masih]

For reference this requires changes in the VPC set up, e.g. https://github.com/ipni/storetheindex/blob/main/deploy/infrastructure/prod/us-east-2/vpc.tf
Cc @gammazero

[Jorropo]

I don't know your architecture but that is surprising to me, you do not need to use IPv6 internally, cloudfront can terminates an HTTP request over IPv6 and reverse proxy it to IPv4.
What you say would make sense if the public side of your LB goes through inside your VPC but I would find that surprising, I don't do cloud based stuff on the regular.

[masih]

Not all endpoints are cached by cloudfront nor go through cloudfront. This leaves me to believe that we would need changes deeper in the stack at VPC level. If IPv6 resolution is needed exclusively for content seveved by cloudfront then that's a different story. @Jorropo this came up in the IPNI colo today hence the posts. Please let us know if this strill remains low priority 👍

[Jorropo]

Still low priority.