کتاب همه چیز درباره بیت کوین https://www.dropbox.com/s/0pn1c6d63wt36s2/Hame.Chiz.Darbareye.Bitcoin_%40unixmens.pdf?dl=0 #bitcoin @unixmens

با سلام خدمت تمامی ویرایشگران نقشه OSM در ایران
از همه‌ی دوستانی که علاقمند هستند تا مشارکت بیشتری در پروژه OSM Iran داشته باشند دعوت به همکاری به عنوان نویسنده در وب‌سایت و کانال گروه می‌کنیم.
تمامی عزیزانی که با پیمان نحوه‌ی برخورد با مشارکت‌کننده و مدیران موافقت کنند و با ایجاد یک پست در انجمن ویرایشگران OSM ایران بخش گروه های کاری آن را کتباً به اطلاع تمام اعضا برسانند می‌توانند یکی از نویسندگان وبسایت یا کانال OSM Iran باشند
با تشکر OSM Iran

#security @unixmens

ششمین نمایشگاه تخصصی پدافند سایبری
زمان: ۱۸ تا ۲۱ ابان ماه ۹۸
مکان: نمایشگاه بین المللی تهران (آدرس ) مختصات : 35.78954, 51.39962
#security @unixmens

دیتاسنتر یا مرکز داده‌، ساختمانی است که برق، فضا و سرمایش لازم برای نگهداری از سرورهای یک کسب‌وکار را فراهم می‌کند. تداوم عملیات یک کسب‌وکارها به میزان پایداری مرکز داده‌ای که سرورها در آن نگهداری می‌شود‌ بستگی دارد، کسب‌وکارها باید اطمینان حاصل کنند که فعالیت‌های روزمره آن‌ها به دلیل قطعی سرورها مختل نخواهد شد. درنتیجه، امنیت و پایداری مراکز داده برای هر کسب‌وکار یکی از اولویت‌های اصلی است.

با این ضرورت در این نوشته سعی کردیم انواع مراکز داده را تشریح کنیم تا کسب‌وکارها بتوانند از بین گزینه‌های موجود بهترین سرویس را انتخاب نمایند.



نوع اول- Hyperscale Data Center

کلمه‌ی Hyperscale به ترکیب کاملی از سخت‌افزار و تسهیلاتی اشاره دارد که می‌توانند در یک محیط توزیع شوند و امکانات لازم برای تگهداری تا هزاران سرور را شامل شود. مانند دیتاسنتر شرکت‌هایی مانند، مایکروسافت، گوگل و اپل. برای مثال مرکز داده‌ی شیکاگوی مایکروسافت یکی از بزرگ‌ترین Data Center های دنیا محسوب می‌شود که ۶۵ هزار مترمربع مساحت دارد و میزبان حدود یک میلیون سرور است که در واحدهای ۱۵۰۰ تا ۲۵۰۰ تایی دسته‌بندی‌شده‌اند.

ا Hyperscale Data Center پایداری و مقیاس‌پذیری را به افراد و یا کسب‌وکارها ارائه می‌دهد و تفاوت این مرکز داده با دیگر مراکز داده اتصال به یک شبکه پرسرعت و پهنای باند بالا است.



نوع دوم- Colocation Data Center

کولوکیشن سرویسی است که ارائه‌دهنده سرویس، فضا، برق و امکانات سرمایشی را برای کسب‌وکارهای متعدد در یک مکان خاص فراهم می‌کند. سرویس کولوکیشن این امکان را برای شرکت‌ها فراهم می‌کند تا تجارت خود را با کم‌ترین پیچیدگی و هزینه توسعه دهند. مزیت اصلی انتخاب این سرویس برای میزبانی از سرورها این است که تجهیزات نگهداری از سرورها داری بالاترین حد استاندارها و با ویژگی‌های عالی هستند تا زیرساخت‌های میزبانی را ایمن و قابل‌اعتماد نگه‌دارند. همچنین وظیفه‌ی نگهداری از سرورها بر عهده‌ی ارائه‌دهنده این سرویس است و کسب‌وکار هیچ‌گونه مسئولیتی در برابر قطعی‌های احتمالی ندارد.



نوع سوم- Wholesale Colocation Data Center

این سرویس بیشتر مختص شرکت‌های بزرگ است. به‌طوری‌که فضایی مانند یک اتاق با تمام امکانات به سازمان اجاره داده می‌شود. (در سرویس کولوکیشن یک رک به کسب‌وکار اجاره داده می‌شود). مشتریان این سرویس به‌صورت کامل در هر زمانی به سرورهای خود دسترسی دارند و می‌توانند زیرساخت خود را مدیریت نمایند و در فضای اختصاصی خود استقلال کامل داشته باشند.



نوع چهارم- Enterprise Data Center

یک کسب‌وکار می‌تواند یک مرکز داده خصوصی که تنها برای استفاده خود سازمان است را راه‌اندازی نماید. این نوع مرکز داده به این صورت است که هر کسب‌وکار برای نیاز خود به‌صورت اختصاصی در محل شرکت فضایی را برای نگهداری از سرورهای خود اختصاص می‌دهد. این نوع مرکز داده نیازمند سرمایه‌گذاری قابل‌توجه‌ای است و علاوه بر این، کسب‌وکار حتماً باید نیروی انسانی با دانش کافی جهت پشتیبانی ۲۴ ساعته در محل داشته باشند.



نوع پنجم- دیتاسنتر مجازی یا ابری

در دیتاسنتر ابری سرورهای مورد نياز بصورت مجازى وجود دارند به همین دلیل بدون نياز به صرف هزينه و زمان و در لحظه آماده و قابل بهره‌برداری هستند به این ترتیب در سرويس‌هاى ابری نیاز به هزينه سنگین برای خرید تجهیزات IT نیست. در این سرویس، کسب‌وکار می‌تواند دیتاسنتر ابری خود را مانند یک دیتاسنتر فیزیکی، طراحی کند، تعداد سرور موردنیاز و شبکه را تعریف و از طریق پنل مدیریت از دیتاسنتر خود محافظت و نگهداری کند.
#datacenter #type #sddc #server #bigdata
https://t.iss.one/unixmens

کتاب جدیدی که نوشتم و بصورت آزاد منتشر کردم ، تقدیم عزیزان کتاب نحوه مدیریت ESX و Vspareاز طریق libvirt و virsh
نکته : این کتاب قسمتی از کتاب مجازی سازی هست که در حال نوشتن آن هستم . بگذار اشتراک خوبی ها صفت تو باشد ...

#yashar_esmaildokht #linux #virtualization #vmware #redhat #esxi #esx #libvirt #virsh @unixmens

بورسیه کارشناسی، کارشناسی ارشد و دکترا در تمامی رشته های تحصیلی ارائه شده توسط دانشگاه ملبورن استرالیا
https://scholarships.unimelb.edu.au/awards/medley-hall-residential-college-bursaries

⁠⁣نحوه پیدا کردن کار در استرالیا🇦🇺


کارفرمایان در استرالیا ، ابتدا فرد مورد نظر برای کار را در میان افراد بومی همان کشور جستجو می کنند و در صورتی که فرد مورد نظر را پیدا نکردند برای افراد خارجی فرصت کاری فراهم خواهد شد. پس اگر علاقه مند به کار در استرالیا هستید بهتر است رزومه خوبی در مرحله اول داشته باشید و سپس نحوه پیدا کردن کار در استرالیا را بررسی نمایید. در اینجا برخی از روش هایی که افراد می توانند کار بیایند آورده شده است.


🔷 مراکز کاریابی در استرالیا⁣🇦🇺
یکی از راه هایی که افراد می توانند برای پیدا کردن شغل مورد نظر با توجه به مهارت خود استفاده کنند مراجعه به موسسات کاریابی است. این موسسات پلی بین شما و کارفرما هستند زیرا از شرایط و درخواست های استرالیا اطلاع دارند و می توانند کار مورد نظر شمارا بیابند . این موسسات بعد از پیدا کردن کار درصدی از حقوق شما را با توافق قبلی بر می دارند.


