Adding DNSSEC-related RRs into inet_res and inet_dns

[antranigv]

In the modern world, DNSSEC is everywhere, however, sometimes people don't implement it on their domain, which is why I was trying to create an application, where I pass it a domain and it checks for the ad flag, as well as for DNSSEC-related RR records, such as RRSIG, DS and DNSKEY.

Turns out that Erlang/OTP's inet_res does get the RRSIG records if dnssec_ok is set to true and edns is set to 0 inside of res_option(), however, the ad flag is not parsed and the RRSIG records are not recognized. all I see is type: 46.

Additionally, There is no way to send a query for the DS and DNSKEY resource records.

In an ideal world, all I need is the ad flag to be parsed (so I can make sure the DNSSEC'd response is validated by the resolver) and that the RRSIG, DS and DNSKEYs are accepted by OTP.

I'd like to implement this myself, but opening the ticket here because missed couple of things when I tried to do this :) If you can guide, I'll send a PR directly. I also wanted to confirm that I'm on the right path for adding these features.

Where are the DNS headers defined? I missed that part. There are other DNS RR types, should they be added as well? Such as SSHFP.

Thank you Erlang/OTP team!

[RaimoNiskanen]

Hi @antranigv and thank you for your interest in our DNS resolver library!

The development is largely driven by user interest, such as yours, so I will try to guide you. The resolver library is also used by our internal Ericsson customers so it is crucial to not break existing code without very good reason, which places limits on how we can do changes...

The Erlang records for DNS records are defined in lib/kernel/src/inet_dns.hrl. Here are also the record names and types defined.

Encoding is done in lib/kernel/src/inet_dns.erl. For example the #dns_rr_opt{} and #dns_rr{} records are encoded to wire format by encode_res_section/4 and helper functions such as encode_type/1. Decoding is done by decode_rr_section/5 and helper functions, in particular decode_data/3, decode_type/1 and such.

DNSSEC record would certainly be a welcome addition. We can take SSHFP at a later time - it is the first time I hear of it.

[antranigv]

Hi Raimo, Thank you for your guidance! Somehow my eye missed the inet_dns.hrl file. Now that I look at it, it makes total sense. I will add the DNSSEC resource records and their headers into the DNS library. If there’s interest, I’ll gladly add other records as well, such as SSHFP and whatever else is missing. There’s a cool list on Wikipedia! https://en.wikipedia.org/wiki/List_of_DNS_record_types#Resource_records Again, thank you and the Erlang team for all your work. Kind regards, — Antranig Vartanian https://antranigv.am/ PGP Key ID: 0x2D59F21C

…

On 28 Aug 2024, at 11:29 AM, Raimo Niskanen ***@***.***> wrote: Hi @antranigv and thank you for your interest in our DNS resolver library! The development is largely driven by user interest, such as yours, so I will try to guide you. The resolver library is also used by our internal Ericsson customers so it is crucial to not break existing code without very good reason, which places limits on how we can do changes... The Erlang records for DNS records are defined in lib/kernel/src/inet_dns.hrl. Here are also the record names and types defined. Encoding is done in lib/kernel/src/inet_dns.erl. For example the #dns_rr_opt{} and #dns_rr{} records are encoded to wire format by encode_res_section/4 and helper functions such as encode_type/1. Decoding is done by decode_rr_section/5 and helper functions, in particular decode_data/3, decode_type/1 and such. DNSSEC record would certainly be a welcome addition. We can take SSHFP at a later time - it is the first time I hear of it. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>