Re: dns.c modification patch for getting TLSA RR records

On 26 May 2018 at 18:39, Erwin Hoffmann <[email protected]> wrote:

> Hi Manvendra,
>
> thanks for the interesting patch and your ever supporting work ;-)
>
> "4. In the course of writing, discovered and fixed an extremely
>   minor memory leak in dns_mxip(). How did djb miss it?"
>
> Code in dns.c:
>
>  42 - if (!nummx) return dns_ip(ia,sa); /* e.g., CNAME -> A */
>  43 + if (!nummx) {
>  44 +  alloc_free(mx); /*- how did djb forget to free this in original
> qmail-1.03?. Proves that he is a mortal */
>  45 +  return dns_ip(ia,sa); /* e.g., CNAME -> A */
>  46 + }
>
>
> Hm. I don't think it is a real problem here: qmail-remote has finished
> it's job and mail will be delivered (or not). In this case, the
> qmail-remote process is decommissioned and the OS will free the memory it
> has given anyway.
>
> In my qmail-smtpd and regarding the SPF piece I also did not clean up the
> allocated memory. It will be freed whatsoever. Maybe that should be
> considered 'bad style', but on the other hand, it saves some CPU cycles. Of
> course, considering long-running daemons this is a different story.
>
> The above is definitely not a problem as dns_mxip() is used only by
qmail-remote and dnsmxip program. Both of which exit after doing its job.
But long running daemon - exactly the reason, why I put the alloc_free(). I
wrote a daemon qmail-daned which calls these dns function for every request
and caches the MX record, TLSA RR records and the result of the DANE
verification. I took a look at dbjdns and if I can figure out how to cache
those TLSA records, I will discard qmail-daned. But for the moment the
alloc_free() was required in my case.