API does not accept punycode domains

[jacklul]

Versions

Core version is v6.4.1 (Latest: v6.4.1)
Web version is v6.5 (Latest: v6.5)
FTL version is v6.6 (Latest: v6.6)

Platform

Discovered on my instance but verified that it also happens in latest Docker release.
VM: Linux alpine 6.12.16-0-virt #1-Alpine SMP PREEMPT_DYNAMIC 2025-02-21 15:23:09 x86_64 Linux

Expected behavior

To be able to add domains like xn--gi8h42h.ws (🍆🥵.ws meme domain) to blocked/allowed.

Actual behavior / bug

You cannot do that currently, API responds that the domain is invalid.

Payload: {"domain":"xn--gi8h42h.ws","comment":"Added from Query Log","type":"deny","kind":"exact"}
Response: {"error":{"key":"bad_request","message":"Invalid request: Invalid domain name","hint":"string contains a disallowed character"},"took":0.00011467933654785156}

Steps to reproduce

Attempt to add any such domain (I've checked few from this wikipedia article) to allowed/blocked and see the result.

Debug Token

I don't think is relevant here but: https://tricorder.pi-hole.net/bATrGjCV/

Additional context

Discovered by accident - I have a regex rule (^|\.)xn--.*$ to block all domains like this - wanted to whitelist that meme site temporarily and encountered this.

[rdwebdesign]

Thanks for reporting.

As an alternative, you can use a regex to whitelist the domain.
Use:

^xn--gi8h42h\.ws$

[jacklul]

Thanks for reporting.

As an alternative, you can use a regex to whitelist the domain. Use:

^xn--gi8h42h\.ws$

Yes, regex works

[DL6ER]

The root cause is that idn2_to_ascii_lz() round-trips punycode domains through IDNA2008 validation — it decodes the xn-- label back to Unicode, checks the characters against IDNA2008 (RFC 5892), and re-encodes. Emoji and various other Unicode characters are classified as DISALLOWED in IDNA2008, so the round-trip fails even though the ASCII punycode form is a perfectly valid DNS name that resolvers handle fine.

The fix checks whether the input domain is already pure ASCII (all bytes <= 0x7F). If so, it skips idn2_to_ascii_lz() entirely and goes straight to lowercasing + valid_domain() validation. Non-ASCII input (e.g. äöü.com typed in Unicode) still goes through the IDN conversion path as before. This is applied to both the domain list endpoint (src/api/list.c) and the search endpoint (src/api/search.c).

Fixed by #2838

[DL6ER]

This fix has been merged and will be part of the next release of Pi-hole FTL. Thanks for reporting!