Skip to content

Add CAA DNS Record Type Support for Custom Domain Operations#519

Merged
BinoyOza-okta merged 1 commit intomasterfrom
OKTA-1146219
Apr 7, 2026
Merged

Add CAA DNS Record Type Support for Custom Domain Operations#519
BinoyOza-okta merged 1 commit intomasterfrom
OKTA-1146219

Conversation

@BinoyOza-okta
Copy link
Copy Markdown
Contributor

Fix: Add CAA DNS Record Type Support for Custom Domain Operations

Summary

This PR fixes a critical validation error that prevented custom domain operations from working when the Okta API returned CAA (Certificate Authority Authorization) DNS records.

SDK Version: okta-sdk-python 3.3.0
Issue: OKTA-1146219

Problem

Broken Functionality

5 out of 6 custom domain API endpoints were failing with Pydantic validation errors:

Method Response Model Status
create_custom_domain DomainResponse ❌ Broken
get_custom_domain DomainResponse ❌ Broken
replace_custom_domain DomainResponse ❌ Broken
verify_custom_domain DomainResponse ❌ Broken
list_custom_domains List[DomainResponse] ❌ Broken
delete_custom_domain None (204) ✅ N/A

Root Cause

The DNSRecordTypeDomains and EmailDomainDNSRecordType enums only defined two record types:

class DNSRecordTypeDomains(str, Enum):
    CNAME = "CNAME"
    TXT = "TXT"
    # Missing: CAA and other types!

When the Okta API returned DNS records with recordType: "CAA", Pydantic validation failed:

ValidationError: Input should be 'CNAME' or 'TXT' [type=enum, input_value='CAA']

Example Failure

from okta.models.dns_record_domains import DNSRecordDomains

dns_record = DNSRecordDomains.from_dict({
    "fqdn": "example.com",
    "recordType": "CAA",  # Not in enum!
    "values": ["0 issue \"ca.example.com\""]
})
# ❌ ValidationError: Input should be 'CNAME' or 'TXT'

Solution

Added CAA record type to both DNS enum classes:

Files Changed

  1. okta/models/dns_record_type_domains.py

    class DNSRecordTypeDomains(str, Enum):
        CNAME = "CNAME"
        TXT = "TXT"
        CAA = "CAA"  # ✅ Added
  2. okta/models/email_domain_dns_record_type.py

    class EmailDomainDNSRecordType(str, Enum):
        CNAME = "CNAME"
        TXT = "TXT"
        CAA = "CAA"  # ✅ Added

Testing

Verification Performed

✅ Tested get_custom_domain() method with domain containing CAA records
✅ DNS records with CAA type now deserialize correctly
✅ No validation errors during deserialization
✅ All custom domain operations work as expected

Test Prompts Verified

  1. ✅ "Can you get details of the domain agrjamcp.sigmanetcorp.us please?"
  2. ✅ "Can you verify the custom domain agrjamcp.sigmanetcorp.us please?"
  3. ✅ "Can you update this domain? Move it to another brand to full-brand-2?"

Impact

Before

  • Custom domain operations completely broken
  • ValidationError on any domain with CAA records
  • Unable to create, read, update, or verify custom domains

After

  • ✅ All custom domain operations functional
  • ✅ CAA records properly deserialized
  • ✅ No breaking changes to existing functionality
  • ✅ Maintains backward compatibility

Breaking Changes

None - This is a pure bug fix that adds support for additional DNS record types returned by the Okta API.

Notes

  • The OpenAPI spec may need updating to include all possible DNS record types
  • Consider adding other standard DNS record types (MX, NS, SOA, etc.) in future updates
  • This fix unblocks all custom domain operations for domains using CAA records

Related Issues: OKTA-1146219
Type: Bug Fix
Priority: High (5/6 endpoints broken)

… operations

This commit resolves a critical validation error that caused 5 out of 6 custom
domain API endpoints to fail when the Okta API returned CAA (Certificate Authority
Authorization) DNS records.

Problem:
- DNSRecordTypeDomains and EmailDomainDNSRecordType enums only defined CNAME and TXT
- When API returned CAA records, Pydantic validation failed during deserialization

Solution:
Added CAA record type to both enum classes:
- okta/models/dns_record_type_domains.py
- okta/models/email_domain_dns_record_type.py

Testing:
Verified with get_custom_domain() method that CAA records now deserialize correctly without validation errors.
aniket-okta

This comment was marked as spam.

Copy link
Copy Markdown

@aniket-okta aniket-okta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Live tests passed - CAA deserialization, verify, and replace all work. Review comments below are inline on the changed lines.

Copy link
Copy Markdown

@aniket-okta aniket-okta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarifications - all core concerns addressed:

✅ CAA-only scope confirmed as a deliberate product decision (discussed with Agrja)
EmailDomainDNSRecordType + CAA confirmed as per ticket requirements
.py files confirmed as regenerated via openapi-generator-cli, not hand-edited
✅ Live tested - get_custom_domain, verify_domain, and replace_custom_domain all work correctly with CAA records on okta-mcp-server.oktapreview.com

Two non-blocking suggestions for follow-up:

  • Consider adding a unit test for the CAA deserialization repro case from the JIRA to prevent silent regressions
  • A CHANGELOG.md entry would be good given the severity (5/6 endpoints were broken)

Approving - good fix, good discussion.

@BinoyOza-okta
Copy link
Copy Markdown
Contributor Author

Sure, Aniket, the CHANGELOG.md changes will be covered in the release notes.

@BinoyOza-okta BinoyOza-okta merged commit cc03347 into master Apr 7, 2026
15 checks passed
@BinoyOza-okta BinoyOza-okta deleted the OKTA-1146219 branch April 7, 2026 06:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants