rfc2136 provider make use of SOA records to determine `Server` property

[olzemal]

rfc2136 defines:

[4](https://datatracker.ietf.org/doc/html/rfc2136#section-4) - Requestor Behaviour

  4.1. From a requestor's point of view, any authoritative server for
  the zone can appear to be able to process update requests, even
  though only the primary master server is actually able to modify the
  zone's master file.  Requestors are expected to know the name of the
  zone they intend to update and to know or be able to determine the
  name servers for that zone.

emphasis on or be able to determine the name servers for that zone. This can be done by requesting the SOA as defined earlier in the rfc:

 Primary Master  master server at the root of the AXFR/IXFR
                 dependency graph.  The primary master is named in
                 the zone's SOA MNAME field and optionally by an NS
                 RR.  There is by definition only one primary master
                 server per zone.

however external-dns-management requires the property Server to be set in the secret.

• external-dns-management/pkg/controller/provider/rfc2136/handler.go

  Line 53 in 1e3c28c

  server, err := c.GetRequiredProperty("Server")

• external-dns-management/examples/20-secret-rfc2136-credentials.yaml

  Line 9 in 1e3c28c

  Server: ... # "<host>[:<port>]" of the authorive DNS server, default port is 53

It would be great if this property was optional. If no value is given external-dns-management should lookup the server via a SOA request for the Zone.

This way in case the primary master IP switches (fail-over / multi master scenario) there would be no configuration change needed.

Optionally store the returned value in the field for the purpose of caching and minimizing request counts.
In case the cached IP is not reachable anymore the cache should be dropped.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale

[MartinWeindel]

/remove-lifecycle stale

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale