Replies: 8 comments 2 replies
|
Hi, thanks for reporting this. Could you please point out the error(s) in the JSON output? I'm not completely understanding the issue yet. Thanks! |
|
Hello, In " Here ; with " # KO
⛔🔜 root@srv-fr.h1.ww1:~ # dig ANY ◕‿◕.ST @dns.google | jc --dig -p
[
"question": {
# HERE
"name": "\\226\\151\\149\\226\\128\\191\\226\\151\\149.ST.",
"class": "IN",
"type": "ANY"
},
# HERE BUT COMPREHENSIVE
"authority": [
{
"name": "ST.",
"class": "IN",
"type": "SOA",
"ttl": 1800,
"data": "ns1.bahnhof.net. hostmaster.nic.ST. 2511386452 3600 900 1209600 86400"
}
],
]Thanks sir. |
|
IDNA (PunyCode) for domain en sub domain name + URL ENCODE For DOMAIN NAME AND SUB DOMAIN : 
For URL DIRECTORY : 
CF : https://www.punycoder.com/ The latest RFC 9549 (https://www.rfc-editor.org/rfc/rfc9549), dating from March 2024, is an improvement and update to RFC 5280 (and obsoletes RFC 8399). By the way, not in the wind, the following ⛔🔜 root@srv-fr.h1.ww1:~ # dig dns.google @dns.🇫🇷.◕‿◕.st
dig: couldn't get address for 'dns.🇫🇷.◕‿◕.st': not foundIt's slightly stupid. ⛔🔜 root@srv-fr.h1.ww1:~ # host dns.🇫🇷.◕‿◕.st
dns.xn--j77hya.xn--hwgz2tba.st has address 109.210.49.186
dns.xn--j77hya.xn--hwgz2tba.st has IPv6 address 2a01:cb1d:6aa:b400:1ab3::1😇 Suppressing this symptom, too : Input command : PunyCode → Output : ASCII : OK ⛔🔜 root@srv-fr.h1.ww1:~ # dig xn--hwgz2tba.st +nocomments +noquestion +noauthority +noadditional +nostats
; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> xn--hwgz2tba.st +nocomments +noquestion +noauthority +noadditional +nostats
;; global options: +cmd
◕‿◕.st. 3600 IN A 158.69.126.137
◕‿◕.st. 3600 IN A 147.79.115.130
# OKWith " ⛔🔜 root@srv-fr.h1.ww1:~ # dig xn--hwgz2tba.st +nocomments +noquestion +noauthority +noadditional +nostats | awk '{if (NR>3){print}}'| tr -s '\t'
xn--hwgz2tba.st. 3600 IN A 147.79.115.130
xn--hwgz2tba.st. 3600 IN A 158.69.126.137
# KOInput command IDNA (ASCII) → Output : ASCII : OK ⛔🔜 root@srv-fr.h1.ww1:~ # dig ◕‿◕.st +nocomments +noquestion +noauthority +noadditional +nostats
; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ◕‿◕.st +nocomments +noquestion +noauthority +noadditional +nostats
;; global options: +cmd
◕‿◕.st. 3579 IN A 158.69.126.137
◕‿◕.st. 3579 IN A 147.79.115.130
# OKWith " ⛔🔜 root@srv-fr.h1.ww1:~ # dig ◕‿◕.st +nocomments +noquestion +noauthority +noadditional +nostats | awk '{if (NR>3){print}}'| tr -s '\t'
# KO🤩 I'm trying to get the same output as " # my test....
dig xn--hwgz2tba.st +nocomments +noquestion +noauthority +noadditional +nostats +noidnout | awk '{if (NR>3){ cmd = "idn -d " $1; v="xn--" ($1 ~ v); print v" "$2" "$3" "$4 $5 }}'# example :
martijn@monitoring:~$ dig aaaa google.com +nocomments +noquestion +noauthority +noadditional +nostats | awk '{if (NR>3){print}}' | tr -s '\t' | jq -R 'split("\t") |{Name:.[0],TTL:.[1],Class:.[2],Type:.[3],IpAddress:.[4]}'
{
"Name": "google.com.",
"TTL": "76",
"Class": "IN",
"Type": "AAAA",
"IpAddress": "2a00:1450:400e:80e::200e"
}CF : Martijn.Gr, Converting DIG output to JSON Because—and precisely because the IDNA standard is designed for domain names (meaning there's a TLD involved)—the " ⛔🔜 root@srv-fr.h1.ww1:~ # idn -d xn--hwgz2tba.st.
x࢙࢞࢜n࢙࢙-ࡴ࢟ࢡ
⛔🔜 root@srv-fr.h1.ww1:~ # idn -d xn--hwgz2tba
x࢙n࢙࢙-ࡴ
⛔🔜 root@srv-fr.h1.ww1:~ # idn -d hwgz2tba
◕‿◕And more "
For Text Unicode to PunyCode (ASCII) : ⛔🔜 root@srv-fr.h1.ww1:~ # idn -a IP❤10
xn--ip10-mw4b
# OK⛔🔜 root@srv-fr.h1.ww1:~ # idn -a IP❤10.WS
xn--ip10-mw4b.WS
# OKFor PunyCode (ASCII) to Text Unicode : ⛔🔜 root@srv-fr.h1.ww1:~ # idn -d xn--ip10-mw4b.ws
idn: punycode_decode: Invalid input
# KO⛔🔜 root@srv-fr.h1.ww1:~ # idn -d xn--ip10-mw4b
xn-ᘛ-ip10
# KO⛔🔜 root@srv-fr.h1.ww1:~ # idn -d ip10-mw4b
ip❤10
# OKCan anyone help me out ? 😉 Many thanks. The IDNA standard is linked to domain names and is mandatory for SSL/TLS certificates : ⛔🔜 root@srv-fr:~ # echo | openssl s_client -showcerts -connect xn--8s8h.xn--j77hya.xn--hwgz2tba.st:443 -servername xn--8s8h.xn--j77hya.xn--hwgz2tba.st -tls1_3 | openssl x509 -text -noout
depth=3 C = US, O = Internet Security Research Group, CN = ISRG Root X2
verify return:1
depth=2 C = US, O = ISRG, CN = Root YE
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = YE2
verify return:1
depth=0 CN = media.fr.xn--hwgz2tba.st
verify return:1
DONE
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
05:ff:7a:f3:44:19:3c:3b:ca:6a:2e:f4:30:a2:34:18:3a:d5
Signature Algorithm: ecdsa-with-SHA384
Issuer: C = US, O = Let's Encrypt, CN = YE2
Validity
Not Before: Jul 18 15:33:18 2026 GMT
Not After : Oct 16 15:33:17 2026 GMT
Subject: CN = media.fr.xn--hwgz2tba.st
Authority Information Access:
CA Issuers - URI:http://ye2.i.lencr.org/
[...]
X509v3 Subject Alternative Name:
DNS:media.fr.xn--hwgz2tba.st, DNS:media.xn--j77hya.xn--hwgz2tba.st, DNS:xn--5s8h.fr.xn--hwgz2tba.st, DNS:xn--5s8h.xn--j77hya.xn--hwgz2tba.st, DNS:xn--7s8h.fr.xn--hwgz2tba.st, DNS:xn--7s8h.xn--j77hya.xn--hwgz2tba.st, DNS:xn--8s8h.fr.xn--hwgz2tba.st, DNS:xn--8s8h.xn--j77hya.xn--hwgz2tba.st
[...]
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1For this subdomain name emojis style and style domain : ; SSL Certificat 5 or SSL Certificat 1 - OK
media.fr.◕‿◕.st ; (alias AAAA x A for identificate IPs)
media.🇫🇷.◕‿◕.st ; (alias AAAA x A for identificate IPs)
💿.fr.◕‿◕.st ; (alias AAAA x A for identificate IPs)
💿.🇫🇷.◕‿◕.st ; (alias AAAA x A for identificate IPs)
📀.fr.◕‿◕.st ; (alias AAAA x A for identificate IPs)
📀.🇫🇷.◕‿◕.st ; (alias AAAA x A for identificate IPs)
💽.fr.◕‿◕.st ; (alias AAAA x A for identificate IPs)
💽.🇫🇷.◕‿◕.st ; (alias AAAA x A / reverse PTR IP6.ARPA for identificate Container/Docker)A trip toward happiness, with the colors ; we arrive at the new matrix ; in our logs. Unicode > Full Emoji List, v17.0 : https://unicode.org/emoji/charts/full-emoji-list.html 
Punycode is an essential encoding system for enabling internationalized domain names (IDNs) to work across the Internet and all applications. How Punycode works :
In principle, the " ZW3B’s LAB3W : The Web’s Laboratory ; Engineering of the Internet |
|
Because even Google's AI agent replies that the domain doesn't exist; it must be trying to retrieve it in JSON format. Regarding this subdomain: SRV.🇨🇦.◕‿◕.ST # Other example :
2607:5300:60:9389:15:2:a:1000 (NS2) - Name Server Bind9 - FQDN : 🌈.🇨🇦.ip❤10.ws.
fc00:5300:60:9389:15:2:a:1000 - FQDN LOCAL : 🌈.🇨🇦.ip❤10.ws. I pointed out to it that the output of the command " It apologized for the error ; that was yesterday. # Example :
⛔🔜 root@srv-fr.h1.ww1:~ # dig ANY ns2.ca.ipv10.net @dns.google
; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ANY ns2.ca.ipv10.net @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47714
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ns2.ca.ipv10.net. IN ANY
;; ANSWER SECTION:
ns2.ca.ipv10.net. 3600 IN AAAA 2607:5300:60:9389:15:2:a:1000
ns2.ca.ipv10.net. 3600 IN RRSIG AAAA 13 4 3600 20260912223023 20260813222108 3274 ipv10.net. vgml4n5cCVR2QKeKwm3HoGbva94CThAPTw116W6uAkx8w/7hIVL465CJ 4Vd5wdEGst+HaNA/V67X6V1rz8IgUQ==
;; Query time: 139 msec
;; SERVER: 2001:4860:4860::8844#53(dns.google) (TCP)
;; WHEN: Fri Aug 21 00:29:35 CEST 2026
;; MSG SIZE rcvd: 178⛔🔜 root@srv-fr.h1.ww1:~ # dig -x 2607:5300:60:9389:15:2:a:1000 @dns.google
; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> -x 2607:5300:60:9389:15:2:a:1000 @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34935
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;0.0.0.1.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
0.0.0.1.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa. 60 IN PTR 🌈.🇨🇦.ip❤10.ws.
;; Query time: 119 msec
;; SERVER: 2001:4860:4860::8888#53(dns.google) (UDP)
;; WHEN: Fri Aug 21 00:20:40 CEST 2026
;; MSG SIZE rcvd: 150 |
|
I was trying to recreate your issue, but I cannot. Can you tell me what setup is needed for this? I tried with the following to get into a Debian installation that matches your version of dig ( But in that case I cannot even run dig: dig ◕‿◕.ST @dns.google
# dig: '◕‿◕.ST' is not a legal IDNA2008 name (could not convert string to UTF-8), use +noidninWhen using the dig ◕‿◕.ST @dns.google +noidnin
#
# ; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ◕‿◕.ST @dns.google +noidnin
# ;; global options: +cmd
# ;; Got answer:
# ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41508
# ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
#
# ;; OPT PSEUDOSECTION:
# ; EDNS: version: 0, flags:; udp: 512
# ;; QUESTION SECTION:
# ;\226\151\149\226\128\191\226\151\149.ST. IN A
# <<SNIP>>And once I am using "question": {
"name": "\\226\\151\\149\\226\\128\\191\\226\\151\\149.ST.",
"class": "IN",
"type": "ANY"
},So this seems to work exactly as expected? Note that this name is still exactly what you were providing. It is just encoding as escaped decimal bytes: I would not expect jc to do that sort of post-processing on the question section though, if dig has escaped decimal bytes then I expect that in my JSON as well. |
|
Hello @Zegnat, thanks for you reply. First of all, your system returns : That isn't the issue... Your system identifies the 2008 RFC but is reporting incorrect information; the current RFC is this one, dating from 2024 : Internationalization Updates to RFC 5280 So : For Internationalized Domain Names (IDNA): The " On older systems, you generally need to send the Punycode (because the system itself does not handle special characters) ; consequently, " On all systems (modern and legacy) : If you want to retrieve the Punycode value (the one to be configured in the DNS or rDNS zone file): You can pass "+noIDNout" to " The IETF standard applies to "domain names" and "subdomains" ; it is also linked to "SSL/TLS" certificates, which in turn are linked to those "domain names" and "subdomains". Returning to the issue with " You should never encode the " Depending on the OS, you then return either :
Greets, To make things easier (using an "é" instead of an "emoji"), you can use the following "domain name"—which is an old "IDNA" domain. Since around 2025, the domain has displayed correctly in your browser's address bar → http://armées.com Text : armées.com
|
So what system are you using? I am trying to recreate your problem. According to your previous post, you were using Are you saying you are using a legacy system? Then that is probably why you are having issues. Note that the 9.18 versions reached end-of-life this year. Can you tell me on which distro’s BIND 9 and which exact version of dig you are using when you have your original problem? Even better if you can provide a Docker image that reproduces your original issue so it is easier to test if jc is doing the correct parsing of dig’s output. That is what I was trying to do: reproduce your problem on your version of dig. |
|
Hello again. I happen to have several systems—some quite old, others running Debian "sid". For example: In Buster (Debian 10): input/output must be PunyCode. In Buster, I haven't yet tried the "jc" wrapper to get JSON output from dig commands. In Bookworm (Debian 12): input/output is plain text. This might be the area to investigate: In Bookworm (Debian 12) jc version : 1.22.5 https://github.com/kellyjonbrazil/jc Because there is also an issue with AWK, and likely with other commands like "ping", "hostname", and "tcpdump" that don't natively support IDNA. However, regarding "jc --dig" — as a user, I can clearly see and understand the problem I mentioned earlier. You must capture and encode the input as PunyCode for the DNS query (and then convert it back to normal text or display the PunyCode). I admit I don't know exactly where the root cause lies, but that is the direction to look in; specifically for JC, the " For example, on my web server, I have this type of address: the domain encoded in PunyCode and the URL using percent-encoding : https://srv.xn--e77hd.xn--hwgz2tba.st/infos/my-traceroute/mtr-json-result_srv.%F0%9F%87%A8%F0%9F%87%A6.%E2%97%95%E2%80%BF%E2%97%95.st_TO_hst.%F0%9F%87%AB%F0%9F%87%B7.%E2%97%95%E2%80%BF%E2%97%95.st_tcp_443_ipv6.json In the end, when everything is over : https://srv.🇨🇦.◕‿◕.st/infos/my-traceroute/mtr-json-result_srv.🇨🇦.◕‿◕.st_TO_hst.🇫🇷.◕‿◕.st_tcp_443_ipv6.json 😉 Thanks you sir. Links : |
|
That was a lot of information. I am again going to try and only get down to your original problem. I am just trying to recreate whatever issue you are having with jc on the dig output. I am now testing with:
When I try to run your original query: dig ANY ◕‿◕.ST @dns.google | jc --dig -pI can now confirm that the output includes: "question": {
"name": "\\226\\151\\149\\226\\128\\191\\226\\151\\149.ST.",
"class": "IN",
"type": "ANY"
},Full response[
{
"id": 56221,
"opcode": "QUERY",
"status": "NXDOMAIN",
"flags": [
"qr",
"rd",
"ra"
],
"query_num": 1,
"answer_num": 0,
"authority_num": 1,
"additional_num": 1,
"opt_pseudosection": {
"edns": {
"version": 0,
"flags": [],
"udp": 512
}
},
"question": {
"name": "\\226\\151\\149\\226\\128\\191\\226\\151\\149.ST.",
"class": "IN",
"type": "ANY"
},
"authority": [
{
"name": "ST.",
"class": "IN",
"type": "SOA",
"ttl": 1800,
"data": "ns1.bahnhof.net. hostmaster.nic.ST. 2511388119 3600 900 1209600 86400"
}
],
"query_time": 53,
"server": "8.8.4.4#53(dns.google) (TCP)",
"when": "Wed Sep 02 21:20:01 CEST 2026",
"rcvd": 107,
"when_epoch": 1788376801,
"when_epoch_utc": null
}
]Interestingly it looks like this is actually behaviour coming from dig. So this might not be fixable by jc. We can see this in action by switching jc for any other tool, e.g. just cat: dig ANY ◕‿◕.ST @dns.google | cat -This tells us exactly what dig is piping through. And it is: ; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ANY ◕‿◕.ST @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15886
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;\226\151\149\226\128\191\226\151\149.ST. IN ANY
;; AUTHORITY SECTION:
ST. 1266 IN SOA ns1.bahnhof.net. hostmaster.nic.ST. 2511388119 3600 900 1209600 86400
;; Query time: 26 msec
;; SERVER: 8.8.4.4#53(dns.google) (TCP)
;; WHEN: Wed Sep 02 21:31:51 CEST 2026
;; MSG SIZE rcvd: 107No IDN! But when I run without the pipe: ; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ANY ◕‿◕.ST @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52137
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;◕‿◕.st. IN ANY
;; ANSWER SECTION:
◕‿◕.st. 3600 IN SOA ns1.ip❤10.ws. 👮.ip❤10.ws. 2025110538 300 60 420 60
◕‿◕.st. 3600 IN NS ns2.ip❤10.ws.
◕‿◕.st. 3600 IN NS ns1.ip❤10.ws.
◕‿◕.st. 3600 IN A 158.69.126.137
◕‿◕.st. 3600 IN A 147.79.115.130
◕‿◕.st. 3600 IN MX 10 smtp.◕‿◕.st.
◕‿◕.st. 10800 IN TXT "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/128 ~all"
◕‿◕.st. 3600 IN AAAA 2607:5300:60:9389::1
◕‿◕.st. 3600 IN AAAA 2a02:4780:28:5295::1
◕‿◕.st. 10800 IN SPF "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/128 ~all"
;; Query time: 276 msec
;; SERVER: 8.8.8.8#53(dns.google) (TCP)
;; WHEN: Wed Sep 02 21:33:53 CEST 2026
;; MSG SIZE rcvd: 418It seems like there is something in dig that is trying to guess what type of file descriptor it is writing to and then changing what it wants to output. The jc parsing actually works. If we fool dig into thinking it writes to a terminal and not to a pipe, then jc gives us the correct output: script -q -c "dig ANY ◕‿◕.ST @dns.google" /dev/null | jc --dig -pNow our JSON has: "question": {
"name": "◕‿◕.st.",
"class": "IN",
"type": "ANY"
},Full response[
{
"id": 56276,
"opcode": "QUERY",
"status": "NOERROR",
"flags": [
"qr",
"rd",
"ra"
],
"query_num": 1,
"answer_num": 10,
"authority_num": 0,
"additional_num": 1,
"opt_pseudosection": {
"edns": {
"version": 0,
"flags": [],
"udp": 512
}
},
"question": {
"name": "◕‿◕.st.",
"class": "IN",
"type": "ANY"
},
"answer": [
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "SOA",
"ttl": 3600,
"data": "ns1.ip❤10.ws. 👮.ip❤10.ws. 2025110538 300 60 420 60"
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "NS",
"ttl": 3600,
"data": "ns2.ip❤10.ws."
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "NS",
"ttl": 3600,
"data": "ns1.ip❤10.ws."
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "A",
"ttl": 3600,
"data": "147.79.115.130"
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "A",
"ttl": 3600,
"data": "158.69.126.137"
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "MX",
"ttl": 3600,
"data": "10 smtp.◕‿◕.st."
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "TXT",
"ttl": 10800,
"data": "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/128 ~all"
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "AAAA",
"ttl": 3600,
"data": "2607:5300:60:9389::1"
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "AAAA",
"ttl": 3600,
"data": "2a02:4780:28:5295::1"
},
{
"name": "◕‿◕.st.",
"class": "IN",
"type": "SPF",
"ttl": 10800,
"data": "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/128 ~all"
}
],
"query_time": 374,
"server": "8.8.8.8#53(dns.google) (TCP)",
"when": "Wed Sep 02 21:35:28 CEST 2026",
"rcvd": 418,
"when_epoch": 1788377728,
"when_epoch_utc": null
}
] |
|
Ok, sir @Zegnat, perfect ! Thanks a lot for this response. Now we should notify https://dns.google 😉✌️ |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
It seems to me that there is an error with the response from "
jc --dig".The
digcommand responds correctly, whether translated into IDNA or—on older systems—PunyCode (using+noidnout).Could you please correct this ?
Best regards.
Romain.
Normal 👍
For your information, this is an IDNA : Internationalizing Domain Names in Applications.
For command in our system (out dig) :
Thanks.
All reactions