Reprise du message précédent :

 
Un impact ? Sûrement. Je n'ai pas fait le nécessaire pour mesurer l'impact. Mais comme le dit XaT en dessous, c'est "du bon sens" car donner plus de sockets à ta VM que ce qu'a le serveur physique, à un moment ça coince Et sur le client lourd vSphere, on pouvait choisir le nombre de sockets/cores mais sur la version Web on met uniquement le nombre de cœur et ça laisse le socket à 1 afin d'éviter des imbalance si on se goure dans les cases
 

 
Finalement après lecture oui, tout se bon sens se ramène à de l'infra pure et les limites physiques des machines

NUMA ça date et c'est écrit dans les manuels de mobo multicpu.
Perso je préfère du monoCPU pour pas se faire chier avec ça

Bon ca casse du dns ses morts?

?

Post de qualité, thanks Merci pour les liens à côté aussi, l'explication des champs d'esxtop pertinents dans le cadre d'un troubleshooting c'est bien cool

Tous mes domaines sont protégés par dnssec depuis longtemps, m'en tape !

Ya un truc en cours à part cette fausse vraie alerte de l'ICANN ?  
 
https://www.lemonde.fr/pixels/artic [...] 08996.html

J'ai juste vu des tas d'articles sans trop lire. En gros, fake news  

Vous avez un peu de doc sympa sur LACP ? Notamment sur le choix de l'algo (src/dst ip/mac)

Sur du EPYC 1 socket ta du NUMA...

 
Je pensais que c'était virtuel ce concept et que c'était juste ce que présentait la VM à l'OS.  

A un moment t'a quand même des CPU physiques qui doivent adresser de la mémoire physique
Et si tu fait du SR-IOV ça rajoute encore du bordel

Du NUMA hors SMP ? J'connaissais pas. M'enfin EPYC j'en vois pas passer, pas de soucis

 
Ouais enfin je vais faire mon dev de base mais le truc propose de faire des configurations suboptimales en mode YOLO à un béotien
En général quand ça a un vrai impact, que c'est facile de faire de la merde, ça se met dans un sous menu de sous menu sous "advanced settings" pas dans le 3ème écran entre la sélection de l'OS et l'affectation de l'adresse réseau.

Voui et non.
 
Spa pour rien quand même que c'est un métier sysadmin

Boarf 3 clics

Oui je charriais. Après c'est quand même facilement trouvable sur les Internets

Pour l'avoir fait de nombreuses fois, non ça monte aussi le cpu socket si on se contente d'utiliser le menu d'ajout de vcpu par defaut.
il faut tjrs aller verifier dans les options avancées que c'est bien des cores et non des socket qu'il a ajouté.
et comme Bmenez, j'ai lu ça et là que ça n'importait peu, c'etait surtout important pr l'OS invité et des softs dependant du nombre de cpu pr leurs licences.
 
en tt cas merci pr ton retour, je vais aller lire les liens donnés en detail.

 
Spa pour rien si je suis aigri

Du généraliste non.

 
https://www.01net.com/actualites/mo [...] 39872.html
 

Peut-être en sais-tu plus que lui ?

https://www.youtube.com/watch?v=mrXtwcGkroI

Je ne vais pas voir les liens vidéos.

Par contre, je réagis à l'article du Monde qui était au-dessus sur cette page et cité par caudacien :

Du coup, qui dit vrai ? C'est un fake ou pas ?

l'ICANN fait sa pub comme elle peut pour pousser DNSSEC, et il ne s'est rien passé de spécial.

La plupart des admins sont en mode :

C'est comme IPv6, ça sert à rien.

toujours d'actualité https://sockpuppet.org/blog/2015/01/15/against-dnssec/
 

J'ai du mal à être convaincu que DANE est dans l'absolu un mauvais remplacement au système de CA actuel.
Après une fois mis en balance avec l'effort à fournir pour déployer DNSSec je ne sais pas.

  je quote , je n'avais pas un aussi bon resumé  

 
Du coup, je comprends pas la réaction de Poly Notre secrétaire d'Etat s'est officiellement planté en beauté non ?

c'est son boulot

Le ministre de la cybersécurité du japon a quand même placé la barre à 9000+  
http://www.lefigaro.fr/secteur/hig [...] sa-vie.php  

