Hello, thank you for the great tool, this one looks very promising.
Seeing the vast amount of tunables supported, I thought it would make sense to propose the things I'm about to propose, to make it even more powerful.
In modern dig versions, there is a +unknownformat option that lets you see the raw (well, hex) bytes for any RR value, so that it is not parsed by the client. This is useful when debugging very low-level DNS response issues.
Also, I noticed that the tool does not accept the TYPE<N> notation for records, supporting only the named RRs, but this is useful for working with experimental RR types that are not standard. Would be very cool if the tool could accept TYPE* as the type argument, even if there is no explicit support for parsing the response structure.
E.g. here (of course HTTPS RR is now standard, but it used to not be one):
Hello, thank you for the great tool, this one looks very promising.
Seeing the vast amount of tunables supported, I thought it would make sense to propose the things I'm about to propose, to make it even more powerful.
In modern dig versions, there is a
+unknownformatoption that lets you see the raw (well, hex) bytes for any RR value, so that it is not parsed by the client. This is useful when debugging very low-level DNS response issues.Also, I noticed that the tool does not accept the
TYPE<N>notation for records, supporting only the named RRs, but this is useful for working with experimental RR types that are not standard. Would be very cool if the tool could acceptTYPE*as the type argument, even if there is no explicit support for parsing the response structure.E.g. here (of course
HTTPSRR is now standard, but it used to not be one):Thanks!