gcp_dns_resource_record_set always updates SOA, causing 412 conflicts at scale — request toggle to skip SOA updates

SUMMARY

Add a feature flag/parameter to the google.cloud.gcp_dns_resource_record_set module to skip explicit SOA record updates. Currently, the module always deletes and re-adds the SOA (incrementing its serial) with every DNS change, even though Google Cloud DNS already manages SOA serials automatically. This behavior causes race conditions and 412 Precondition Failed errors when multiple nodes update records in parallel.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

google.cloud.gcp_dns_resource_record_set

ADDITIONAL INFORMATION

This feature would allow users to bypass unnecessary SOA updates and let Google Cloud DNS handle serial increments internally. It is especially critical in high-scale environments (e.g., 100s of nodes provisioning simultaneously), where forced SOA updates result in frequent conflicts and failed record creations.

We propose a new parameter:

- name: Create A record without SOA update
  google.cloud.gcp_dns_resource_record_set:
    name: "{{ inventory_hostname }}.int.example.com."
    type: A
    ttl: 60
    target:
      - "{{ ansible_default_ipv4.address }}"
    managed_zone:
      name: abcd
      dnsName: int.example.com.
    project: gcp-abcd
    auth_kind: serviceaccount
    service_account_file: /path/key.json
    state: present
    skip_soa_update: true   # <--- new parameter

Why it’s needed:

Removes contention on SOA serial numbers during parallel updates.

Prevents 412 errors, improving reliability of large-scale automated deployments.

Maintains backward compatibility (default behavior still updates SOA).

What it would solve:

Eliminates DNS update failures in parallel provisioning scenarios.

Allows teams to rely on native Cloud DNS behavior rather than redundant SOA handling in the module.

Start with the google.cloud.gcp_dns_resource_record_set module and trace where SOA records are deleted and re-added during record changes. Add the optional skip_soa_update behavior while preserving the current default, then verify that parallel record creation can avoid explicit SOA updates and that existing behavior remains unchanged.