|
**[1] `dns.question.name`:** If the name field contains non-printable characters (below 32 or above 126), those characters should be represented as escaped base 10 integers (\DDD). Back slashes and quotes should be escaped. Tabs, carriage returns, and line feeds should be converted to \t, \r, and \n respectively. |
If the name field contains non-printable characters (below 32 or above 126), those characters should be represented as escaped base 10 integers (\DDD). Back slashes and quotes should be escaped. Tabs, carriage returns, and line feeds should be converted to \t, \r, and \n respectively.
Seems to be incorrect. DNS supports ASCII only and there is rfc3492 on how to record unicode in domain names which looks like xn--s1ab.xn--80ab0c:80 - this is called Punycode.
I'd like to revisit the need to do any type of normalization or escaping - instrumentation on the DNS level is likely to deal with IP address primitive provided by the standard library which is already encoded.
Knowing that unencoded (invalid) address is submitted for resolution is important, and there are no constraints in OTel that would require special encoding. We can mention that it's likely in Punycode, but no normalization is needed.
semantic-conventions/docs/attributes-registry/dns.md
Line 14 in 55009b3
Seems to be incorrect. DNS supports ASCII only and there is rfc3492 on how to record unicode in domain names which looks like xn--s1ab.xn--80ab0c:80 - this is called Punycode.
I'd like to revisit the need to do any type of normalization or escaping - instrumentation on the DNS level is likely to deal with IP address primitive provided by the standard library which is already encoded.
Knowing that unencoded (invalid) address is submitted for resolution is important, and there are no constraints in OTel that would require special encoding. We can mention that it's likely in Punycode, but no normalization is needed.