TLSA RRset IPv4 HTTPs SMTPs - Interrogation

Support Debian
,
Tags: #<Tag:0x00007fb42a120d50> #<Tag:0x00007fb42a120580>
#1

Bonjour,

Comme tout les administrateurs le savent, chez nos hébergeurs de serveurs dédiés nous ne pouvons pas gérer le reverse de l’adresse IPv4 depuis un serveurs DNS interne à la machine.

Cela pause problème :

  • pour le reverse DNS de l’IPv4 (on ne peut qu’assigner un seul nom de serveur (d’IPv4), via l’interface de gestion).
  • pour l’association DANE entre le nom de domaine et le certificat TLS - J’ai un doute, justement la dessus.

Exemple Website test: zw3b.eu :
Screenshot 2023-11-18 at 16-03-11 Website test zw3b.eu

Je ne sais pas comment « internet.nl » me retourne cela : DANE existence → DANE TLSA record existance sur l’IPv4), mais bon - Auriez-t’il un soucis d’interrogation ?

Puisque à ce que je sais, on interroge un enregistrement de ressource DANE par rapport au certificat TLS et du (associé au) protocole HTTPs (site web) et nom, entité comme cela :

$ host -t TLSA _443._tcp.zw3b.eu
_443._tcp.zw3b.eu has TLSA record 3 0 1 98000A3E3FF9111437F3890484A8B0637C74549D848B01DBD935FA36 C30B6C61

Certes les RRset « zw3b.eu » sont configurés avec un enregistrement IPv4 et IPv6.

$ host zw3b.eu
zw3b.eu has address 158.69.126.137
zw3b.eu has IPv6 address 2607:5300:60:9389::1
zw3b.eu mail is handled by 10 smtp.zw3b.eu.

Que pensez-vous de çà - Auriez-t’il une erreur d’interrogation côté « internet.nl » ; test website ?

PS : Je vois qu’il y a écris « not tested » → parce s’ils chercheraient à trouver le rDNS de l’IPv4 (qui retournerait, donc, « mail.zw3b.eu ») et puis sa signature - il tomberaient sur un autre certificats TLS celui de « mail.zw3b.eu »).

Je vous ajoute ces informations (ma zone rDNS de mon l’IPv4 - que personne ne peut interroger depuis l’internet, à part avoir mon DNS dans son resolv.conf) :

$ dig -x 158.69.126.137 +short @my_dns_lan
mail.zw3b.fr.
zw3b.blog.
ipv01.net.
mail.zw3b.blog.
ipv10.net.
zw3b.net.
lab3w.com.
zw3b.tv.
mail.lab3w.com.
zw3b.fr.
mail.ipv10.net.
lab3w.fr.
mail.lab3w.fr.
mail.ipv01.net.
mail.zw3b.site.
zw3b.site.
mail.zw3b.tv.
mail.zw3b.net.

Ce que vois l’internet, le rDNS de mon IPv4 (configuré dans le panel de mon hébergeur) :

$ dig -x 158.69.126.137 +short @dns.google
mail.zw3b.eu.

Et pourtant même l’IPv6 (principal) pointe sur un autre nom :

$ dig -x 2607:5300:60:9389::1 +short @dns.google
wan.ipv10.net.

$ dig -x 2607:5300:60:9389::1 +short @my_dns_lan
wan.ipv10.net.

Mon DNS : « my_dns_lan » c’est celui-ci : « dns.ipv10.net » :wink:

Donc, comme je l’expliquais, ci-dessus, çà doit être une erreur d’interrogation TLSA.

Note de Moi-même : Bon Ok, mesdames, messieurs, j’ai une erreur dans l’ordre des préférences algorithmiques TLS - je n’ai pas activé HSTS (redirection HTTPS obligatoire pour le client), et n’ai pas de politique de sécurité sur mes contenus (je suis tout seul à bosser sur les sites web - tout va bien).

Bonne journée, bon weekend à vous.

Salutations,
Romain

DANE : DNS-based Authentication of Named Entities.
TLSA : Transport Layer Security Authentification.
PTR : PoinTer Records or Reverse DNS records.
SNI : Server Name Indicator

Gateway/Proxy/Cluster -> 2 servers Mail
#2

C’est normal, c’est la norme DNS, un seul PTR par adresse IP.

#3

Source ?

Parce que de chez vous, vous pouvez voir cela (c’est une de « mes » IPv6).

WEB Servers :

$ host 2607:5300:60:9389:15:1:a:10
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.fr.
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.site.
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.blog.
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.net.
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.tv.
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.eu.
0.1.0.0.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer w1a.zw3b.com.

$ host 2607:5300:60:9389:15:2:a:10
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.blog.
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.site.
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.eu.
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.tv.
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.net.
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.com.
0.1.0.0.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ww2.zw3b.fr.

NS servers :

$ host 2607:5300:60:9389:15:1:a:1000
0.0.0.1.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ns1.ipv01.net.
0.0.0.1.a.0.0.0.1.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ns1.ipv10.net.

