feat: add support for resolving records for resources with wildcard hostnames

[solidDoWant]

Some resources, such as HTTPRoutes, can specify wildcard hostnames. Currently, these values are loaded exactly as-is into the indexer for DNS resolution. As a result, lookups for subdomains matching these wildcard values always fail. This PR allows for resolving these queries, if a more specific record is not specified on another resource.

In short, given these resources:

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: s3-gateway
spec:
  hostnames:
    - "*.s3.my.domain.name"
    - s3.my.domain.name
  parentRefs:
    # IP address 1.2.3.4
    - name: my-gateway
      namespace: networking
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: s3-gateway-other
spec:
  hostnames:
    - bucket-3.s3.my.domain.name
  parentRefs:
    # IP address 5.6.7.8
    - name: my-other-gateway
      namespace: networking

The following queries can now be resolved:

• s3.my.domain.name: 1.2.3.4 (only this one can be resolved currently)
• bucket-1.s3.my.domain.name: 1.2.3.4
• bucket-2.s3.my.domain.name: 1.2.3.4
• bucket-3.s3.my.domain.name: 5.6.7.8

[larivierec]

Thanks for the PR.
Will review later.

[larivierec]

I was actually contemplating if we should accept a PR for this, but all other tests seem to still pass.

I'm wondering though, would Ingress, Service behave the same or is this GW Api specific?

[solidDoWant]

This should affect any resource that is used by the plugin. Any resource that returns a '*.some.domain.name' style record can have subdomains resolve to it.

Note that this prioritizes more specific records, so if there is one resource that provides '*.some.domain.name', and another that provides 'more-specific.some.domain.name', the later will always be chosen when the plugin is queried for the later.

[larivierec]

Yeah, so this doesn't really apply to ingress. It's actually invalid in the schema

[samip5]

Can you actually use this with an Ingress tho?

[larivierec]

Ignore my comment. Yes, it is valid

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

From the ingress it accepts.

ChatGPT, mentioned it had to be RFC1123 compliant, that would make a * in a host invalid.

TL;dr all good from my end

[Copilot]

Pull Request Overview

This PR adds support for resolving wildcard hostnames for resources (e.g., HTTPRoutes) by enhancing the DNS index lookup logic.

• Refactors the index key generation in ServeDNS by replacing the old indexKeys logic with getQueryIndexKeySets and getMatchingAddresses.
• Introduces a toWildcardQName helper to compute wildcard query names and adds additional test cases to ensure correct wildcard resolution.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
gateway_test.go	Added new test cases for wildcard hostname queries (Tests 18 & 19).
gateway.go	Refactored query key generation and address matching to support wildcard lookups.