Mailing List Archive

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.

---

Apart from that: The use of TLSA records (and perhaps CAA) together with CurveDNS (given it's lookup) is certainly as 'safe' as with DNSSEC, though the RFC just require the later.

Regards.
--eh.


> Am 26.05.2018 um 13:46 schrieb Manvendra Bhangui <mbhangui@gmail.com>:
>
> https://sourceforge.net/projects/indimail/files/netqmail-addons/tlsarr.patch.gz

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE

On 26 May 2018 at 18:39, Erwin Hoffmann <feh@fehcom.de> 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.

On 26 May 2018 at 18:39, Erwin Hoffmann <feh@fehcom.de> wrote:

>
> Apart from that: The use of TLSA records (and perhaps CAA) together with
> CurveDNS (given it's lookup) is certainly as 'safe' as with DNSSEC, though
> the RFC just require the later.
>
> Regards.
>
>
Thanks for the pointer. I will take a look at curvedns. Is it the one at
http://curvedns.on2it.net/ ?

Hi,


> Am 26.05.2018 um 15:57 schrieb Manvendra Bhangui <mbhangui@gmail.com>:
>
> On 26 May 2018 at 18:39, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> Apart from that: The use of TLSA records (and perhaps CAA) together with CurveDNS (given it's lookup) is certainly as 'safe' as with DNSSEC, though the RFC just require the later.
>
> Regards.
>
>
> Thanks for the pointer. I will take a look at curvedns. Is it the one at http://curvedns.on2it.net/ ?

Yeah, you can find more interesting implementations here:

https://www.fehcom.de/ipnet/djbdnscurve6.html

Apart from those, I hope to finish 'dbbdnscurve6' within the next weeks:

- entire IPv6 capability.
- rbldns can be used to flag IPv6 addresses.

Regards.
--eh.

>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE

On 28 May 2018 at 01:45, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> Yeah, you can find more interesting implementations here:
>
> https://www.fehcom.de/ipnet/djbdnscurve6.html
>
> Apart from those, I hope to finish 'dbbdnscurve6' within the next weeks:
>
> - entire IPv6 capability.
> - rbldns can be used to flag IPv6 addresses.

Looks interesting. Will be trying out this. If I have few problems, I
will trouble you :)

On 28 May 2018 at 01:45, Erwin Hoffmann <feh@fehcom.de> wrote:
>> Am 26.05.2018 um 15:57 schrieb Manvendra Bhangui <mbhangui@gmail.com>:
>> Thanks for the pointer. I will take a look at curvedns. Is it the one at http://curvedns.on2it.net/ ?
>
> Yeah, you can find more interesting implementations here:
>
> https://www.fehcom.de/ipnet/djbdnscurve6.html
>
> Apart from those, I hope to finish 'dbbdnscurve6' within the next weeks:
>
> - entire IPv6 capability.
> - rbldns can be used to flag IPv6 addresses.

I was working on few of those links you have mentioned on your page
(tinydnssec, curvedns-0.87, nacl, and dq). Have built the RPM/Debian
packages with the ipv6 patches and now even updated curvedns to 0.88

https://build.opensuse.org/package/show/home:indimail/tinydnssec

On 26 May 2018 at 17:16, Manvendra Bhangui <mbhangui@gmail.com> wrote:
> As part of DANE implementation, I have added a new function
> to dns.c library. I have made the following modifications but
> am stuck because of lack of knowledge about DNSSEC.
>
> 1. Modified dns.c and added dns_tlsarr() function
> 2. New source tlsarralloc.c, tlsarralloc.h which uses
> gen_alloc, gen_allocdefs
> 3. New program dnstlsarr which uses the above dns_tlsarr()
> function to query TLSA Resource Records

So finally I managed to get DANE verification for qmail. Did some
rudimentary testing and released it as part of indimail-mta-2.5. I
have also backported the changes to netqmail-1.06, after removing
IPV6, SPF, BATV code. I have backported from indimail-mta to netqmail
in a hurry and hence there could be bugs. If someone is really
interested in testing this, improving it and killing the bugs, I will
provide whatever help I can give. In that case just email me so that
we don't trouble the other subscribers of this list. This patch
provides SMTP AUTH and TLS in qmail-remote. Entire code has been
written using djb functions. No stdio.h, no string.h, etc. Also I have
not included qmail-daned - TLSA RR caching daemon for qmail in this
patch because that will require another few hours to back port it from
indimail-mta. Probably I will do it in the coming few days.

The link to the dane patch is here.
https://sourceforge.net/projects/indimail/files/netqmail-addons/dane.patch.gz

Please note that I have not tested it, other than testing the
dnstlsarr program. The same functions in dnstlsarr program are used by
qmail-remote.

Example usage of dnstlsarr (which can also function as a DANE tester)
are given below

Example 1 - Just Display the TLSA Resource Records.
$ dnstlsarr postino.cesnet.cz
terenasslca3ta.cesnet.cz ttl=3282 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25
terenasslca3ta.cesnet.cz ttl=3282 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8

Example 2
$ dnstlsarr -v 2 -s mail.ietf.org
checking mail.ietf.org
TLSARR[0]:_25._tcp.mail.ietf.org IN TLSA ( 3 1 1
0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6 )
220 ietfa.amsl.com ESMTP
Client: EHLO argos
250-ietfa.amsl.com
250-PIPELINING
250-SIZE 67108864
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
Client: STARTTLS
220 2.0.0 Ready to start TLS
matched sha256 fingerprint
[0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6] of
subjectPublicKeyInfo
Client: QUIT
221 2.0.0 Bye

Example 3 - querying the MX record to get the TLSA RR
$ dnstlsarr -v 2 -s postino.cesnet.cz
checking postino.cesnet.cz
TLSARR[0]:terenasslca3ta.cesnet.cz IN TLSA ( 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25 )
TLSARR[1]:terenasslca3ta.cesnet.cz IN TLSA ( 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8 )
220 postino.cesnet.cz ESMTP
Client: EHLO argos
250-postino.cesnet.cz
250-PIPELINING
250-SIZE 41943040
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
Client: STARTTLS
220 2.0.0 Ready to start TLS
failed sha256 fingerprint
[be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25] of
full certificate
matched sha256 fingerprint
[beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8] of
full certificate
Client: QUIT
221 2.0.0 Bye

Example 4 - getting TLSA RR by giving the domain name instead of the MX host
$ dnstlsarr -m cesnet.cz
MX postino.cesnet.cz IPv6 2001:718:1:101::144:24210
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8
MX postino.cesnet.cz IPv4 195.113.144.24210
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8
MX cartero.cesnet.cz IPv6 2001:718:ff05:202::1650
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8
MX cartero.cesnet.cz IPv4 78.128.216.1650
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8
MX mail.cesnet.cz IPv4 195.113.144.234100
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
be6a0d9e1d115f2293f6abf11b3ec8e882e24426eeeb09aaa503597993e77a25
terenasslca3ta.cesnet.cz ttl=2974 2 0 1
beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8


The current implementation does not use DNSSEC. At the moment, I still
have not figured out how to do DNSSEC. So this feature could come in
future release. Also the code is largely untested. Use it at your own
risk.

The original announcement is here
https://groups.google.com/forum/#!topic/indimail/LSTKnbwDWps