repost

Of course, c'était pour illustrer

Techniquement pas d'ordinateur pas de hacking  
Level de sécurité supra supérieur  
Tu peux pas test    

 
Les arguments sont toujours aussi spécieux
 
 
 
Tu es victime d'un biais d'attribution

Pourquoi ?

 
Les auteurs n'ont pas compris quelle menace essaie de contrer DNSSEC (ou s'ils ont compris, ils ne le montrent pas )
J'admets que DNSSEC n'est pas l'Alpha et l'Oméga de la sécurité et comme souvent à l'IETF, c'est sur-conçu.
DNSSEC essaie de rendre difficile l'injection de réponses DNS mensongères.
 
C'est sûr que si ton analyse de risque révèle que ton problème c'est la confidentialité, DNSSEC ne fait pas partie des solutions.
Également, quand on n'écrit pas uniquement pour polémiquer, on propose des choses
 
Plus en détails (avec de vrais morceaux d'attaque ad hominem ) :

Le mec cherche une solution efficace à 100% pour... un problème non clairement défini. Ok, ça commence bien.
Rappel : DNSSEC ne cherche pas à résoudre le problèmes des services troués.
 

Voilà, voilà. Encore une fois, DNSSEC ne cherche pas à sécuriser SMTP.
 
Je suis d'accord avec eux, vu sous cet angle DNSSEC est inutile.
 
Je suis aussi d'accord avec "DNSSEC is a Government-Controlled PKI" même si je n'aurai pas utilisé "Government-Controlled" (les auteurs sont américains donc c'est culturel) mais "Thirdparty-Controlled".
C'est comme les autorités de certification en fait.
 

L'article date de 2015, depuis on a fait des progrès (grâce à ce genre d'article, il faut le reconnaitre) et ECDSA est disponible.
 

Ben ouais... Mais c'est comme IPv6, personne ne veut y'aller parce que ce n'est pas au niveau d'IPv4, parce que personne n'y va, parce que...
Une belle attitude attentiste, c'est sûr que quand on ne fait rien, quand on ne propose rien, on peut se permettre de critiquer ceux qui essaient d'avancer.
 

N'en jeter plus, la coupe est pleine. Dans le top 5 des non-arguments. Le changement coûte plus cher (à court terme) que de ne rien faire.
Les auteurs parlent de TLS en long et en large comme le summum de la sécurité mais ils oublient que l'adoption de TLS ne l'a pas été à coût nul.
Ils peuvent cependant estimer que le coût est trop élevé par rapport au gain dans leur cas d'étude, ce qui n'en fait pas une vérité absolue.
 

Autrement dit, on fait de la merde avec SSL/TLS depuis des années donc on va continuer. Si la requête DNS échoue, c'est qu'il y'a un soucis et quand il y'a un problème, on l'étudie et on le résout.
 

Ok. C'est un problème de pionnier ça mais pas un argument contre DNSSEC.
 

Si le resolveur DNS est sur ma machine, la surface d'attaque est limitée. Si un attaquant est déjà dans ce périmètre, c'est "game over" même pour TLS.
 

2015, depuis ça a évolué.
 

Qui sont ?
 
La conclusion rejoint le début, DNSSEC répond à un problème spécifique, bien délimité. Les auteurs essaient de l'appliquer à un autre espace de problèmes et ça ne fonctionne pas. (sans blague ?)
J'admets que DNSSEC n'est pas simple mais en attendant mieux, ça fait ce que ça doit faire
 
PS: On retrouve le même genre de discours avec RPKI-ROA.

 
J'avoue que DNSSEC je m'en tamponne, mais ca:
 

 
N'a rien a voir avec SMTP...
 

 
Ca sent le sapin, même ipv6 eu des mise en prod dans ses premières heures...
 

 
Quand tu vois TLS et la vitesse de progression dans les foyers, je lis que DNSSEC besoin d'etre deploy sur serveur et client, on en reparle dans 20 ans donc...

Les CA https://groups.google.com/forum/#!m [...] 83uQA5AAAJ

+1, ca existe historiquement pour éviter que des clients de vmware ne perdent trop d'argent lors du p2v à cause des licences.
Par contre rajouter des vcpu pour augmenter les perfs cpu d'une vm, c'est une très mauvaise idée très répandue oui.