🔷 سایت های کاریابی استرالیا⁣🇦🇺
یکی دیگر از روش ها برای یافتن کار در استرالیا استفاده از وب سایت ها می باشد. نکته‌ای که نباید از یاد ببرید این است که توان فنی و مهارتی خود را در این حوزه ‌ها، همگام با پیشرفت فنی و تکنیکی روز دنیا افزایش دهید . واقعیت این است که به موازات افزایش نیاز در این مشاغل، توان تکنولوژی و تخصصی در استرالیا رو به افزایش می باشد . پس شما وقتی یک شغل را در استرالیا از آن خودتان کنید آگاهی و تخصصتان را هر روز باید به روز کنید .


وب سایت های کاریابی محبوب در استرالیا :

⁣◾️seek.com.au
⁣◾️jobnet.com.au
⁣◾️bluecollar.com.au
⁣◾️careerone.com.au
⁣◾️adzuna.com.au


🔷 یافتن کار در روزنامه های استرالیا⁣🇦🇺
آخرین روشی که می توان به آن اشاره نمود تا بتوانید کار پیدا کنید استفاده از روزنامه است. روزنامه های ملی و محلی را بخوانید. برای جستجو لازم نیست این روزنامه ها را بخرید، معمولا بسیاری از کتابخانه های ملی، روزنامه های معتبر را برای بازدیدکنندگان در محلی مخصوص قرار می دهند. با رفتن به کتابخانه نزدیک محل سکونت خود می توانید از این روزنامه ها و همچنین خدمات اینترنتی آنها به صورت رایگان استفاده کنید .


برخی از روزنامه های شناخته شده در استرالیا
▪️“Financial Review”
▪️the “Telegraph”
▪️“Sydney Morning Herald”


#oversea #unixmens

آیین نامه تامین اجتماعی در خصوص حمایت از شرکتهای نوپا

🔆🖌 #مفاهیم_دیجیتال_مارکتینگ

20. Event Promotion

تبلیغ (پیشبرد)رویداد به کلیه برنامه ها و استراتژیهای بازاریابی برای یک رویداد(event) گفته میشود. هدف یک برنامه پیشبرد رویداد اینست که تعداد قابل توجهی از مردم از یک رویداد خاص مطلع شوند که در نتیجه باعث شود میزان حضور و توجه مخاطبان یا حتی ثبت نام آنها برای دیدن برنامه افزایش یابد.

📌ابزارهای تبلیغاتی برای یک رویداد چیست و کدام مناسب است؟

اینکه چگونه بتوانیم برای یک رویداد، تبلیغات داشته باشیم مستلزم اینست که با یک استراتژی قوی و برنامه ریزی شده پیش برویم. اما نکته اینجاست که برای این استراتژی بزرگ نیازی نیست هزینه زیادی پرداخت نماییم.
ابزارها و نرم افزارهای بسیار و حتی رایگانی هستند که از آنها میتوانیم برای جلب مخاطب و تقویت رویداد بهره ببریم. اگر از پلتفرمهای موجود درست استفاده کنیم آنگاه فقط برای چند تبلیغ و آنهم در مقاطع زمانی محدود مجبوریم هزینه ای پرداخت نماییم.

📌موثرترین ابزارها برای تبلیغ یک رویداد چیست؟
1️⃣شبکه های اجتماعی
2️⃣ایمیل مارکتینگ
3️⃣وب سایت
4️⃣ثبت نام در سایت
5️⃣پوستر،بنر و هر نوع مدیای پیرینتی
6️⃣اینفلوئنسر مارکتینگ
7️⃣بازاریابی تجربی(همراه با عمل)experiential marketing
8️⃣ویدئو
9️⃣انتشار خبرنامه یا ویژه نامه
🔟بازاریابی مجدد remarketing

‏محققان امنیتی از وجود یک آسیب پذیری در کلاینت Forcepoint VPN خبر دادند. این آسیب پذیری از نوع ترفیع امتیازی است و تمام نسخه های این vpn به جز نسخه آخر را تحت تاثیر قرار داده است.
‎
securityaffairs.co/wordpress/91618/hacking/forcepoint-vpn-client-flaw.html
#security @unixmens

❇️ #گوگل امروز از ساخت رایانه کوانتومی جدید خود Sycamore با قدرت پردازشگر باورنکردنی 54 کوبیت خبر داد.

💪گوگل ادعا می کند که این رایانه مسائلی که یک ابر رایانه برای حل آن به حدود ده هزار سال زمان نیاز دارد را در کمتر از 💥سه و نیم دقیقه 💥پردازش می کند.
👇👇👇
👌در رایانه‌های کوانتومی به جای بیت از بیت کوانتومی یا کوبیت بجای 0 و 1 ها برای ذخیره‌سازی و انتقال داده‌های دیجیتالی استفاده می‌شود که در نتیجه سرعت فوق العاده ای را نسبت به یک رایانه کلاسیک به ارمغان می آورد.

ا DNS یک دیتابیس توزیع شده، سلسه مراتبی و پویاست که وظیفه‌ی آن فراهم کردن اطلاعاتی در رابطه با یک دامنه و آدرس‌های IP مرتبط با آن است. در این مطلب سعی شده تا مروری بر تاریخچه DNS ، مشکلات امنیتی آن و آن‌چه سبب خلق راهکار DNSSEC شد، پرداخته شود.


تاریخچه DNS

زمانی‌که مفهوم اینترنت به گستردگی حال حاضر نبود، سیستم‌ها برای برقراری ارتباط با یک‌دیگر، از آدرس IP استفاده می‌کردند. با رشد اینترنت و افزایش تعداد دستگاه‌هایی که قادر به اتصال به اینترنت بودند، تصمیم بر آن شد که سیستم‌ها با نام، یک‌دیگر را فرابخوانند. به ‌همین ‌دلیل نیاز به مکانیزمی برای مشخص کردن آدرس IP متناظر با هر نام بود.

نخستین راه‌حلی که برای این مشکل مطرح شد، استفاده از فایلی با نام host بود. در این فایل آدرس IP متناظر با هر نام درج شده و به هر سیستمی که قصد ارتباط با سایر سیستم‌ها با نام را داشت، منتقل می‌شد. اما با گسترده‌تر شدن دنیای اینترنت و اضافه شدن میلیون‌ها دستگاه به این ساختار، در عمل استفاده از فایل host و انتقال آن به هر سیستم، کاری ناممکن بود. همین عامل سبب معرفی سرویسی با نام Domain Name Service (DNS) شد.


عملکرد DNS

در DNS، اطلاعات مربوط به یک دامنه و آدرس‌های IP مرتبط با آن به‌وسیله‌ی Resource Recordها مشخص می‌شوند که انواع مختلفی دارند و مشهورترین آن‌ها رکورد A، رکورد MX، رکورد AAAA و رکورد NS هستند. با ساخت یک دامنه، برای آن یک zone ساخته می‌شود که RRهای مرتبط با آن در فایلی با نام DNS zone file که یک فایل متنی ساده ‌است، ذخیره می‌شوند. پس به‌شکل خلاصه، وظیفه‌ی DNS، نگهداری و فراهم کردن فایل DNS zone است.

آدرس‌های DNS از چند label ساخته می‌شوند که هر label مشخص‌کننده‌ی سلسله مراتبی است که به‌ترتیب باید به سراغ آن‌ها رفت. این labelها از راست به چپ بررسی می‌شوند. برای نمونه نشانی .www.example.com دارای چهار label است؛“www“ که در این سلسله مراتب leaf به‌شمار می‌آید،“example” که یک دامنه است،“com“ که یک TLD یا Top Level Domain است و درنهایت “.” که نشان‌دهنده‌ی Root Server است.

زمانی‌که در مرورگر خود نشانی www.example.com را وارد می‌کنید، در نخستین گام سیستم‌عامل Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر هیچ آدرس IP پیدا نکند،recursive query را به‌سمت Recursive Resolver ارسال می‌کند.

در DNS از دو نوع query استفاده می‌شود. Recursive و iterative. تفاوت این دو query عبارت است از:

یکrecursive query حتمن باید با ارسال یک response پاسخ داده شود.
iterative query نیازی به دریافت response ندارد.

ا Recursive resolver می‌تواند DNS سروری فراهم شده به‌وسیله‌ی ISP یا هر name server دیگری باشد که از سایر DNS سرورهایی که می‌توانند در رابطه با آدرس IP دامنه‌ی www.example.com پاسخ دهند، آگاهی دارد. Recursive Resolver با دریافت query از سمت مرورگر، ابتدا Cache خود را برای یافتن آدرس IP متناظر با آن بررسی می‌کند. اگر آدرسی پیدا نکند، با بررسی labelهای دامنه‌ی www.example.com. از چپ به راست (نخستین برچسب . است) متوجه می‌شود که اولین مکانی که برای پیدا کردن آدرس IP مربوطه باید به سراغ آن برود Root Server است.

