On Mon, Sep 30, 2024 at 04:39:24AM +0000, Rahul Thakur via Dnsmasq-discuss wrote: > Sent: 25 September 2024 15:29, From: Rahul Thakur <rahul.tha...@genexis.eu> > > > > Hi Simon, > > > > Thanks for responding to this patch, please find my justification > > for this patch as follows: > > > > I think rfc 2181 is defining the behaviour for DNS server and not > > DNS proxy. > > > > I am relying on and referring to rfc 5625 while making this change. > > > > In section 4.4 > > (https://datatracker.ietf.org/doc/html/rfc5625#section-4.4), the > > rfc 5625 states, > > > > If a proxy must unilaterally truncate a response, then the proxy MUST > > set the TC bit. Similarly, proxies MUST NOT remove the TC bit from > > responses. > > > > Dnsmasq is ofcourse complying to this behaviour > > and not meddling with the TC bit while setting the > > answers to 0. But, if I read further section 4.4.1 > > (https://datatracker.ietf.org/doc/html/rfc5625#section-4.4.1), > > > > Whilst TCP transport is not strictly mandatory, it is supported by > > the vast majority of stub resolvers and recursive servers. > > > > So, this indicates that it is not mandatory that > > the client ignores this truncated response. This > > is further supported by section 6.1.3.2 of rfc 1123 > > (https://datatracker.ietf.org/doc/html/rfc1123#section-6.1.3.2). In > > paragraph 3 of the DISCUSSION in section 6.1.3.2, it states, > > > > Whether it is possible to use a truncated answer > > depends on the application. > > > > Hence, when dnsmasq explicitly deletes the answers, then it deprives > > clients that do not fallback to TCP and are happy with the truncated > > response to be able to resolve their queries. > > > > To me, it sounds like a better strategy to forward the truncated > > response as is to the client and let the client decide what it wants > > to do rather than forcefully dropping the answers. > > > > Best regards, > > Rahul Thakur > > > > Hi Simon, > > So what do you think of my reasoning for this patch? Do you agree?
Review the feedback that was given by Simon. Review the patch with the feedback in mind. Submit a revisited patch and see what happens. > Best regards, > Rahul Thakur Groeten Geert Stappers -- Silence is hard to parse _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
