IPv6 addresses fail DCV validation - bracketed addresses rejected, unbracketed addresses malform URLs

[msuliq]

Description

IPv6 address targets fail DCV validation in two different ways depending on the format provided:

Bracketed IPv6 addresses (e.g., [2606:4700:4700::1111]) are rejected by DomainEncoder.prepare_target_for_lookup() because the IDNA encoder doesn't recognize the [ character. Unbracketed IPv6 addresses (e.g., 2606:4700:4700::1111) pass the domain encoder but produce malformed URLs for HTTP-based validation (the port gets appended incorrectly).

Steps to Reproduce

Case 1: Bracketed IPv6

from open_mpic_core import DomainEncoder

DomainEncoder.prepare_target_for_lookup("[2606:4700:4700::1111]")

Raises: ValueError: Invalid domain name: Codepoint U+005B at position 1 of '[2606:4700:4700::1111]' not allowed

Case 2: Unbracketed IPv6

When performing HTTP-based DCV validation with domain_or_ip_target = "2606:4700:4700::1111" the URL is constructed as: http://2606:4700:4700::1111/.well-known/... this is interpreted as host "2606:4700:4700" with port "1111"

Error Messages

Bracketed IPv6:

Lambda execution error: {"errorMessage": "Invalid domain name: Codepoint U+005B at position 1 of '[2606:4700:4700::1111]' not allowed", "errorType": "ValueError", ...}

Unbracketed IPv6:

error_type: mpic_error:dcv_checker:lookup
error_message: There was an error looking up the DCV record. Error type: ClientConnectorError, Error message: Cannot connect to host 2606:4700:4700::1111:80 ssl:default [Cannot assign requested address]

Note the malformed host 2606:4700:4700::1111:80 - the :80 port is being appended to the IPv6 address without proper bracket notation, resulting in an invalid address.

Suspected Cause

In domain_encoder.py, the prepare_target_for_lookup() method attempts to parse the input as an IP address using ipaddress.ip_address()
If that fails (which it does for bracketed IPv6 like [::1]), it falls through to IDNA encoding and the IDNA encoder rejects the [ character as invalid. The method doesn't account for the URL-standard bracket notation used to delimit IPv6 addresses in URIs (RFC 3986).

Expected Behavior

Bracketed IPv6 addresses like [2606:4700:4700::1111] should be recognized and the brackets stripped for internal processing the format_host_for_url() method should then re-add brackets when constructing URLs, HTTP connections to IPv6 addresses should use properly formatted URLs like http://[2606:4700:4700::1111]/.well-known/...

[birgelee]

Thanks for bringing this to our attention. We will look into it.

@msuliq can you clarify what deployment infrastructure you are using? The AWS Lambda deployment does not support IPv6 routing by default (this is an AWS problem, the low-cost lambda offering is IPv4 only, you need a VPC for IPv6).

I was also confused by your wording:
"When performing HTTP-based DCV validation with domain_or_ip_target = "2606:4700:4700::1111" the URL is constructed as: http://2606:4700:4700::1111/.well-known/... this is interpreted as host "2606:4700:4700" with port "1111""

The IPv6 address 2606:4700:4700::1111 is the prefix 2606:4700:4700 followed by a zero block followed by a host address of 1111. There is no port specified in this address.

[msuliq]

@birgelee thank you for quick response.

I am running open-mpic-core-python library on localhost with the simplest FastAPI wrapper, python 3.12.
You are right about the check_type: "dcv", it's a remnant from my earlier tests, I did re-test with check_type: "caa".

IPv6 address formatted without square brackets

MPIC response meets expected behavior

{"check_type"=>"caa",
 "domain_or_ip_target"=>"2606:4700:4700::1111",
 "is_valid"=>true,
 "trace_identifier"=>nil,
 "perspectives"=>
  [{"perspective_code"=>"us-east-1",
    "check_response"=>
     {"check_completed"=>true, "check_passed"=>true, "errors"=>nil, "timestamp_ns"=>1765485989040460000, "check_type"=>"caa", "details"=>{"caa_record_present"=>false, "found_at"=>nil, "records_seen"=>nil}}},
   {"perspective_code"=>"ap-northeast-1",
    "check_response"=>
     {"check_completed"=>true, "check_passed"=>true, "errors"=>nil, "timestamp_ns"=>1765485989069632000, "check_type"=>"caa", "details"=>{"caa_record_present"=>false, "found_at"=>nil, "records_seen"=>nil}}}],
 "caa_check_parameters"=>nil,
 "previous_attempt_results"=>nil}

IPv6 address formatted WITH square brackets

MPIC response has an error related to IDNA encoding failure.

{"check_type"=>"caa",
 "domain_or_ip_target"=>"[2606:4700:4700::1111]",
 "is_valid"=>false,
 "trace_identifier"=>nil,
 "perspectives"=>
  [{"perspective_code"=>"us-east-1",
    "check_response"=>
     {"check_completed"=>false,
      "check_passed"=>false,
      "errors"=>
       [{"error_type"=>"mpic_error:caa_checker:lookup",
         "error_message"=>
          "There was an error looking up the CAA record: Error during CAA lookup for [2606:4700:4700::1111]: Invalid domain name: Codepoint U+005B at position 1 of '[2606:4700:4700::1111]' not allowed. Trace ID: None"}],
      "timestamp_ns"=>1765485918874339000,
      "check_type"=>"caa",
      "details"=>{"caa_record_present"=>nil, "found_at"=>nil, "records_seen"=>nil}}},
   {"perspective_code"=>"af-south-1",
    "check_response"=>
     {"check_completed"=>false,
      "check_passed"=>false,
      "errors"=>
       [{"error_type"=>"mpic_error:caa_checker:lookup",
         "error_message"=>
          "There was an error looking up the CAA record: Error during CAA lookup for [2606:4700:4700::1111]: Invalid domain name: Codepoint U+005B at position 1 of '[2606:4700:4700::1111]' not allowed. Trace ID: None"}],
      "timestamp_ns"=>1765485918874657000,
      "check_type"=>"caa",
      "details"=>{"caa_record_present"=>nil, "found_at"=>nil, "records_seen"=>nil}}}],
 "caa_check_parameters"=>nil,
 "previous_attempt_results"=>nil}

Proposal

While this is not a bug, would it be possible to improve decoder to support IPv6 address with square brackets as well?
I opened a pull request based on my local tests and changes, it produces same result regardless of square brackets around IPv6 target

{"check_type"=>"caa",
 "domain_or_ip_target"=>"2606:4700:4700::1111",
 "is_valid"=>true,
 "trace_identifier"=>nil,
 "perspectives"=>
  [{"perspective_code"=>"us-east-1",
    "check_response"=>
     {"check_completed"=>true, "check_passed"=>true, "errors"=>nil, "timestamp_ns"=>1765486308481363000, "check_type"=>"caa", "details"=>{"caa_record_present"=>false, "found_at"=>nil, "records_seen"=>nil}}},
   {"perspective_code"=>"ap-northeast-1",
    "check_response"=>
     {"check_completed"=>true, "check_passed"=>true, "errors"=>nil, "timestamp_ns"=>1765486308612071000, "check_type"=>"caa", "details"=>{"caa_record_present"=>false, "found_at"=>nil, "records_seen"=>nil}}}],
 "caa_check_parameters"=>nil,
 "previous_attempt_results"=>nil}

{"check_type"=>"caa",
 "domain_or_ip_target"=>"[2606:4700:4700::1111]",
 "is_valid"=>true,
 "trace_identifier"=>nil,
 "perspectives"=>
  [{"perspective_code"=>"us-east-1",
    "check_response"=>
     {"check_completed"=>true, "check_passed"=>true, "errors"=>nil, "timestamp_ns"=>1765486367936439000, "check_type"=>"caa", "details"=>{"caa_record_present"=>false, "found_at"=>nil, "records_seen"=>nil}}},
   {"perspective_code"=>"af-south-1",
    "check_response"=>
     {"check_completed"=>true, "check_passed"=>true, "errors"=>nil, "timestamp_ns"=>1765486368065970000, "check_type"=>"caa", "details"=>{"caa_record_present"=>false, "found_at"=>nil, "records_seen"=>nil}}}],
 "caa_check_parameters"=>nil,
 "previous_attempt_results"=>nil}

[msuliq]

@birgelee reason for patching core library was the fact that url was being malformed during HTTP challenge for IPv6 addresses, the lookup address http://[2606:4700:4700::1111]/.well-known/... was not built correctly and the check failed.
I tried to test changes by running core library with the simplest FastAPI wrapper locally but my network failed to resolve IPv6 routes, I tried several providers to no avail.
Yesterday I was able to test these changes on a AWS Lambda that has proper configurations and I can confirm that both dcv and caa checks were working.

[birgelee]

@msuliq thanks for working on this. So you were able to test in AWS Lambda with IPv6 networking and it properly contacted an external IPv6 address for validation?

For the CAA check are you referring to a CAA record placed at an IPv6 only nameserver?

I did look over the PR. I thought it looked good. I was hoping to put an IPv6 test into the official integration suite but I didn't get to it. My main concern is just ensuring the IPv6 functionality works and is well maintained.

[msuliq]

@birgelee
Yes, I was able to test in AWS Lambda with IPv6 networking properly configured and I was able to pass MPIC check, Lambda properly contacted an external IPv6 address for dcv validation.

For the CAA check yes I am referring to the CAA record placed at an IPv6 only nameserver. This is not the main concern for this PR, I just wanted to make sure that CAA check did not get broken.