# inet\_res.resolve/5 works only with limited dns classes and types **URL:** \ **Category:** Questions / Help\ **Tags:** otp, inet\ **Created:** [November 9, 2023, 4:22pm UTC](https://erlangforums.com/t/inet-res-resolve-5-works-only-with-limited-dns-classes-and-types/3013 "2023-11-09T16:22:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![D4no0](https://erlangforums.com/letter_avatar_proxy/v4/letter/d/9e8a1a/32.png) [@D4no0](https://erlangforums.com/u/D4no0)\ **Post date:** [November 9, 2023, 4:22pm UTC](https://erlangforums.com/t/inet-res-resolve-5-works-only-with-limited-dns-classes-and-types/3013/1 "2023-11-09T16:22:15Z")
I am working currently on a project where I have to check for DNSSEC for specific zones, meaning I need to query for `RRSIG` records. I tried to use [`inet_res.resolve/5`](https://www.erlang.org/doc/man/inet_res#resolve-5), however if you look at the types it can operate on [here](https://www.erlang.org/doc/man/inet_res#type-dns_rr_type), it is clear that it is missing this and many more new record types. I was wondering if there is a way to make some kind of raw queries and parse them by myself? since for now I have to resort to use external clis like `dig` and I am not very keen to deal with leaking zombie processes. ---
**Author:** ![jimdigriz](https://erlangforums.com/user_avatar/erlangforums.com/jimdigriz/32/1885_2.png) [@jimdigriz](https://erlangforums.com/u/jimdigriz)\ **Post date:** [November 9, 2023, 9:59pm UTC](https://erlangforums.com/t/inet-res-resolve-5-works-only-with-limited-dns-classes-and-types/3013/2 "2023-11-09T21:59:20Z")
Try passing in the integer vales for the types. You will need to decode the binary value in the reply yourself but it works. ---
**Author:** ![jimdigriz](https://erlangforums.com/user_avatar/erlangforums.com/jimdigriz/32/1885_2.png) [@jimdigriz](https://erlangforums.com/u/jimdigriz)\ **Post date:** [November 13, 2023, 3:01pm UTC](https://erlangforums.com/t/inet-res-resolve-5-works-only-with-limited-dns-classes-and-types/3013/3 "2023-11-13T15:01:25Z")
If you are looking to handle DNSSEC, you may find some of the work I am doing for service discovery which involves SIG(0) helps: > > > This Work-in-Progress is to add \[SIG(0)\](https://datatracker.ietf.org/doc/rfc293…1/) support to OTP; similarly to the support for TSIG in https://github.com/erlang/otp/pull/6985. > > This work is necessary so that user code may implement the signing required by \[SRP\](https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/); I have created a \[reference client implementation\](https://gist.github.com/jimdigriz/6ded4c013c277d0d3e1931980165a5cf). > > Outstanding tasks: > \* ~~decoder~~ > \* ~~encoder~~ > \* verify messages > \* supports query validation only so far > \* sign messages > \* support TCP multi-message > \* tests (...see below though, I need guidance on what would be consider appropriate) > \* (optionally) support more KEY formats > > Outstanding Questions: > \* is this wanted? if not, could I lobby for just the \`#dns\_rr\_sig{}\` part so the rest could be handled in user land; similarly to TSIG we need to know the byte offset of the SIG(0) record and this is best worked out in \`inet\_dns.erl\` (which also includes \`FORMERR\` handling) to avoid having a second DNS decoder to figure that out > \* \`public\_key.hrl\` is included in \`inet\_dns.erl\` > \* this is to support \`{encode,decode}\_key\_publickey/2\` which maybe should be moved into \`inet\_dns\_sig0.erl\` > \* I remember for TSIG it was requested that \`{encode,decode}\_algname/1\` remained in \`inet\_dns.erl\` > \* I like the idea of returning \`public\_key\` types in the KEY RR as the binary would not be usable unable to do this anyway (avoiding needless duplication in user code) > \* which \[security algorithms need to be included\](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1) > \* there is some overlap with DNSSEC here, so there may be a desire to generalise this > \* this may though be no more difficult that writing an implementation of Canonical DNS Name Ordering (\[RFC2535, section 8\](https://datatracker.ietf.org/doc/html/rfc2535#section-8)) > \* I do not know enough about DNSSEC to be able to determine how the interface should function so would prefer to keep this as SIG(0) only > > Things that make this fun, I am unable to see how end-to-end testing will work as: > > \* knotd does not support SIG(0); looks like it was removed in 2.0 > \* BIND9 supports SIG(0) but does not: > \* \[support multiple messages seen via TCP\](https://bind9.readthedocs.io/en/stable/chapter7.html#sig-0) > \* sign responses > \* looking through the instructions and the source code I think it is unable to > \* though in practice this is probably not useful, as the client would need to pre-trust the KEY RR somehow > \* \[\`dnspython\`\](https://www.dnspython.org/) does \[not support SIG(0)\](https://github.com/rthalley/dnspython/issues/314) > > Maybe a rework of the reference Python implementation would suffice as a sort of DNS bitbanger? I think you may need to do a canonical sort to get (RR)SIG working, but at least the ‘crypto sausage making machine’ you no longer have to figure out; or if you already have, its be a dual wasted effort of duplication…but at least (frustratingly) educational. Do poke me off list if you want to collaborate on this if you think there is overlap. ---
**Author:** ![D4no0](https://erlangforums.com/letter_avatar_proxy/v4/letter/d/9e8a1a/32.png) [@D4no0](https://erlangforums.com/u/D4no0)\ **Post date:** [November 13, 2023, 3:51pm UTC](https://erlangforums.com/t/inet-res-resolve-5-works-only-with-limited-dns-classes-and-types/3013/4 "2023-11-13T15:51:37Z")
I am currently working on a tool that checks web security. One of the checks we want to perform is checking DNSSEC and validation of records like RRSIG. For now we have more important things to attend to, so I will get back later with more information. We currently ended up with using `dig` to query for RRSIG records as a workaround, however if the support for dnssec will be improved in erlang, we will refactor to the official library. > [@jimdigriz](#): > > I think you may need to do a canonical sort to get (RR)SIG working, but at least the ‘crypto sausage making machine’ you no longer have to figure out; or if you already have, its be a dual wasted effort of duplication…but at least (frustratingly) educational. > > Do poke me off list if you want to collaborate on this if you think there is overlap. I am not sure we can collaborate as we are writing everything in elixir, the exception is usage of OTP libraries.