اکنون سیزده Root Server در سراسر دنیا وجود دارند که دربردارنده‌ی اطلاعات DNS مربوط به Top Level Domainها یا TLDها هستند. TLDها در واقع دامنه‌هایی مانند .com، .org و… هستند. پس Recursive Resolver با ارسال یک iterative query از Root Server در رابطه با TLD .com سوال می‌کند و Root Server نیز در پاسخ، برای آن آدرس IP مربوط به TLD .com را ارسال می‌کند.

در گام بعد Recursive Resolver یک iterative request برای TLD که آدرس IP آن را از Root Server دریافت کرده است، ارسال می‌کند و در رابطه با example.com می‌پرسد. TLDها، DNS serverهایی هستند که اطلاعات DNS مربوط به زیردامنه‌های خود را نگهداری می‌کنند (در این‌جا TLD .com دارنده‌ی اطلاعات example.com است). TLD با دریافت درخواست، آدرس IP مربوط به example.com را برای Recursive Resolver ارسال می‌کند.

در مرحله‌ی بعد Recursive Resolver با ارسال یک iterative query برای example.com، آدرس IP متعلق به رکورد www.example.com را خواستار می‌شود. example.com نیز در پاسخ آدرس IP مربوط به رکورد www.example.com را برای Recursive Resolver ارسال می‌کند. درنهایت، Recursive Resolver که به آدرس IP مربوط به www.example.com دست یافته، آن را برای مرورگر ارسال می‌کند و صفحه‌ی مربوط به این دامنه در مرورگر (البته با چشم‌پوشی از چند مرحله‌ی دیگر که ارتباطی با DNS ندارند) باز می‌شود. تمام این اتفاقات در کم‌تر از چند ثانیه رخ می‌دهند.

تصویر زیر بیان‌گر مراحلی است که گفته شد.

حمله‌ی DNS Spoofing

در ابتدای معرفی DNS هیچ تصوری از ایجاد مشکلات امنیتی برای این سرویس محبوب نبود. البته این موضوع برای تمام سرویس‌ها و پروتکل‌هایی که در ابتدای دهه‌ی 1980 معرفی می‌شدند، صدق می‌کرد. همین موضوع سبب شد تا آسیب‌های امنیتی جدی برای DNS ایجاد شوند.

مسایل امنیتی DNS به‌طور کلی در دسته‌های زیر قرار می‌گیرند:

استفاده از reverse DNS برای جعل هویت کاربران
خطاهای نرم‌افزاری (مانند سرریز بافر و…)
رمزنگاری بد (مانند توالی‌های پیش‌بینی‌پذیر و…)
نشت اطلاعات (مانند داده‌های نامعتبر یا افشای محتویات Cache)
قرار دادن داده‌های نامناسب در Cache یا در اصطلاح Cache poisoning

نخستین مشکل امنیتی که در DNS کشف شد، Cache Poisoning بود که از آن با نام DNS Spoofing نیز یاد می‌شود. DNS Cache Poisoning زمانی اتفاق می‌افتد که سرور DNS پایین دست (Recursive Resolver)، داده‌ها یا IP نادرستی را ارسال کند. در این حمله مهاجم با در اصطلاح، سمی کردن Cache سرور DNS پایین‌دست، سبب می‌شود که این DNS سرور در مقابل درخواست‌هایی که دریافت می‌کند، پاسخ‌های اشتباه و مورد دل‌خواه مهاجم را ارسال کند.

برای درک بهتر این حمله، تصویر زیر را در نظر بگیرید. در این تصویر قالب قدیمی پیامی حاوی داده‌های DNS نشان داده شده که در آن، فیلدهای مهم مورد استفاده در حمله‌ی Cache poisoning با رنگ آبی کم‌ رنگ متمایز شده‌اند.

