draft dns configuration for gateway API GEP-2627

minor tweaks

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <[email protected]>

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <[email protected]>

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <[email protected]>

geps/gep-2627/index.md

@@ -0,0 +1,50 @@
+# GEP-2627: DNS configuration within Gateway API
+
+* Issue: [#2627](https://github.com/kubernetes-sigs/gateway-api/issues/2627)
+* Status: Provisional
+
+## TLDR
+
+For gateway infrastructure to be valuable we need to be able to connect clients to these gateways. A common way to achieve this is to use domain names/hostnames and DNS. Gateways define listeners that can have assigned hostnames or wildcards.  The guidelines for DNS configuration are a critical piece of service networking, but this is currently not expressible as part of Gateway API.   Instead of leaving this as an exercise for the user to figure out, this proposal attempts to provide options to ease Gateway API operations.
+
+## Goals
+* Allow cluster operators or infrastructure providers to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener and have that DNS service interacted with via a controller to provision and configure the defined listener hostnames as DNS names and records based on the addresses assigned to the gateway instances.
+* Provide a standard CRD-based API as an alternative to the need for "loose" APIs such as annotations.   Support an easily extended, standardized, versioned, and status-reporting API. 
+* Increase portability and supportability across gateway providers and third party implementors, for this type of key configuration
+
+## Non-Goals
+
+* Cover more complex DNS routing strategies that come into play for multi-cluster topologies such as round robin, failover, health checks, weighted and geo location with this first pass. Supporting these types of use cases for distributed gateways (e.g., in different regions or multiple gateways for resilience within a region) and offering a form of global load balancing leveraging DNS is a potential future goal.
+
+## Use Cases
+
+As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used and limit which domains can be used.
+
+A a cluster administrator, I would like to have the dns names automatically populated into my specified dns zones as a set of records based on the assigned addresses of my gateways and have the status of the DNS records reported back to me, so that I do not have to undertake external automation or management of this essential task and can leverage existing kube based monitoring tools to know the status of the integration.
+
+As a cluster administrator, I would like the DNS records to be setup automatically based on the assigned gateways address and if the IP or hostname changes, I would like for the DNS to update automatically to ensure traffic continues to reach my gateway. 
+
+## API
+
+Initial draft will not offer an API yet until the use cases are agreed. Some thoughts worth thinking about: 
+- I think it is important that we try to move away from APIs based on annotations which, while convenient, are not a full API and suffer from several limitations. An example: I want to configure a listener with a domain I own that is in a different provider than the domains of the other listeners. I want to add a new option to configure a particular weighting and so on. Soon you end up with a large set of connected annotations that often grow in complexity that really should be expressed as an API.
+
+- It is also important that this API can be delegated to controllers other than the Gateway provider. This is because there are existing solutions that may want to support whatever API decided upon. It should not **have** to be a gateway provider that has to integrate with many DNS providers. 
+
+## Conformance Details
+
+(This section describes the names to be used for the feature or
+features in conformance tests and profiles.
+
+These should be `CamelCase` names that specify the feature as
+precisely as possible, and are particularly important for
+Extended features, since they may be surfaced to users.)
+
+## Alternatives
+
+it is possible to use `external-dns` to manage dns based on HTTPRoutes and Gateways https://github.com/kubernetes-sigs/external-dns/blob/7f3c10d65297ec1c4bcc8dd6f88c189b7f3e80d0/docs/tutorials/gateway-api.md. The aim of this GEP is not remove this as an option, but instead provide a common API that could then be leveraged by something like external-dns. 
+
+## References
+
+(Add any additional document links. Again, we should try to avoid
+too much content not in version control to avoid broken links)

geps/gep-2627/metadata.yaml

@@ -0,0 +1,8 @@
+apiVersion: internal.gateway.networking.k8s.io/v1alpha1
+kind: GEPDetails
+number: 2627
+name: DNS configuration for Gateway API
+status: Experimental
+authors:
+  - maleck13
+