DKIM issues - dkim=neutral (no key) and other errors - gmail

I'm trying to upgrade my PHP DKIM from Sha1 to Sha256 and getting errors. I tried many things (as follows), basically gmail fails to authenticate my signature with all sorts of errors (as follows). My message header is:
ARC-Seal: i=1; a=rsa-sha256; t=1531129068; cv=none;
d=google.com; s=arc-20160816;
b=AbkKcrsMJTl1UsVer0iTqShaCPEbef/33ABSdCP6FB6BvWeOVnmE4xNIcJjZTXwE8B
OuwXkIa26k4i8I6NqSSCwnQoa1QENQCnMSFUJX9hxQa774BMmME+1c2AP7h7Jb7ug8Z8
9EYXQCuJNLs1FnApd8p2gsx/RsC9DQ6Z3M57mrZpIp9N6MsAE9VAGQ/sthz+dkMkJlvT
V1hEO26gjXPivGe14EFTb0h5q6kkgoWONQXG+gQQVWEzDk8Gq/eT7Ilm9Fzh0V2PNb+n
n5zB8ZRdiG8fx0i3oPVDPnNG9k3drOJG6dNdwbIhol+fjRhs6u8boLM1ZCFHGl7S2vKp
3AyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=date:message-id:mime-version:reply-to:to:from:dkim-signature
:subject:to:arc-authentication-results;
bh=MrgLc4ve1ORJFuf0aopHaOcjRXDQ8YmXq9esgbjEKik=;
b=rG9HE1d3/x5uB5d4PKk9IBG6YoQUltU4GksFoKgw849OU+sM4V5tJ13CuldShH8J9L
yaOwnZC9W04AhhyzwBCQ3L2H9M4BNWX+ROo7VKakCyxL91aiZMlxB6XwrrK9T4xTJIYk
OiAB9AzQawP49a/jdKD0rNZAAReOuRvfY/Mo8FzJ0rlAfbyNiu0z1CPLN6BqfE9Hf7n2
a2QGMMmq+B9Vm5a8pmq7xvFROEpiDe2jUndpfTZB3NoVNYYdk5sBPL698dz+RCFFRhtt
UnJWPUrFRcVPLbXrZrOMnhpXfaPiRE/P5UGFwahS0XsHpXvx2QHq02DSxe02jPrrWtt+
957Q==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=neutral (no key) header.i=#mydomain.com header.s=dkimpr header.b=QuXBPFmZ;
spf=pass (google.com: domain of noreply#mydomain.com designates 110.120.130.140 as permitted sender) smtp.mailfrom=noreply#mydomain.com
Return-Path: <noreply#mydomain.com>
Received: from ess007709 ([110.120.130.140])
by mx.google.com with ESMTPS id h16-v6si13954889pgb.39.2018.07.09.02.37.47
for <myemail#gmail.com>
(version=TLS1_2 cipher=AES128-SHA bits=128/128);
Mon, 09 Jul 2018 02:37:48 -0700 (PDT)
Received-SPF: pass (google.com: domain of noreply#mydomain.com designates 110.120.130.140 as permitted sender) client-ip=110.120.130.140;
Authentication-Results: mx.google.com;
dkim=neutral (no key) header.i=#mydomain.com header.s=dkimpr header.b=QuXBPFmZ;
spf=pass (google.com: domain of noreply#mydomain.com designates 110.120.130.140 as permitted sender) smtp.mailfrom=noreply#mydomain.com
Received: from www-data by ess007709 with local (Exim 4.80) (envelope-from <noreply#mydomain.com>) id 1fcSDJ-0006Ij-CQ; Mon, 09 Jul 2018 02:12:09 -0700
To: myemail#gmail.com
Subject: Welcome to MYWEBSITE
X-PHP-Originating-Script: 1001:test.html
DKIM-Signature: v=1; a=rsa; q=dns/txt; l=586; s=dkimpr; t=1531127529; c=relaxed/simple; h=From:To:Subject; d=mydomain.com; i=infonz#mydomain.com; z=From:=20"mydomain=20App"=20<noreply#mydomain.com> |To:=20myemail#gmail.com |Subject:=20Welcome=20to=20MYWEBSITE; bh=f1SBFzroobq/J+Xp4b+3SEctGQ40Fdi61QLOr3b+Joc=; b=QuXBPFmZGPUazSutggKZHSFxhc7WyIeshmT+Le1i+0n1aYq8B9lDKV9kgw5JdIOBwJvNuyYqHQ0FVDy+gti+FkVujXkzOfrbay4RjZ1Ti0tijJdsWrkSwzlJp9HO9CIbzpo6rcvRG6JoO76lkdhc35lmCfmlCsTfopIvNlHSMK+RoWp87+QIFINyqM0phTT1atSIJQWnMcKSLS54fMqlMjNXEgyN/Q53ZUDM+qIHDCk5eQskP6rGvxsEGIHZK4IgnTqb4uIgNWZNFlNr0f5z7j8PlUSzOLZrGC1r78i9DFrT128z35dOXXA7NV6TaS56jE+/uhLB1f0qfYdjnj4jCw==
From: mydomain App <noreply#mydomain.com>
To: myemail#gmail.com
Reply-To: noreply#mydomain.com
Content-Type: text/html; charset=utf-8
MIME-Version: 1.0
I did have some issues publishing my DNS TXT since my DNS host (NameCheap) has a limitation of 255 chars per TXT DNS record, I did so by publishing a CNAME instead pointing to a different host and hosting the TEXT record with a different provider. I believe it is resolving OK since when I try to validate the TXT record with DMARC DKIM analysis tool, I get the following OK result:
v=DKIM1; k=rsa; g=*; s=email; h=sha256; t=s;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2M+BcNJ0iDiEvfEY3oZ33gSpO7sjt
LyiNuyHNjT2KU1QWKaM8mKbYtwXjKqrG1vp4gLAPcbBI2rl2yGsxqJ+ml0ULTHYpjuGF5bMT9jh
/Dt/3bTTps4hbBrZPoaL9f6xDHu6LGEKgnqLEF/z+tpUte56xCFxz/b8zTYLn6srpQBsBTORjzq
8pkmfYGLfVJgw0+zZTZjQL4UXDqd3jmj/go4HCeij1UGoMkgp4zWzzCrJDuWbfPOPikaqZmhZk+
Je5I60pHn6Dlhp3v6awdGTWLb+51L0Y0QieLt3yM62Z4TeVembyUI6sEB+hb7DByK5GbS44sJxu
+AbnUJ4U5dhWwIDAQAB;
I tried heaps of things to resolve my error:
I tried to send k=rsa-sha256 instead of k=rsa, I got then a dkim=fail error (which at least shows that the DNS record is resolving?)
I tried to remove the l=... variable (the length of the encrypted body) and ended up with a dkim=neutral (no key) error.
I tried UTF encryption instead of base64 and also tried without binary packing - all failed.
I tried to play with the TXT record and publish some other versions like with or without escape characters before the ; - got the same results.
I tried to change the flag relaxed/relaxed to relaxed/simple (saw someone claiming it would work) - with no results.
ANY CLUES? I will appreciate any help! Cheers

dkim=neutral (no key) sounds to me as if the receiver cannot properly retrieve and parse your DKIM record. This aligns with your observation of the limitation of 255 chars at namecheap. I have had similar issues.
The most easy fix is to generate and use a shorter DKIM key fitting this limitation. If I remember correctly, the DKIM community offers such generator. Otherwise you can try to use a different DNS provider which supports longer TXT records.

You can break the long DKIM (public) record into multiple strings utilizing double quotes a space and another double quote.
Thus:
("part one" "part two" "etc")

OK so after a year and a half, I managed to resolve the issue by resetting my server. Problem was that I was trying to sign my emails in the php level with php mail, which was using exim4. The resolution I got was by setting up postfix server as an outgoing mail server, as explained in this guide. It is a long guide of 12 pages but going step by step is making it work well.
Stack used is Linux debian, the DKIM and SPF would work regardless of which backend mail you use (php, python, node.js etc)

Related

Problems with percent encoding and Azure BLOB DELETE?

Azure is returning 404 The specified blob does not exist when it does, I can browse to the file concerned without problems. Indeed, the file path is generated by my script from a prior call to https://${vault}.blob.core.windows.net/${container}?restype=container&comp=list, therefore the BLOB absolutely 110% exists !
However a DELETE call returns 404 (you can see my header construction below, along with the Azure response) :
S:DELETE
x-ms-date:Tue, 09 May 2017 17:22:27 GMT
x-ms-version:2016-05-31
/myaccount/mycontainer/path/to/my/dir/Some%20File%20B_Foo_Bar%20Dev_1234.docm
S:EBHf8ElRGrAiYAbLTtYa9SqWFJ2eg7F0bebRNGTlLac=
404 The specified blob does not exist.
Date: Tue, 09 May 2017 17:22:22 GMT
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
Content-Length: 215
Content-Type: application/xml
Client-Date: Tue, 09 May 2017 17:22:39 GMT
Client-Peer: 191.235.193.40:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2
Client-SSL-Cert-Subject: /CN=*.blob.core.windows.net
Client-SSL-Cipher: ECDHE-RSA-AES256-SHA384
Client-SSL-Socket-Class: IO::Socket::SSL
X-Ms-Request-Id: 5b3ddd1c-0001-00c1-10e8-c80c81000000
X-Ms-Version: 2016-05-31
I am using a Perl script (the script goes through the XML from the container/list API and deletes stuff older than X ) , consuming the API directly, relevant part is :
for my $data ( $twig->findnodes("//Blob[Properties/Last-Modified < ${then}]")) {
### SEND DELETES
my $filNam=$data->field("Name");
$hdrs = "/${vault}/${container}/${filNam}";
my $delURL="https://${vault}.blob.core.windows.net/${container}/$filNam";
if ($debug) {
say "DelURL: ".$delURL;
}
if (!$nodelete) {
doHTTP("DELETE",$delURL,
$hdrs,
encode('UTF-8',"DELETE\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:${tNow}\nx-ms-version:${azureVersion}\n${hdrs}",Encode::FB_CROAK)
);
}
}
FYI, its not my code, I get the same error if I use Microsoft's NPM client (i.e. azure -vv storage blob delete data .....)
I think I might have found the answer.
Seems like a bit of "feature" (a.k.a. bug).
Looks like percent stuff needs to be prefixed with 25 (e.g. %20 becomes %2520).
https://blogs.msdn.microsoft.com/windowsazurestorage/2012/05/28/character-encoding-issues-related-to-copy-blob-api/

Microsoft-Cognitive text translation works inaccurate

I'm using the translator api of microsoft azure and it works inaccurate.
In my example I translate form english to german:
The first picture shows correct translations except for "apple" which should be "Apfel" in german, also the second image shows another mistake as "pepino" is in German a "Birnenmelone", also dict.leo.org knows this.
Does anyone has an idea how to increase the accuracy of the service or how to change the input to get a better output?
Update: I thought also context count, so i simply used articles and also try to even give the context of "XYZ is a fruit". This made the results just a little better so that around 50% of the feedback is right now.
The Translator API is not intended to be a dictionary lookup, but rather a translation of natural language where context can help determine the translation. If you are just searching for a single word then the Translation API will generally return the most commonly used form of that word within the training data, which for "apple" would be the company Apple.
Alternatively, instead of calling the Translate API, you can call the GetTranslations API (or GetTranslationsArray) and pass in the optional <options> body with <IncludeMultipleMTAlternatives>true</IncludeMultipleMTAlternatives> to get multiple alternative translations. This is documented at https://msdn.microsoft.com/en-us/library/dn887253.aspx and we are working to get it into the Azure Cognitive Services documentation as well.
Example:
REQUEST
POST https://api.microsofttranslator.com/v2/Http.svc/GetTranslations?text=apple&from=en&to=de&maxTranslations=5 HTTP/1.1
User-Agent: Fiddler
Authorization: Bearer xxx
Host: api.microsofttranslator.com
Content-Length: 325
Expect: 100-continue
Content-Type: text/xml
<TranslateOptions xmlns="http://schemas.datacontract.org/2004/07/Microsoft.MT.Web.Service.V2"><Category>general</Category><ContentType>text/plain</ContentType><IncludeMultipleMTAlternatives>true</IncludeMultipleMTAlternatives><ReservedFlags></ReservedFlags><State></State><Uri></Uri><User>TestUserId</User></TranslateOptions>
RESPONSE
HTTP/1.1 200 OK Content-Length: 553 Content-Type: application/xml; charset=utf-8 X-MS-Trans-Info: 0639.V2_Rest.GetTranslations.491248A8 Date: Fri, 28 Apr 2017 20:55:44 GMT
<GetTranslationsResponse xmlns="http://schemas.datacontract.org/2004/07/Microsoft.MT.Web.Service.V2" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><From>en</From><State/><Translations><TranslationMatch><Count>0</Count><MatchDegree>100</MatchDegree><MatchedOriginalText/><Rating>5</Rating><TranslatedText>Apple</TranslatedText></TranslationMatch><TranslationMatch><Count>0</Count><MatchDegree>100</MatchDegree><MatchedOriginalText/><Rating>0</Rating><TranslatedText>Apfel</TranslatedText></TranslationMatch></Translations></GetTranslationsResponse>

Postfix and save to sent mail dir

I know this might be a dummy question or a question that comes from lack of knowledge, but I hope someone can still answer it. I did try to read a lot of Postfix documentation but found no answer to this. I don't even know if it's a Postfix specific or mail servers general question.
So I have a mail server, just a clean Postfix install that delivers email.
I've defined my users and connected with IMAP and SMTP using Thunderbird.
When I went to Thunderbird account settings and disabled "place a copy", Postfix did not put a copy of the sent message in the user .Sent folder.
However, I've also connected my Gmail, Hotmail or Yahoo mail and disabled the "place a copy" and still have a copy in the sent items folder.
So in this case there are 2 options:
Something is wrong with my Postfix configuration
Gmail, Hotmail, Yahoo put a copy in their sent folder as a different process on the server side
Just for the record, having searched around for a how to, and not finding one, I am posting it here:
The only (easy) way I've found to save sent emails is the sender_bcc solution (with it's attendant faults):
I am using postfix / dovecot / sieve / mysql virtual boxes
In /etc/postfix/main.cf add:
sender_bcc_maps = mysql:/etc/postfix/mysql-virtual-bcc-maps.cf
Create file /etc/postfix/mysql-virtual-bcc-maps.cf:
user = (database user)
password = (database password)
hosts = 127.0.0.1
dbname = (database databasename)
query = SELECT CONCAT_WS('',LEFT('%s', LOCATE('#', '%s')-1),'+sent#',SUBSTRING('%s', LOCATE('#', '%s')+1)) AS destination FROM virtual_users WHERE email='%s' AND autosent=1
You'll note in my query, I've added a (tinyint default 0) column to my virtual_users table so I can turn on/off this automatic sent items feature per user. This query takes the sender email address that postfix gives it, splits it in half at the # sign, and adds +sent to the address so it looks like sender+sent#domain.tld. This allows sieve in the next step to pick it up and drop it straight to sent items.
In /etc/dovecot/sieve/default.sieve add:
require ["fileinto", "mailbox", "envelope", "subaddress","imap4flags"];
if envelope :detail "to" "sent" {
addflag "\\Seen";
fileinto :create "Sent";
stop;
}
Also helpful to modify /etc/dovecot/conf.d/15-mailboxes.conf and add the auto subscribe to sent (and junk and trash and others for that matter):
mailbox Sent {
special_use = \Sent
auto = subscribe
}
I think that is all (I'm posting this the next day after doing it, so I think I got it all...)
Postfix itself does not place copies of sent messages anywhere; it receives messages and delivers them to the recipient. Saving sent messages to your own mailbox is the responsibility of your user agent (Thunderbird, in your case).
It's important to understand that Postfix (and other traditional Unix SMTP servers) don't have a "user" concept. Yes, if so configured it's possible to authenticate by supplying a username and a password, but Postfix doesn't use this identity information.
That said, it's not impossible to configure Postfix to do what you expected – sender_bcc_maps can be used to add a recipient to messages sent by you, and by adding yourself and using a filter in your mail client (or mail delivery agent like procmail) you can make sure that messages sent by you end up in the Sent folder.
I am running a Installation with automatic copies created by sender_bcc_maps. It's working fine. You have to check the sender, otherwise everyone can create sent mails in foreign sent folders.
I have solved it with two virtual domains. One for the user and one for the copy.
But there is a big problem with sender_bcc_maps. All bcc senders will be deleted in the sent copy. You cannot see anymore, who got a blind copy of this mail.
As 'ego2dot0' said above, you don't need any MDA filters (sieve etc.) to do this. It can be done using Postfix alone, although it took me a while to figure out how to do it.
You have to use sender_bcc_maps AND virtual_mailbox_maps features together.
You have to use a virtual domain dedicated specially for copies to self. If your actual domain is "your.domain.tld", you can use eg. subdomain "copyself.your.domain.tld". This subdomain does not have to actually exist, ie. be defined in the DNS (moreover, it's better that it isn't defined, so nobody accidentally sends mail to it from outside). It is a purely virtual domain that is recognized only by Postfix.
1) Configure sender_bcc_maps to BCC mail coming from user#your.domain.tld to user#copyself.your.domain.tld. You can do it for only a few selected users using a regular "hash" type map, or you can do it for all users at once using PCRE type map and regular expressions.
2) You have to define your virtual domain in virtual_mailbox_domains, like this:
virtual_mailbox_domains=copyself.your.domain.tld
3) Configure virtual_mailbox_maps so that the destination mailbox for address "user#copyself.your.domain.tld" is the actual "Sent" mailbox of the user "user". For example (assumed that you are using regular system users and Maildir format - like in my case) the path to "Sent" mailbox for user "user" will be "/home/user/Maildir/.Sent". So, you can define common part of the path as virtual_mailbox_base, eg.
virtual_mailbox_base=/home
and then in the virtual mailbox map enter the rest of the path like this:
user#copyself.your.domain.tld user/Maildir/.Sent/
(the trailing / is important to indicate the Maildir format).
Again, you can use PCRE type map to do this for all users.
4) To properly save mail to the mailbox, Postfix need to also know the proper UID and GID for the particular user, so you have to use virtual_uid_maps and virtual_gid_maps parameters as well. If you are using virtual users, it's probably enough to define "static" type maps specifying a single UID and GID of the system user that owns all the virtual mailboxes. However, if you are using system users like me, you need the proper actual UID and GID for any user. If you have only a few users, you can use a regular "hash" type map, with entries like these:
user#copyself.your.domain.tld 2001
or you can try to setup a pipeline with "pipemap" map type, that uses some PCRE maps and "unix:passwd.byname" map to obtain the UIDs and GIDs for all users (I haven't done this part, as my Postfix installation is compiled without "pipemap" type support).
So to sum everything up, use something like this:
In /etc/postfix/main.cf file, add the following lines:
sender_bcc_maps=hash:/etc/postfix/sender_bcc
virtual_mailbox_domains=copyself.your.domain.tld
virtual_mailbox_base=/home
virtual_mailbox_maps=hash:/etc/postfix/copyself
virtual_uid_maps=hash:/etc/postfix/copyself_uids
virtual_gid_maps=hash:/etc/postfix/copyself_gids
/etc/postfix/sender_bcc contains a bunch of lines like:
user#your.domain.tld user#copyself.your.domain.tld
/etc/postfix/copyself contains - respectively - lines like:
user#copyself.your.domain.tld user/Maildir/.Sent/
/etc/postfix/copyself_uids and /etc/postfix/copyself_gids contain - respectively - lines like:
user#copyself.your.domain.tld 2001
I have done this on my server and it works great for me.

Using filter for return-path

I am getting mail where "From" and "Reply-to" are different than "Return-Path", "Received from" as shown in this example.
How do I set filter for such mail?
Return-Path: <cybersho#bhasha.interpole.net>
Received: from bhasha.interpole.net (bhasha.interpole.net.
Received: from cybersho by bhasha.interpole.net with local (Exim 4.77)
(envelope-from <cybersho#bhasha.interpole.net>)
From: "Gadima.com" <books#gadima.com>
Reply-to: "Gadima.com" <books#gadima.com>
It doesn't seem to be possible in Gmail, unfortunately.
I fell back to my email client, Gnus (because of its amazing flexibility and lightness) to do this. The details are explained in the "6.3.3 Client-Side IMAP Splitting" section of its manual.
It was surprisingly easy. In my ".gnus.el" file, I put (I'm using the nnimap backend for Gmail) something like this:
(setq nnimap-split-methods
'(("mail-list-folder" "Return-Path: mail-list-address")
("INBOX" ""))
You'd need to adapt your "mail-list-folder" (label) and "Return-Path: mail-list-address" parts accordingly. The string containing "Return-Path: ..." is a regexp so can you can use wildcards such as .* and even groups. For example, to filter some lists I'm subscribed to, I have:
(setq nnimap-split-methods
'(("list.\\1" "^Return-Path: <\\(.*\\)-bounces.*#gnu.org>")
("INBOX" ""))
Notice the capture group, \\(.*\\) which is used to form my label, as well as the adaptations required to match the Return-Path as formed by the mailing list program.
If you'd like to try it out I can suggest the following wiki to get started: https://www.emacswiki.org/emacs/GnusGmail.

DNS query function that differentiates between not existing host and network error

getaddrinfo() returns EAI_NONAME for both network error when resolving an existing host and a non existing host.
What should I do to be able to differentiate between those two errors?
Because when the host does not exist I want to fail and when there is a network error I want to continue trying to resolve.
With classic DNS you can't do this. To the end resolver you really can't distinguish between whether a host exists or whether there was a network failure.
However, with DNSSEC you actually can (assuming the zone was securely signed). You'll need a validating library that can do this for you, and it'll still fail to give you accurate results for unsigned zones (which are unfortunately many in number). But for signed ones you'll get different results depending on whether the name existed or whether there was a network failure. DNSSEC contains a number of records that are used to prove something doesn't exist.
As an example, the libval library that comes from The DNSSEC-Tools Project has a val_getaddrinfo() that will tell you whether the result was validated or not. If no answer existed and it was validated then you can trust that it really doesn't exist. There is a sample getaddr command line application that can be used to test the results as well as study the code.
stackoverflow.com is, sadly, unsigned:
# getaddr wwwxxx.stackoverflow.com
Return code = -2
Validator status code = 134 (VAL_NONEXISTENT_NAME_NOCHAIN)
Error in val_getaddrinfo(): -2
And the error code indicates that (the "nochain" part). That could have failed either because it didn't exist or because the network had issues.
But for signed zones, you'll get a better response:
# getaddr wwwxxx.dnssec-tools.org
Return code = -2
Validator status code = 132 (VAL_NONEXISTENT_NAME)
Error in val_getaddrinfo(): -2
Here the validator status changed and we can be sure the address really didn't exist.
Note that .com, .org and .net are all signed, which means you can always determine if a given something.com exists (but maybe not subname.something.com).
There are other libraries that provide DNSSEC support as well, but I'm most familiar with libval, which is why I used it above.
The DNS is actually quite complex to fully understand how and why it works, and even more so when you add the secured version of it. There isn't a simple reference to an answer, but you need to read at least RFCs 1034 and 1035 and understand the RCODE #3, which is NXDOMAIN and realize it's returned by a resolver that you're querying through and there is no other answer tha the resolver is allowed to give you.
If you want starting points for reading, you can check out:
RFC1034 Domain names - concepts and facilities. P.V. Mockapetris. November 1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936) (Also STD0013) (Status: STANDARD)
RFC1035 Domain names - implementation and specification. P.V. Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035, RFC4343, RFC5936, RFC5966) (Also STD0013) (Status: STANDARD)
RFC4033 DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=52445 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC6014) (Status: PROPOSED STANDARD)
RFC4034 Resource Records for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=63879 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470, RFC6014) (Status: PROPOSED STANDARD)
RFC4035 Protocol Modifications for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=130589 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470, RFC6014) (Status: PROPOSED STANDARD)
RFC5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, G. Sisson, R. Arends, D. Blacka. March 2008. (Format: TXT=112338 bytes) (Status: PROPOSED STANDARD)
I found out that http://c-ares.haxx.se/ is able to differentiate between ARES_ETIMEOUT and ARES_ENOTFOUND unlike getaddrinfo()

Resources