$ host 2607:5300:60:9389:15:2:a:1000
0.0.0.1.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ns2.ipv01.net.
0.0.0.1.a.0.0.0.2.0.0.0.5.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ns2.ipv10.net.

:wink:

#4

La RFC 1035 bonne lecture.

#5

@Zargos, il y a plusieurs RFC depuis les milles premières… faut suivre :wink: :rofl: :blush: - depuis 1987 du RFC :crazy_face: je plaisante - « bise » à vous, monsieur, madame !

RFC 2181 : Clarifications to the DNS Specification → Enregistrements PTR (July 1997)

La confusion au sujet des noms canoniques a conduit à croire qu’un enregistrement PTR devrait avoir exactement un RR dans son RRSet. C’est incorrect, la section pertinente de la RFC1034 (section 3.6.2) indique que la valeur d’un enregistrement PTR doit être un nom canonique. Autrement dit, il ne devrait pas s’agir d’un pseudonyme. Rien dans cet article n’implique qu’un seul enregistrement PTR soit autorisé pour un nom. Aucune restriction de ce type ne devrait être déduite.

Notez que même si la valeur d’un enregistrement PTR ne doit pas être un alias, il n’est pas obligatoire que le processus de résolution d’un enregistrement PTR ne rencontre aucun alias. L’étiquette recherchée pour une valeur PTR peut avoir un enregistrement CNAME. Autrement dit, il pourrait s’agir d’un pseudonyme. La valeur de ce RR CNAME, sinon un autre alias, ce qui ne devrait pas être le cas, donnera l’emplacement où se trouve l’enregistrement PTR. Cet enregistrement donne le résultat de la recherche du type PTR. Ce résultat final, la valeur du RR PTR, est le label qui ne doit pas être un alias.

Salutations,
Romain

#6

Essaye de faire joujou sur internet avec des PTR dont l’IP pointe sur plusieurs nom, sans compter les certificats et je te souhaite bon courage.
Car il y a l’implémentation au delà de la RFC.

#7

çà va bien de mon côté :slight_smile:

par exemple : SSL Server Test: smtp.zw3b.eu (Powered by Qualys SSL Labs)

Screenshot 2023-11-18 at 17-29-48 SSL Server Test smtp.zw3b.eu (Powered by Qualys SSL Labs)

¿ des G.A.F.A.M → Google Apple Facebook Amazon Microsoft ?

#8

Bon qui pourrait « instruire » les commerciaux de l’Internet.

Par exemple sur mon serveur mail « mail.my_server.com » je suis bloqué, je ne peut pas configurer les noms des hosts de mes clients, je suis obligé de mettre mon smtp (global), le du serveur.

Je ne peut pas leur assigner leur nom de domaine.

smtp.client1.com (certif TLS et rDNS IPv4) correspondant
smtp.client2.com (certif TLS et rDNS IPv4) correspondant.

Je ne vais pas acheter/louer une IPv4 par client qui pointerait (en plus) sur la même machine.

J’ajoute que sur UNE IPV4, j’ai « généralement » un bloc IPv6::/64 de plus, bien plus d’un million d’adresses IPv6.

Il serait tout a fait normal de pouvoir configurer plusieurs rDNS sur l’IPv4 et selon le SNI (Server Name Indicateur), je pourrais alors configurer DANE (TLSA), le certificat des protocoles SMTPs, IMAPs, POP3s…

Parce que là çà fait moche → T’as un mail monmail@undomain.com et quand t’essaies de configurer dans ton logiciel client, il te sort le certificat de l’hébergeur…

Je ne vais pas ajouter au certificat du serveur global, les noms des domaines des clients, en subjectAltName, çà serait bizarre.

C’n’est pas très « users friends ».

NdMoi-même : pour les webmails tout va bien grâce au reverse proxy web.

Romain

PS : Je vais passer le mot sur un forum américain et mail.

Parlez de ça entre vous s’il vous plaît - cela le semble important !

Sportivement :wink:

J’aime bien ma marque, mais bon.
Sinon, ils font tous çà les hébergeurs mails ; les mecs qui payent un services domaine/mail chez Google configurent le smtp de google :rofl::face_with_raised_eyebrow: C’est « ouf ».

PS : Le titre du sujet - être connaisseur.

#9

Test mail lab3w.fr (Internet.nl) - 97%

Screenshot_2023-11-30-16-47-32-79_40deb401b9ffe8e1df2f1cc5ba480b12

Sur ssllabs.com c’est mauvais → mail.lab3w.fr
par contre mail.zw3b.eu c’est OK !

Il manque juste ce petit truc les gars, ISP, mes Seigneurs, nos Seigneurs.

Juste çà :wink::blush:

Sur lab3w.com c’est bon (100% valid, conform, security) parce que j’ai configuré le MX sur le smtp.ISP.net

#10

J’ai peut-être une solution : HA-proxy.

Cà m’a fait penser à (et si je pouvais tester une 2ème solution mail, ce serait de la bombe)

:wink:

Bonne appétit !