پایه و اساس این حمله بر دو موضوع استوار بود؛ نخست آن که در آن زمان، سرورهای DNS برای هر Query که تولید می‌کردند در فیلد Query ID (QID) (یا Transaction ID که از آن برای ره‌گیری queryها و responseهای آن‌ها استفاده می‌شود) مقداری عددی قرار می‌دادند که به‌ازای هر پیام جدید، به این مقدار یک واحد اضافه می‌شد. به بیان دیگر، شماره QIDها یک رشته از اعداد متوالی بودند، پس با به‌دست آوردن یک QID ،QID پیام بعدی به‌راحتی حدس ‌زده می‌شد.

مورد دوم آن‌که DNS از UDP استفاده می‌کرد. به‌همین دلیل، زمان ارسال یک Query روی یک پورت UDP، منتظر دریافت پاسخ مربوط به آن، از روی همان پورت می‌ماند و به‌محض دریافت نخستین پاسخ درست، پاسخ پذیرفته می‌شد و سایر پیام‌ها رد می‌شدند.

مهاجم ابتدا برای به‌دست آوردن QID و شماره پورت، یک Host (تصور کنید یک وب‌سایت جعلی) در DNS server متعلق به خود ایجاد و سپس به‌سمت Recursive Resolver، کوئری را برای دسترسی به این Host ارسال می‌کرد. چون در آن زمان سرورهای DNS، شماره پورتی تصادفی و خالی را در اختیار می‌گرفتند و برای تمام پیام‌های بعدی که قرار بر ارسال آن‌ها بود از همین شماره پورت به‌عنوان شماره پورت مبدا در هِدر پیام UDP استفاده می‌کردند، و از سوی دیگر چون شماره QIDها به‌شکل متوالی افزایش پیدا می‌کردند، مهاجم تنها با شنود ترافیک DNS جاری شده به‌سمت سرور خود می‌توانست به‌راحتی به این دو مورد دست پیدا کند.

مرحله‌ی بعد، سمی کردن رکورد مربوط به Host مورد حمله در DNS سرور Recursive Resolver بود. ابتدا مهاجم با ارسال Query، از Recursive Resolver آدرس IP مربوط به Host مورد نظر را پرس‌وجو می‌کرد. Recursive Resolver نیز برای پیدا کردن آدرس آن Host (البته اگر آن را در Cache خود ذخیره نداشت) به سراغ Root Server می‌رفت. هم‌زمان با این که Recursive Resolver پیام Query را برای یافتن آدرس IP دامنه‌ی مورد نظر برای Root Server ارسال می‌کرد، مهاجم نیز شروع به ارسال پی‌درپی responseهایی با آدرس IP جعلی و QIDهایی در بازه‌ی QID به‌دست آورده، می‌کرد.

نخستین QID که با QID مربوط به Query ارسال شده مطابقت پیدا می‌کرد، Recursive Server همان را به‌عنوان پاسخ درست می‌پذیرفت و در Cache خود ذخیره می‌کرد و حتا اگر پس از آن سرور اصلی مربوط به آن Host نیز، پاسخ درست را ارسال می‌کرد، آن پاسخ دیگر پذیرفته نمی‌شد.

تصویر زیر بیان‌گر اتفاقاتی است که گفته شد.

شاید این حمله به گفتار ساده باشد اما در حقیقت دارای پیچیدگی‌های بسیاری است:

نخست آن که دامنه‌ی مورد حمله نباید در Cache سرور Recursive موجود باشد وگرنه آن‌چه در بالا توضیح داده شد، رخ نمی‌دهد و Recursive Resolver بی‌درنگ با دریافت Query از جانب سیستم مهاجم، آدرس IP که در Cache خود ذخیره دارد را برای آن ارسال می‌کند.
دوم آن که مهاجم باید توانایی حدس زدن QID را داشته باشد.
مورد سوم آن که، سیستم مهاجم باید سرعت‌ عملی بیش‌تر از ارتباط میان Recursive Resolver و Root Server داشته باشد تا بتواند پاسخی با QID مورد انتظار در Recursive Resolver را سریع‌تر از Name Server اصلی ارسال کند.

این مشکل نخستین‌بار به‌وسیله‌ی Computer Science Research Group (CSRG) در دانشگاه Berkeley در سال 1989 کشف شد و از آن جایی دارای اهمیت بود که دو برنامه‌ی مشهور UNIX در آن زمان (rsh و rlogin) از DNS برای احراز هویت کاربرانی که قصد ریموت زدن به آن‌ها را داشتند، استفاده می‌کردند. این دو برنامه به آدرس IP نگاهی می‌انداختند و متناسب با آن، hostname را به‌دست می‌آوردند و بدون هیچ پرسش اضافه‌تری که آیا این کاربر معتبر است یا نه، آن را می‌پذیرفتند. پس یک مهاجم به‌راحتی می‌توانست با یک کاربر جعلی به این برنامه‌ها دسترسی پیدا کند. CSRG برای حل این مشکل، Query رکورد PTR علاوه‌بر رکورد A را پیشنهاد کرد. اما این روش نیز با DNS cache poisoning قابل دور زدن بود.

راه‌حل دیگر استفاده ازTransaction ID های تصادفی برای BIND بود. اما بیش‌تر راه‌حل‌های پیشنهادی برای امن‌سازی DNS چندان هم خوب به نظر نمی‌رسیدند و نیاز به یک روش بهتر، هم‌چنان احساس می‌شد. در سال 1997 نهاد IETF نخستین RFC (2065) را در رابطه با راه‌حلی بهتر برای امن‌سازی DNS ارایه کرد. این راه‌حل Domain Name System Security Extensions (DNSSEC) نام داشت اما جز برای محققانی که به‌خوبی بر مشکلات بسیار DNS آگاهی داشتند، مورد استقبال قرار نگرفت و بنا به هر دلیلی، جدی قلمداد نشد.


باگ Kaminsky

در سال 2008، محققی به نام Dan Kaminsky اعلام کرد که شیوه‌ی جدیدی از حملات Cache Poisoning را کشف کرده که بسیار بدتر از انواع قبلی است.

همان‌طور که در بخش قبل توضیح داده شد، در حمله‌ی Cache Poisoning مهاجم قادر بود تا با سمی کردن رکورد مربوط به Host مورد حمله در Cache مربوط به Recursive Server، کاری کند که درخواست کاربران برای دسترسی به آن Host، به‌سمت سرور جعلی او منتقل شوند. اما Kaminsky کشف کرد که مهاجم می‌تواند یک گام فراتر رود و به‌جای سمی کردن رکورد مربوط به یک Host، کاری کند که تمام درخواست‌هایی که مربوط به یک دامنه‌ی خاص هستند، سمی شوند. برای نمونه فرض کنید در تصویر بالا تمام درخواست‌هایی که مربوط به دامنه‌ی example.com هستند (example.com، example2.com و…) به‌سمت سرور جعلی مهاجم منتقل شوند.

در این حمله مهاجم به‌جای هدف قرار دادن رکورد A در پیام DNS، به سراغ Authority رکوردها می‌رود و این‌گونه ادعا می‌کند که name server مورد درخواست نیست اما از آن اطلاع دارد و می‌تواند پاسخ درخواست‌های مربوط به این name server را بدهد. به بیان بهتر خود را به‌عنوان یک Authoritative name server جا می‌زند. به ‌این ‌ترتیب هر درخواستی که به دست Recursive Resolver برسد که مربوط به دامنه‌ی هدف باشد، به‌سمت مهاجم ارسال می‌شود.

پیدا شدن این باگ جامعه‌ی اینترنت را مجاب به یافتن راهی برای حل این مشکل کرد. راه‌حل پیشنهادی، افزایش سایز QID از 16 بیت به 32 بیت، هم‌چنین استفاده از شماره پورت‌های تصادفی برای هر پیام DNS به‌جای یک پورت UDP یک‌سان برای همه‌ی پیام‌ها بود. این راه‌حل‌ها هر چند سبب سخت‌تر شدن کار مهاجمان برای انجام این حمله می‌شدند اما آن را به یک امر ناممکن مبدل نمی‌‌ساختند. پس باز هم نیاز به روشی برای امن‌تر کردن DNS هم‌چنان احساس می‌شد.

تمام این موارد سبب شدند تا ضرورت توسعه و استفاده از DNSSEC که پیش‌تر به‌وسیله‌ی IETF معرفی شده بود، بیش از پیش احساس شود.