From: "piradata (Guilherme Ferreira)" Date: 2022-06-19T17:39:19+00:00 Subject: [ruby-core:109007] [Ruby master Bug#18842] Ruby's Resolv library does not handle correctly the `NODATA` case Issue #18842 has been reported by piradata (Guilherme Ferreira). ---------------------------------------- Bug #18842: Ruby's Resolv library does not handle correctly the `NODATA` case https://bugs.ruby-lang.org/issues/18842 * Author: piradata (Guilherme Ferreira) * Status: Open * Priority: Normal * ruby -v: 2.7.5p203 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Hello, I am opening this issue based on the following DNS bug sleuthing: https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3303 As described by Stan Hu, seems like the Ruby's Resolv library does not handle correctly the `NODATA` case because if any of the searchpaths return the `NODATA` response the search stops there and the domain is not correctly resolved, as the correct resolution should be using the input address as FQDN. Ruby looks at the DNS response code (https://github.com/ruby/ruby/blob/9c0df2e81c22e6e35f3c5d69a070c2a3cf67e320/lib/resolv.rb#L532-L552), which is described in https://datatracker.ietf.org/doc/html/rfc2929#section-2.3. We are assuming that, as described in the issue, the .aws search path caused the DNS to return "No error" and DNS Resolver interprets it as valid. Busybox's nslookup implementation mentions the NODATA case here: https://git.busybox.net/busybox/tree/networking/nslookup.c?h=1_35_stable#n650. https://datatracker.ietf.org/doc/html/rfc2308#section-2.2.1 and may describe the problem with Ruby's Resolv implementation: ``` There are a large number of resolvers currently in existence that fail to correctly detect and process all forms of NODATA response. Some resolvers treat a TYPE 1 NODATA response as a referral. To alleviate this problem it is recommended that servers that are authoritative for the NODATA response only send TYPE 2 NODATA responses, that is the authority section contains a SOA record and no NS records. Sending a TYPE 1 NODATA response from a non- authoritative server to one of these resolvers will only result in an unnecessary query. If a server is listed as a FORWARDER for another resolver it may also be necessary to disable the sending of TYPE 1 NODATA response for non-authoritative NODATA responses. Some name servers fail to set the RCODE to NXDOMAIN in the presence of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA answer is required in this case the resolver must query again using the QNAME as the query label. ``` As it sounded like a Ruby bug report I decided to open this issue in order to correctly to handle the NODATA case. The link for the sleuthing of the problem part: https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3303#note_950108922 and the specific problem can be found on the start of the comment when we could not resolve the DNS unless we removed the aws searchpath as this serachpath specifically was returning the `NODATA` response. -- https://bugs.ruby-lang.org/ Unsubscribe: