یه نفر اومده و یه موزیک پلیر لینوکس به اسم sung با cpp و qt نوشته که طراحی زیبا و ویژگی های باحالی داره
این موزیک پلیر هم سرویس هایی مثل Youtube رو ساپورت میکنه هم میتونید خودتون یه موزیک سرور (مثل jellyfin و Subsonic) راه بندازید و با این کلاینت بهش وصل بشید
یا اصلا میتونید از موزیک های لوکال خودتون استفاده کنید

قابلیت‌هایی مثل لیریک سینک‌شده، ترکیب آهنگ‌های لوکال و یوتیوب توی یه پلی‌لیست، و پشتیبانی از کاورهای متحرک رو هم داره که خودتون می‌تونید تستش کنید.

اوپن سورسه و برای نصب و استفاده میتونید به گیت هابش سر بزنید

https://github.com/yappologistic/Sung

#tools #music | <Yappologistic>
@CleverDevs - @CleverDevsGp

OOP در پایتون چیست؟
OOP مخفف Object-Oriented Programming یا «برنامه‌نویسی شیءگرا» است.
پایتون یک زبان شیءگراست و به ما اجازه می‌دهد کدهای خود را با استفاده از Class و Object ساختاربندی کنیم.
مزایای OOP:
ساختار منظم‌تر برنامه
نگهداری و دیباگ آسان‌تر کد
امکان استفاده مجدد از کد
کاهش کدهای تکراری
کمک به رعایت اصل DRY
اصل DRY مخفف Don't Repeat Yourself است؛ یعنی سعی کنیم یک بخش از کد را چندین بار تکرار نکنیم و در صورت نیاز، آن را داخل یک تابع یا کلاس قرار داده و دوباره استفاده کنیم.
Class و Object چیست؟
کلاس را می‌توانیم مانند یک نقشه یا الگو برای ساخت Object در نظر بگیریم.
برای مثال:
Fruit یک Class است.
و:
Apple
Banana
Mango
می‌توانند Objectهایی بر اساس آن باشند.
مثال دیگر:
Car → Class
Volvo، Audi و Toyota → Object
متد __init__()
متد __init__() هنگام ایجاد یک Object به صورت خودکار اجرا می‌شود و معمولاً برای مقداردهی اولیه به ویژگی‌های Object استفاده می‌شود.

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

p1 = Person("Emil", 36)

print(p1.name)
print(p1.age)

خروجی:

Emil
36

در این مثال، Object به نام p1 ایجاد شده و مقدار name برابر Emil و مقدار age برابر 36 است.
پارامتر self چیست؟
self به Object فعلی اشاره می‌کند و با استفاده از آن می‌توانیم به ویژگی‌ها و متدهای همان Object دسترسی داشته باشیم.

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def greet(self):
        print("Hello, my name is " + self.name)

p1 = Person("Emil", 25)
p1.greet()

خروجی:

Hello, my name is Emil

در اینجا self.name به ویژگی name مربوط به همان Object اشاره می‌کند.
یک مثال ساده با کلاس Dog

class Dog:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def bark(self):
        print(self.name + " says Woof!")

d1 = Dog("Buddy", 3)

d1.bark()

خروجی:

Buddy says Woof!

در این مثال:
Dog → Class
d1 → Object
name و age → Properties
bark() → Method
__init__() → متد مقداردهی اولیه
self → اشاره به Object فعلی
مفاهیم مهم OOP در پایتون:
Classes و Objects
__init__()
self
Properties و Methods
Inheritance
Polymorphism
Encapsulation
Inner Classes
در ادامه یادگیری OOP، این مفاهیم به ما کمک می‌کنند برنامه‌های بزرگ‌تر را به بخش‌های کوچک‌تر و قابل مدیریت تقسیم کنیم و کدی بنویسیم که استفاده مجدد، توسعه و نگهداری آن ساده‌تر باشد.


@JustMyLogss

In-Place Upgrade یا Clean Installation؟
وقتی قرار هست یک Windows Server رو به نسخه جدیدتر ارتقا بدیم، معمولاً با دو انتخاب روبه‌رو هستیم:
In-Place Upgrade
یا
Clean Installation + Migration
در نگاه اول شاید تفاوتشون فقط روش نصب ویندوز به نظر بیاد، ولی در محیط واقعی، انتخاب بین این دو می‌تونه روی Downtime، سرویس‌ها، Applicationها و حتی مدیریت سرور در آینده تأثیر بذاره.
In-Place Upgrade
در این روش، همون Server فعلی رو مستقیماً به نسخه جدید ارتقا می‌دیم.
مثلاً:
Windows Server 2019 → Windows Server 2022
مزیت اصلی این روش اینه که بخش زیادی از Configuration، Roleها، Featureها و Applicationهای فعلی حفظ میشن.
در نتیجه معمولاً Migration کمتری داریم و Downtime هم می‌تونه کمتر باشه.
اما یک نکته مهم وجود داره:
In-Place Upgrade قرار نیست محیط فعلی رو تمیز کنه.
اگر روی Server از قبل Configuration اشتباه، Dependency قدیمی، سرویس ناسازگار یا حتی یک مشکل ناشناخته وجود داشته باشه، ممکنه بعد از Upgrade هم همچنان وجود داشته باشه.
یعنی عملاً محیط فعلی رو با تمام وابستگی‌هاش وارد نسخه جدید می‌کنیم.
Clean Installation
اینجا رویکرد کاملاً متفاوت هست.
یک Windows Server جدید رو از صفر نصب می‌کنیم و بعد سرویس‌ها و اطلاعات موردنیاز رو به محیط جدید منتقل می‌کنیم.
این روش طبیعتاً کار بیشتری داره، اما یک مزیت مهم داره:
از ابتدا دقیقاً می‌دونیم چه چیزی روی Server جدید نصب و Configure شده.
در واقع Clean Install فقط نصب مجدد Windows نیست؛ می‌تونه فرصتی باشه برای اینکه Configurationهای قدیمی و غیرضروری رو هم شناسایی و حذف کنیم.
البته Migration هم بدون دردسر نیست.
مواردی مثل:
• Permissionها
• Certificateها
• DNS
• Firewall Rules
• Scheduled Tasks
• Service Dependencies
• Application Configuration
• Backup و Monitoring Agentها
همگی باید قبل از Migration بررسی بشن.
پس کدوم روش رو انتخاب کنیم؟
جوابش به شرایط Server بستگی داره.
اگر Server وضعیت Stable داشته باشه، Applicationها با نسخه جدید سازگار باشن، Dependencyها مشخص باشن و Downtime محدودی داشته باشیم، In-Place Upgrade می‌تونه انتخاب مناسبی باشه.
اما اگر Server قدیمی و پیچیده باشه، Configurationهای زیادی داشته باشه یا دقیقاً ندونیم چه چیزهایی طی سال‌ها روی اون تغییر کرده، ساختن یک Server جدید و Migration کردن سرویس‌ها کنترل بیشتری روی محیط نهایی میده.
در نهایت، چیزی که قبل از Upgrade اهمیت بیشتری از خود Upgrade داره، Preparation و Recovery Plan هست.
قبل از شروع باید بدونیم:
چه چیزهایی باید Backup بشن؟
چه Dependencyهایی داریم؟
چقدر Downtime قابل قبوله؟
اگر Upgrade شکست خورد، Rollback چطور انجام میشه؟
و مهم‌تر از همه، آیا Backup واقعاً قابل Restore هست؟
چون داشتن Backup با داشتن یک Backup قابل بازیابی، دو چیز کاملاً متفاوت هستن.
#WindowsServer #SysAdmin #Infrastructure #Server #InPlaceUpgrade #CleanInstall


@JustMyLogss

BIOS در مقابل UEFI؛ تفاوت نسل قدیم و جدید Firmware

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

دو فناوری اصلی در این زمینه BIOS و UEFI هستند. BIOS سال‌ها استاندارد اصلی سیستم‌های کامپیوتری بود، اما امروزه UEFI تقریباً جایگزین آن شده است.
در ادامه مهم‌ترین تفاوت‌های این دو را بررسی می‌کنیم.

1. زمان معرفی
BIOS از سال 1981 در کامپیوترهای شخصی مورد استفاده قرار گرفت و برای چندین دهه استاندارد اصلی فرآیند Boot سیستم بود.
در مقابل، اولین مشخصات UEFI در سال 2002 منتشر شد و به‌عنوان نسل جدیدتر Firmware برای رفع محدودیت‌های BIOS طراحی شد.

2. رابط کاربری
یکی از تفاوت‌های قابل مشاهده بین BIOS و UEFI، رابط کاربری آن‌هاست.
در BIOS معمولاً با یک محیط Text-Based مواجه هستیم که بیشتر با استفاده از صفحه‌کلید کنترل می‌شود.
اما UEFI می‌تواند یک رابط گرافیکی (GUI) داشته باشد و علاوه بر صفحه‌کلید، از Mouse نیز پشتیبانی کند.
به همین دلیل تنظیمات UEFI معمولاً برای کاربران ساده‌تر و قابل فهم‌تر است.

3. معماری و محدودیت حافظه
BIOS یک Firmware قدیمی با معماری 16-bit است و در زمان Boot با محدودیت‌های زیادی در دسترسی به حافظه مواجه می‌شود.
UEFI معماری مدرن‌تری دارد و می‌تواند در حالت 32-bit یا 64-bit اجرا شود؛ بنابراین محدودیت‌های حافظه و محیط اجرایی آن بسیار کمتر از BIOS است.
این موضوع یکی از دلایل اصلی طراحی UEFI برای سخت‌افزارهای مدرن‌تر است.

4. پشتیبانی از Partition
یکی از مهم‌ترین تفاوت‌های BIOS و UEFI مربوط به نحوه Boot شدن از روی دیسک است.
BIOS معمولاً با MBR (Master Boot Record) استفاده می‌شود.
MBR محدودیت‌هایی دارد که یکی از مهم‌ترین آن‌ها محدودیت حجم دیسک قابل استفاده برای Partition Table، در حالت متداول، حدود 2TB است.
در مقابل، UEFI از GPT (GUID Partition Table) پشتیبانی می‌کند.
GPT برای دیسک‌های بسیار بزرگ‌تر طراحی شده و محدودیت 2 ترابایتی MBR را ندارد.
بنابراین در سیستم‌های جدید، ترکیب:
UEFI + GPT
استاندارد رایج‌تری محسوب می‌شود.

5. امنیت
BIOS به‌صورت ذاتی قابلیت‌های امنیتی مدرن زیادی ندارد.
در مقابل، UEFI امکان استفاده از قابلیت‌هایی مانند Secure Boot را فراهم می‌کند.
Secure Boot در زمان Boot شدن سیستم، صحت و اعتبار اجزای نرم‌افزاری مورد استفاده برای راه‌اندازی سیستم را بررسی می‌کند و می‌تواند از اجرای Bootloaderهای غیرمجاز جلوگیری کند.
این قابلیت در سیستم‌های جدید و مخصوصاً محیط‌های سازمانی اهمیت زیادی دارد.
6. Performance و سرعت Boot
BIOS به دلیل معماری قدیمی‌تر و محدودیت‌های موجود، فرآیند Boot مدرن و بهینه‌ای ندارد.
UEFI برای سخت‌افزارهای جدید طراحی شده و می‌تواند فرآیند Boot را سریع‌تر و بهینه‌تر انجام دهد.
به همین دلیل در بسیاری از سیستم‌های امروزی، استفاده از UEFI Boot باعث کاهش زمان راه‌اندازی سیستم نسبت به Legacy BIOS می‌شود.



@JustMyLogss

یک توسعه دهنده اسپانیایی با استفاده از هوش مصنوعی، تمامی ابزارهای ادوب را مهندسی معکوس کرده و در راست بازنویسی کرده است.


https://getartcraft.com/apps


شما کاربران پارچ می‌توانید این ابزارها را تست کرده و نتایج آن را با ما به اشتراک بگذارید.

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


@ParchLinux | پارچ لینوکس

عجیب پروژه قوی ایه

چطور دسترسی یک کاربر به لاگین ویندوز رو محدود کنیم؟

یکی از قابلیت‌های امنیتی ویندوز سرور، امکان محدود کردن ورود کاربران به سیستم هست. فرض کنید توی شبکه چند تا کاربر داریم و می‌خوایم اجازه ورود مستقیم به سیستم رو از یک کاربر خاص بگیریم، بدون اینکه اکانتش رو غیرفعال یا حذف کنیم. اینجا Policy به نام Deny log on locally به کارمون میاد.

چطور تنظیمش کنیم؟

اول کلیدهای Win + R رو می‌زنیم و دستور gpedit.msc رو اجرا می‌کنیم.
بعد از طریق مسیر زیر وارد تنظیمات امنیتی می‌شیم:

Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment

حالا گزینه Deny log on locally رو پیدا می‌کنیم و روش دابل‌کلیک می‌زنیم.

گزینه Define these policy settings رو فعال می‌کنیم، روی Add User or Group می‌زنیم و نام کاربری موردنظر رو وارد می‌کنیم. بعد از تأیید تغییرات، برای اعمال سریع‌تر Policy می‌تونیم CMD رو با دسترسی Administrator باز کنیم و دستور زیر رو اجرا کنیم:

gpupdate /force

اما یه نکته 
این Policy فقط ورود محلی به سیستم رو محدود می‌کنه؛ یعنی کاربر نمی‌تونه مستقیماً از طریق کنسول سیستم وارد ویندوز بشه. اگر هدفمون جلوگیری از ورود از طریق Remote Desktop یا همون RDP باشه، باید از Policy جداگانه‌ی Deny log on through Remote Desktop Services استفاده کنیم.

در نهایت، این روش کمک می‌کنه دسترسی کاربران رو دقیق‌تر مدیریت کنیم، بدون اینکه مجبور باشیم حساب کاربریشون رو حذف یا غیرفعال کنیم.

قبل از اعمال این Policy روی سرورهای واقعی، حتماً بررسی کنید که دسترسی حساب‌های مدیریتی ضروری محدود نشه؛ چون یک تنظیم اشتباه در Policyهای امنیتی می‌تونه دسترسی به سیستم رو دردسرساز کنه.

شاید این کارا به نظر ساده بیان ولی مهمه به یاد داشتنشون.


@JustMyLogss

دسکتاپ داداشو دارید که

NTFS Permission در ویندوز سرور

یکی از چیزایی که توی Windows Server خیلی مهمه، بحث NTFS Permission هست. با استفاده از این قابلیت می‌تونیم مشخص کنیم هر کاربر به چه فایل یا پوشه‌ای دسترسی داشته باشه و چه کارهایی بتونه انجام بده.

برای مثال، فرض کنید روی سرور یه پوشه به اسم Financial داریم. می‌خوایم کارمندها فقط بتونن فایل‌های داخلش رو ببینن، مدیر مالی بتونه فایل‌ها رو ویرایش کنه و فقط ادمین دسترسی کامل داشته باشه. اینجاست که NTFS Permission به کارمون میاد.

انواع دسترسی‌های NTFS

به‌طور کلی، چند نوع دسترسی اصلی داریم:

Read: فقط اجازه خوندن فایل‌ها و مده اطلاعات رو می‌ده.
Write: اجازه نوشتن اطلاعات و ایجاد بعضی فایل‌ها و پوشه‌ها رو می‌ده.
Read & Execute: علاوه بر خوندن اطلاعات، امکان اجرای برنامه‌ها رو هم فراهم می‌کنه.
List Folder Contents: اجازه مشاهده فایل‌ها و زیرپوشه‌های داخل یه پوشه رو می‌ده.
Modify: کاربر می‌تونه فایل‌ها رو بخونه، ویرایش و حذف کنه.
Full Control: دسترسی کامله؛ یعنی کاربر علاوه بر تغییر و حذف فایل‌ها، می‌تونه Permissionها رو هم مدیریت کنه.
یه نکته مهم اینه که Modify با Full Control فرق داره. مثلاً اگه به یه کاربر Modify بدیم، معمولاً می‌تونه فایل‌ها رو ویرایش یا حذف کنه، ولی اجازه تغییر دسترسی‌ها رو نداره.

تفاوت Allow و Deny

وقتی می‌خوایم دسترسی یه کاربر رو تنظیم کنیم، با دو گزینه Allow و Deny روبه‌رو می‌شیم.
Allow یعنی اجازه انجام یه کار رو به کاربر بدیم و Deny یعنی اون دسترسی رو ازش بگیریم.
معمولاً Deny صریح بر Allow معمولی اولویت داره. پس باید موقع استفاده از Deny دقت کنیم، چون ممکنه دسترسی‌های دیگه کاربر هم تحت تأثیر قرار بگیرن.

Explicit و Inherited Permission

این دوتا هم از موارد مهم NTFS هستن.
Explicit Permission یعنی دسترسی‌ای که مستقیماً روی یه فایل یا پوشه تنظیم می‌کنیم.
Inherited Permission یعنی دسترسی‌ای که از پوشه والد به فایل‌ها و پوشه‌های داخلش به ارث می‌رسه.
مثلاً اگه روی پوشه D:\Company دسترسی Read بدیم، این دسترسی می‌تونه به زیرپوشه‌ها و فایل‌های داخلش هم منتقل بشه. البته این موضوع به تنظیمات وراثت بستگی داره.

تفاوت NTFS Permission با Share Permission

این یکی از نکات مهم توی ویندوز سروره که خیلی وقت‌ها با هم اشتباه گرفته می‌شن.
NTFS Permission دسترسی به فایل‌ها و پوشه‌ها رو روی فایل‌سیستم کنترل می‌کنه؛ چه به‌صورت محلی و چه از طریق شبکه.
اما Share Permission مربوط به دسترسی به پوشه‌ایه که توی شبکه به اشتراک گذاشته شده.
وقتی کاربر از طریق شبکه به یه پوشه دسترسی پیدا می‌کنه، هر دو مجوز بررسی می‌شن و معمولاً محدودکننده‌ترین دسترسی تعیین‌کننده است.
مثلاً اگه Share Permission روی Full Control باشه ولی NTFS Permission فقط Read باشه، کاربر از طریق شبکه فقط می‌تونه فایل‌ها رو بخونه.
برعکسش هم همین‌طوره؛ اگه Share روی Read باشه و NTFS روی Modify، باز هم دسترسی شبکه‌ای کاربر به Read محدود می‌شه.
چطوری NTFS Permission تنظیم کنیم؟
برای تنظیم دسترسی یه پوشه، کافیه مراحل زیر رو انجام بدیم:
روی پوشه راست‌کلیک کنیم و وارد Properties بشیم.
وارد تب Security بشیم.
روی Edit کلیک کنیم.
از قسمت Add کاربر یا گروه موردنظر رو اضافه کنیم.
دسترسی موردنظر مثل Read، Modify یا Full Control رو انتخاب کنیم.
برای تنظیمات پیشرفته‌تر هم می‌تونیم وارد Security > Advanced بشیم و دسترسی‌ها، وراثت و مالکیت رو بررسی کنیم.
یه مثال کاربردی
فرض کنید روی سرور یه پوشه به اسم D:\Company\Financial داریم و سه گروه ساختیم:
Financial_Readers با دسترسی Read & Execute
Financial_Editors با دسترسی Modify
Administrators با دسترسی Full Control
به این شکل، گروه اول فقط می‌تونه فایل‌ها رو بخونه، گروه دوم امکان ویرایش و حذف فایل‌ها رو داره و گروه سوم می‌تونه دسترسی‌ها رو هم مدیریت کنه.
یه نکته دیگه هم اینکه بهتره به‌جای اینکه به هر کاربر جداگانه Permission بدیم، دسترسی‌ها رو به گروه‌ها اختصاص بدیم و کاربران رو عضو گروه مناسب کنیم. این کار مدیریت دسترسی‌ها رو خیلی راحت‌تر می‌کنه.
چند نکته که بهتره یادتون بمونه:
Modify با Full Control فرق داره.
Permissionها می‌تونن از پوشه والد به ارث برسن.
Deny صریح معمولاً بر Allow معمولی اولویت داره.
برای دسترسی به فایل‌ها از طریق شبکه، باید هم NTFS و هم Share Permission رو بررسی کنیم.
اگه کاربر با وجود داشتن دسترسی نمی‌تونه وارد پوشه بشه، باید عضویت گروه‌ها، وراثت و Effective Access رو هم بررسی کنیم.


@JustMyLogss

Disk Quota دقیقاً چیه؟

Disk Quota قابلیتی در ویندوزه که به مدیر سیستم اجازه می‌ده میزان فضای دیسکی رو که کاربران مصرف می‌کنن، کنترل و محدود کنه.
برای مثال، فرض کنید یک سازمان از Windows Server به‌عنوان فایل‌سرور استفاده می‌کنه و فایل‌های واحدهای مختلف روی یک پارتیشن ذخیره می‌شن. مدیر شبکه می‌خواد هر کاربر بیشتر از ۱۰ گیگابایت فضای دیسک مصرف نکنه.

به‌جای اینکه هر روز میزان مصرف کاربران رو به‌صورت دستی بررسی کنه، می‌تونه Disk Quota رو فعال کنه و برای هر کاربر محدودیت مشخصی تعریف کنه.
نکته مهم اینه که Quota فضای دیسک رو افزایش نمی‌ده؛ بلکه مصرف فضای موجود رو مدیریت می‌کنه.

Disk Quota در ویندوز چطور کار می‌کنه؟
در ویندوز، Disk Quota معمولاً از طریق تنظیمات فایل‌سیستم NTFS مدیریت می‌شه. این قابلیت مصرف فضای دیسک رو بر اساس حساب کاربری ویندوز محاسبه می‌کنه، نه صرفاً بر اساس پوشه‌ای که فایل داخلش قرار داره.
برای مثال، اگر دو کاربر روی یک پارتیشن NTFS فایل ذخیره کنن، مدیر سیستم می‌تونه برای هرکدوم محدودیت جداگانه تعیین کنه.
حتی اگر یکی از کاربران تمام سهمیه خودش رو مصرف کرده باشه، کاربر دیگه همچنان می‌تونه از سهمیه خودش استفاده کنه؛ البته تا زمانی که فضای آزاد پارتیشن و سایر محدودیت‌ها اجازه بدن.

این ویژگی برای فایل‌سرورهای سازمانی بسیار کاربردیه، چون به مدیر سیستم اجازه می‌ده مصرف فضای دیسک رو بر اساس هویت کاربران کنترل کنه.
تفاوت Disk Quota با محدودیت حجم پوشه

این دو مفهوم رو نباید با هم اشتباه بگیریم.
Disk Quota در NTFS، مصرف دیسک رو برای هر کاربر در یک Volume مشخص کنترل می‌کنه. یعنی محدودیت بر اساس حساب کاربری اعمال می‌شه، نه اینکه مستقیماً برای هر پوشه یک سقف مستقل تعریف کنه.

برای مثال، فرض کنید پوشه‌های Finance، HR و IT روی یک فایل‌سرور قرار دارن. اگر هدف این باشه که هر کاربر در کل یک Volume بیشتر از مقدار مشخصی فضا مصرف نکنه، Disk Quota می‌تونه مناسب باشه.

اما اگر بخوایم بگیم پوشه Finance حداکثر ۱۰۰ گیگابایت ظرفیت داشته باشه، باید سراغ قابلیتی مثل File Server Resource Manager (FSRM) بریم که امکان تعریف Quota برای مسیرهای مشخص و مدیریت مصرف پوشه‌ها رو فراهم می‌کنه.

در محیط‌های سازمانی، تفاوت این دو قابلیت اهمیت زیادی داره.
Soft Quota و Hard Quota
در تنظیمات Disk Quota ویندوز، دو رفتار اصلی وجود داره:
۱. محدودیت نرم (Soft Limit)
در این حالت، ویندوز مصرف کاربر رو رصد می‌کنه و می‌تونه هنگام عبور از حد تعیین‌شده، رویداد ثبت کنه یا هشدارهای لازم رو ایجاد کنه؛ اما الزاماً جلوی مصرف بیشتر رو نمی‌گیره.
۲. محدودیت سخت (Hard Limit)
در این حالت، مدیر سیستم مشخص می‌کنه که کاربر نباید از سقف تعیین‌شده عبور کنه. وقتی کاربر به این محدودیت برسه، امکان نوشتن اطلاعات بیشتر روی Volume ممکنه با خطا مواجه بشه.
برای مثال، اگر برای یک کاربر محدودیت سخت ۱۰ گیگابایت تعریف کرده باشیم، ویندوز اجازه نمی‌ده مصرف قابل محاسبه اون کاربر از این سقف عبور کنه.
البته رفتار دقیق سیستم به تنظیمات Quota و نوع عملیات نوشتن بستگی داره.

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

همچنین Disk Quota استاندارد NTFS برای کنترل مصرف بر اساس کاربر طراحی شده، نه برای محدودکردن مستقیم اندازه هر پوشه.
به همین دلیل، در فایل‌سرورهای سازمانی معمولاً باید در کنار Disk Quota، از ابزارهایی مثل FSRM، مانیتورینگ فضای دیسک و سیاست‌های مناسب مدیریت فایل استفاده کنیم.

@JustMyLogss

تکنولوژی‌های ارتباط استوریج با سرور

در زیرساخت‌های شبکه و دیتاسنتر، سرورها به روش‌های مختلفی به فضای ذخیره‌سازی متصل می‌شوند. هر روش از نظر هزینه، عملکرد، پیچیدگی و کاربرد تفاوت‌هایی دارد.

۱. DAS (Direct Attached Storage)

در این روش، استوریج مستقیماً از طریق رابط‌هایی مثل SATA یا SAS به سرور متصل می‌شود.
کاربرد: سرورهای مستقل، دیتابیس‌های محلی و سرورهای فایل کوچک.
مزایا:
هزینه و پیچیدگی کمتر
عملکرد مناسب بدون وابستگی به شبکه ذخیره‌سازی
راه‌اندازی و عیب‌یابی ساده
معایب:
اشتراک‌گذاری دشوارتر بین چند سرور
وابستگی فضای ذخیره‌سازی به سرور متصل‌شده
محدودیت در توسعه متمرکز زیرساخت

۲. Fiber Channel (FC)

در این روش، سرورها از طریق شبکه اختصاصی FC به استوریج مرکزی متصل می‌شوند.
کاربرد: دیتاسنترهای بزرگ، مجازی‌سازی و سرویس‌های سازمانی حساس.
مزایا:
عملکرد بالا و تأخیر کم
شبکه اختصاصی برای ترافیک ذخیره‌سازی
پشتیبانی از افزونگی و مسیرهای جایگزین
معایب:
هزینه بالای تجهیزات اختصاصی
نیاز به دانش فنی برای پیکربندی
پیچیدگی مدیریت و عیب‌یابی شبکه SAN

۳. FCoE (Fiber Channel over Ethernet)

در این روش، فریم‌های FC روی بستر Ethernet منتقل می‌شوند تا ترافیک شبکه و ذخیره‌سازی بتوانند از زیرساخت فیزیکی مشترک استفاده کنند.
کاربرد: دیتاسنترهایی که قصد دارند ترافیک FC و Ethernet را همگرا کنند.
مزایا:
کاهش تعداد کابل‌ها و برخی تجهیزات
استفاده مشترک از زیرساخت فیزیکی شبکه
حفظ پروتکل و دستورات FC
معایب:
نیاز به تجهیزات سازگار با FCoE
پیکربندی پیچیده‌تر Ethernet و قابلیت‌های DCB
محدودیت در انتخاب تجهیزات و وابستگی به معماری خاص

۴. iSCSI

در این روش، دستورات SCSI از طریق TCP/IP روی شبکه Ethernet منتقل می‌شوند و سرور به فضای ذخیره‌سازی بلوکی دسترسی پیدا می‌کند.
کاربرد: سازمان‌های کوچک و متوسط، مجازی‌سازی و راه‌اندازی SAN با استفاده از شبکه IP.
مزایا:
هزینه معمولاً کمتر نسبت به SAN مبتنی بر FC
استفاده از تجهیزات رایج Ethernet
راه‌اندازی و توسعه نسبتاً ساده
امکان دسترسی چند سرور به استوریج مرکزی
معایب:
وابستگی عملکرد به کیفیت شبکه
احتمال افزایش تأخیر در شبکه پرترافیک
نیاز به طراحی مناسب پهنای باند و افزونگی
ضرورت مدیریت امنیت و دسترسی‌ها

@JustMyLogss

تفاوت Authoritative و Non-Authoritative در DNS
یکی از مفاهیم مهم DNS که توی مدیریت شبکه و Windows Server

برای اینکه بهتر متوجه بشیم، باید بدونیم DNS Serverها همیشه اطلاعات رو از یک منبع دریافت نمی‌کنن و هر سرور هم لزوماً مسئول نگهداری اطلاعات تمام دامنه‌ها نیست.
1. Authoritative Answer چیست؟

وقتی یک DNS Server برای یک دامنه یا Zone پاسخ Authoritative می‌ده، یعنی جواب رو بر اساس اطلاعاتی ارائه می‌کنه که برای اون Zone مرجع معتبر محسوب می‌شن.

برای مثال، فرض کنید توی شبکه سازمانی یک DNS Zone با نام زیر داریم:
corp.local
و داخل این Zone رکورد زیر تعریف شده:

server01.corp.local    A    192.168.1.10

اگر DNS Server مسئول این Zone از اطلاعات خودش برای جواب دادن به Query مربوط به server01.corp.local استفاده کنه، جواب Authoritative محسوب می‌شه.

در واقع، این سرور مسئول نگهداری اطلاعات اون Zone هست و پاسخ رو از داده‌های معتبر خودش ارائه می‌ده.

Authoritative بودن به این معنی نیست که سرور حتماً روی اینترنت قرار داره یا مالک دامنه است. توی شبکه داخلی سازمان هم می‌تونیم DNS Server داشته باشیم که برای Zoneهای داخلی مثل corp.local مرجع معتبر باشه.

2. Non-Authoritative Answer چیست؟
حالا فرض کنید یک کلاینت می‌خواد آدرس www.example.com رو پیدا کنه و درخواستش رو به DNS Server سازمان ارسال می‌کنه.

DNS Server سازمان مسئول Zone مربوط به example.com نیست؛ اما می‌تونه از طریق Cache خودش یا با پرس‌وجو از DNS Serverهای دیگه، آدرس موردنظر رو پیدا کنه و به کلاینت برگردونه.

در این حالت، پاسخ معمولاً Non-Authoritative خواهد بود.
یعنی سرور پاسخ‌دهنده لزوماً مرجع اصلی اطلاعات اون Zone نیست و ممکنه پاسخ رو از Cache یا فرآیند حل نام به دست آورده باشه.

Non-Authoritative به معنی اشتباه بودن پاسخ نیست. ممکنه پاسخ کاملاً درست باشه، اما از سروری دریافت شده باشه که برای اون Zone مرجع معتبر محسوب نمی‌شه.

3. DNS Server چطور جواب رو پیدا می‌کنه؟
برای اینکه موضوع بهتر جا بیفته، باید با دو مفهوم Recursive و Authoritative DNS آرو بلد باشیم.
Authoritative DNS Server مسئول نگهداری اطلاعات یک یا چند Zone مشخصه.
Recursive Resolver درخواست کلاینت رو دریافت می‌کنه و تلاش می‌کنه پاسخ نهایی رو پیدا کنه. اگر پاسخ در Cache موجود نباشه، ممکنه از DNS Serverهای مختلف سؤال بپرسه تا به سرور مرجع برسه.
برای مثال، فرض کنیم کلاینت می‌خواد آدرس www.example.com رو پیدا کنه.
روند کلی می‌تونه به این شکل باشه:
1. کلاینت درخواست DNS رو برای سرور تنظیم‌شده روی سیستم ارسال می‌کنه.

2. DNS Server ابتدا Cache خودش رو بررسی می‌کنه.
3. اگر پاسخ معتبر و قابل استفاده‌ای در Cache وجود داشته باشه، می‌تونه همون رو برگردونه.
4. اگر پاسخ وجود نداشته باشه و Recursion فعال باشه، Resolver فرآیند پیدا کردن پاسخ رو شروع می‌کنه.
5. Resolver ممکنه از Root Server، سرورهای دامنه سطح بالاتر مثل .com و در نهایت Authoritative Name Server دامنه سؤال بپرسه.
6. پاسخ رو دریافت می‌کنه، در صورت امکان در Cache نگه می‌داره و به کلاینت برمی‌گردونه.

@JustMyLogss

Libertix is a Windows application that installs a supported Debian/Ubuntu-family desktop system alongside an existing Windows system. It handles the Windows-side preparation, boots a purpose-built live environment, installs the selected distribution and configures a dual-boot menu for either BIOS/MBR or UEFI/GPT machines.



https://github.com/ekimiateam/libertix

DNSSEC و HTTPS؛ دو لایه امنیتی در برابر حملات MITM
یکی از سناریوهای مهم در حملات MITM یا Man-in-the-Middle، دست‌کاری پاسخ‌های DNS برای هدایت کاربر به یک سرور جعلیه.

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

در این شرایط، کاربر ممکنه تصور کنه وارد سایت اصلی بانک شده و اطلاعات ورودش رو وارد کنه. اما سؤال اینجاست که چطور می‌شه جلوی چنین حمله‌ای رو گرفت؟

۱. DNSSEC؛ جلوگیری از جعل پاسخ DNS

DNSSEC با استفاده از امضای دیجیتال، اصالت و یکپارچگی اطلاعات DNS رو بررسی می‌کنه. یعنی Resolver می‌تونه تشخیص بده اطلاعات دریافتی معتبر هستن یا در مسیر دست‌کاری شدن.

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

البته DNSSEC ترافیک رو رمزنگاری نمی‌کنه و به‌تنهایی مانع تمام روش‌های جعل DNS نمی‌شه؛ وظیفه اصلی اون اعتبارسنجی داده‌های DNS هست.

۲. HTTPS؛ محافظت از ارتباط با سرور

حالا فرض کنیم به هر دلیلی، کاربر به IP سرور مهاجم هدایت شده. اینجا HTTPS اهمیت پیدا می‌کنه.

وقتی مرورگر می‌خواد به آدرس اصلی بانک متصل بشه، گواهی TLS سرور رو بررسی می‌کنه تا مطمئن بشه گواهی برای همون دامنه معتبره و زنجیره اعتماد اون تأیید می‌شه.

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

البته اگه کاربر هشدار رو نادیده بگیره، دستگاهش آلوده باشه یا مهاجم به گواهی معتبر یا زیرساخت مورداعتماد دسترسی پیدا کرده باشه، شرایط می‌تونه متفاوت باشه.
تفاوت اصلی DNSSEC و HTTPS چیه؟

DNSSEC بررسی می‌کنه پاسخ DNS معتبره و اطلاعاتش دست‌کاری نشده.
HTTPS هویت سرور رو از طریق گواهی TLS بررسی می‌کنه و از محرمانگی و یکپارچگی ارتباط محافظت می‌کنه.

به زبان ساده، DNSSEC کمک می‌کنه کاربر از طریق پاسخ جعلی DNS به مقصد اشتباه هدایت نشه؛ HTTPS هم کمک می‌کنه سرور مقصد نتونه به‌راحتی خودش رو جای دامنه اصلی جا بزنه.

DNSSEC و HTTPS جایگزین یکدیگر نیستن، بلکه دو لایه امنیتی مکمل هستن. DNSSEC امنیت فرایند دریافت اطلاعات DNS رو افزایش می‌ده و HTTPS از ارتباط بین مرورگر و سرور محافظت می‌کنه.

نکته مهم اینه که معتبر بودن پاسخ DNS لزوماً به معنی امن بودن ارتباط نیست؛ همون‌طور که استفاده از HTTPS هم به معنی سالم بودن تمام فرایند DNS نیست.
در امنیت شبکه، باید چند لایه دفاعی رو کنار هم داشته باشیم تا احتمال موفقیت حملات MITM کاهش پیدا کنه.

@JustMyLogss

GlobalNames Zone در Windows Server DNS

یکی از قابلیت‌های DNS در ویندوز سرور، GlobalNames Zone یا GNZ هست که برای مدیریت نام‌های کوتاه در شبکه‌های سازمانی استفاده می‌شه.

به‌صورت عادی، برای دسترسی به یک سرور باید از نام کامل اون مثل srv-file01.company.local استفاده کنیم؛ اما با GlobalNames می‌تونیم نام‌های کوتاهی مثل files رو تعریف کنیم تا کاربران راحت‌تر به سرورها دسترسی داشته باشن.
مثال کاربردی در محیط MCSA
فرض کنید توی شبکه شرکت سه سرور داریم:
srv-dc01.company.local
srv-file01.company.local
srv-backup01.company.local
می‌خوایم کاربران بتونن با اسم‌های dc، files و backup به این سرورها دسترسی داشته باشن، بدون اینکه هر بار نام کاملشون رو وارد کنن.

۱. ساخت GlobalNames Zone
ابتدا روی DNS Server که عضو Domain هست و دسترسی لازم رو داریم، PowerShell رو با دسترسی Administrator باز می‌کنیم و دستور زیر رو اجرا می‌کنیم:

Add-DnsServerPrimaryZone `
  -Name "GlobalNames" `
  -ReplicationScope "Forest"

با این دستور یک Primary Zone به نام GlobalNames ساخته می‌شه که اطلاعاتش در سطح Forest از طریق Active Directory Replicate می‌شه.

روش جایگزین با CMD:

dnscmd localhost /ZoneAdd GlobalNames /DsPrimary /forest

این دو روش جایگزین همدیگه هستن؛ لازم نیست هر دو رو اجرا کنیم.

۲. فعال‌سازی قابلیت GlobalNames
بعد از ساخت Zone، دستور زیر رو در CMD با دسترسی Administrator اجرا می‌کنیم:

dnscmd localhost /Config /EnableGlobalNameSupport 1

این دستور پشتیبانی از GlobalNames رو روی DNS Server فعال می‌کنه.
۳. ساخت رکوردهای CNAME
حالا داخل Zone ساخته‌شده، رکوردهای CNAME تعریف می‌کنیم تا نام‌های کوتاه به نام کامل سرورها اشاره کنن.

برای مثال:

Add-DnsServerResourceRecordCName `
  -ZoneName "GlobalNames" `
  -Name "files" `
  -HostNameAlias "srv-file01.company.local"

برای سرورهای دیگه هم به همین شکل رکورد می‌سازیم:

Add-DnsServerResourceRecordCName `
  -ZoneName "GlobalNames" `
  -Name "dc" `
  -HostNameAlias "srv-dc01.company.local"

Add-DnsServerResourceRecordCName `
  -ZoneName "GlobalNames" `
  -Name "backup" `
  -HostNameAlias "srv-backup01.company.local"

دقت کنید که نام company.local باید با نام دامنه واقعی شبکه جایگزین بشه.

۴. تست عملکرد
برای بررسی ساخته شدن Zone:

Get-DnsServerZone -Name "GlobalNames"

برای مشاهده رکوردهای داخل Zone:

Get-DnsServerResourceRecord -ZoneName "GlobalNames"

و برای تست Resolve شدن نام:

Resolve-DnsName files -Server 127.0.0.1

اگر تنظیمات درست باشن، باید نام files به سرور مقصد Resolve بشه.

تفاوت GlobalNames با DNS معمولی
در DNS معمولی، Resolve شدن نام‌های کوتاه معمولاً به تنظیمات DNS Suffix و نحوه Name Resolution کلاینت وابسته است؛ اما GlobalNames برای مدیریت متمرکز نام‌های کوتاه و مشخص در سطح سازمان طراحی شده.
نکته مهم اینه که GNZ جایگزین DNS معمولی نیست و برای هر نوع نام کوتاهی هم تضمین نمی‌کنه که بدون تنظیمات اضافی کار کنه.

@JustMyLogss

مبانی عملکرد DNSSEC و نقش رکوردهای اون در امنیت DNS

یکی از مشکلات DNS اینه که در حالت عادی، وقتی یک کلاینت از DNS Server آدرس IP یک دامنه رو می‌پرسه، به‌تنهایی تضمینی برای معتبر بودن پاسخ وجود نداره. همین موضوع می‌تونه زمینه حملاتی مثل DNS Spoofing و بعضی سناریوهای MITM رو فراهم کنه.

اینجاست که DNSSEC وارد می‌شه. وظیفه اصلی DNSSEC اینه که به Resolver کمک کنه صحت و اصالت پاسخ‌های DNS رو بررسی کنه و متوجه بشه اطلاعات دریافتی واقعاً معتبر هستن یا در مسیر تغییر کردن.

۱. امضای دیجیتال در DNSSEC
در DNSSEC، رکوردهای DNS با استفاده از کلیدهای رمزنگاری امضا می‌شن. این امضاها به DNS Resolver کمک می‌کنن تا بررسی کنه اطلاعات دریافت‌شده معتبر هستن یا نه.

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

۲. تفاوت ZSK و KSK
در ساختار DNSSEC معمولاً با دو نوع کلید اصلی سروکار داریم:

ZSK (Zone Signing Key)

این کلید برای امضای رکوردهای موجود در Zone استفاده می‌شه. از اونجایی که رکوردهای DNS ممکنه مرتب تغییر کنن، معمولاً مدیریت و تعویض ZSK ساده‌تر و پرتکرارتر از KSK در نظر گرفته می‌شه.

برای مثال، فرض کنیم در یک شبکه سازمانی، رکورد A مربوط به سرور مالی از آدرس 192.168.1.10 به 192.168.1.20 تغییر کنه. بعد از تغییر رکورد، امضای مربوط به اطلاعات جدید هم باید به‌درستی به‌روزرسانی بشه تا Resolver بتونه اعتبار اون رو بررسی کنه.

KSK (Key Signing Key)

این کلید برای امضای رکورد DNSKEY استفاده می‌شه؛ رکوردی که کلیدهای عمومی Zone رو معرفی می‌کنه. KSK نقش مهمی در زنجیره اعتماد DNSSEC داره و معمولاً نسبت به ZSK کمتر تغییر می‌کنه.

به زبان ساده، ZSK بیشتر برای امضای رکوردهای Zone استفاده می‌شه، اما KSK به اعتبارسنجی مجموعه کلیدهای اون Zone کمک می‌کنه.

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

۳. رکوردهای اصلی DNSSEC
برای درک بهتر DNSSEC باید چهار نوع رکورد مهم اون رو بشناسیم.

۱. DNSKEY Record

این رکورد کلیدهای عمومی موردنیاز برای اعتبارسنجی امضاهای DNSSEC رو منتشر می‌کنه. Resolver از این کلیدها برای بررسی امضای دیجیتال رکوردها استفاده می‌کنه.

۲. RRSIG Record

این رکورد شامل امضای دیجیتال مجموعه‌ای از رکوردهای DNS هست. امضا با کلید خصوصی ساخته می‌شه و Resolver با استفاده از کلید عمومی مناسب، اعتبار اون رو بررسی می‌کنه.
برای مثال، وقتی رکورد A یک دامنه امضا شده باشه، Resolver می‌تونه بررسی کنه که اطلاعات دریافتی با داده‌های امضاشده مطابقت دارن یا نه.

۳. NSEC و NSEC3 Record

یکی از قابلیت‌های مهم DNSSEC اینه که فقط وجود یک رکورد رو بررسی نمی‌کنه؛ بلکه امکان اثبات نبودن یک نام یا رکورد رو هم فراهم می‌کنه.
این موضوع مهمه، چون مهاجم ممکنه یک پاسخ جعلی با این مضمون برگردونه که یک دامنه وجود نداره. رکوردهای NSEC و NSEC3 به Resolver کمک می‌کنن اعتبار پاسخ‌های مربوط به نبودن نام رو بررسی کنه.

تفاوت این دو در نحوه ارائه اطلاعاته. NSEC اطلاعات مربوط به ترتیب نام‌های موجود در Zone رو مشخص می‌کنه و ممکنه امکان استخراج نام‌های دیگه رو فراهم کنه. اما NSEC3 از نام‌های هش‌شده استفاده می‌کنه تا این کار سخت‌تر بشه؛ البته این روش هم محافظت کامل در برابر استخراج نام‌ها ایجاد نمی‌کنه.

۴. DS Record (Delegation Signer)

این رکورد در Zone والد قرار می‌گیره و خلاصه رمزنگاری‌شده‌ای از کلید DNSKEY مربوط به Zone فرزند رو نگه می‌داره.
برای مثال، وقتی یک دامنه زیرمجموعه یک دامنه دیگه باشه، رکورد DS به Resolver کمک می‌کنه ارتباط اعتماد بین Zone والد و فرزند رو بررسی کنه.
در واقع، DS یکی از اجزای مهم زنجیره اعتماد DNSSEC هست و باعث می‌شه Resolver بتونه ارتباط بین کلیدهای Zoneهای مختلف رو بررسی کنه.
۴. زنجیره اعتماد در DNSSEC چطور کار می‌کنه؟

فرض کنیم کاربری می‌خواد آدرس IP یک سامانه بانکی رو دریافت کنه. Resolver فقط به پاسخی که از DNS Server می‌گیره اعتماد نمی‌کنه؛ بلکه در صورت فعال بودن DNSSEC Validation، امضاها و ارتباط بین کلیدها رو هم بررسی می‌کنه.
این فرآیند به‌صورت خلاصه شامل مراحل زیره:

۱. Resolver از یک نقطه اعتماد معتبر، مثل کلید ریشه DNS، شروع می‌کنه.

۲. با بررسی رکوردهای DS و DNSKEY، ارتباط اعتماد بین Zone والد و فرزند رو بررسی می‌کنه.

۳. امضاهای RRSIG مربوط به رکوردهای موردنیاز رو اعتبارسنجی می‌کنه.

۴. اگر زنجیره اعتماد و امضاها معتبر باشن، پاسخ DNS رو معتبر در نظر می‌گیره.

۵. اگر امضا نامعتبر باشه یا زنجیره اعتماد مشکل داشته باشه، Resolver اعتبارسنج معمولاً پاسخ رو به‌عنوان پاسخ معتبر قبول نمی‌کنه.

پس صرف دریافت پاسخ از یک DNS Server به معنی معتبر بودن اون نیست؛ مهم اینه که پاسخ از نظر DNSSEC هم بررسی بشه.
۵. کاربرد DNSSEC در محیط Windows Server
در شبکه‌های سازمانی، DNSSEC می‌تونه امنیت زیرساخت DNS رو افزایش بده؛ اما فعال کردن اون به‌تنهایی کافی نیست و مدیر شبکه باید کلیدها، امضاها و زنجیره اعتماد رو هم بررسی کنه.

برای مثال، فرض کنیم در یک سازمان، Zone مربوط به corp.example.com با DNSSEC امضا شده. صرف وجود رکوردهای DNSKEY و RRSIG به معنی کامل بودن زنجیره اعتماد نیست. اگر ارتباط اعتماد با Zone والد به‌درستی برقرار نشده باشه، Resolver ممکنه نتونه پاسخ‌ها رو معتبر تشخیص بده.

از طرف دیگه، اگر DNSSEC به‌درستی پیکربندی شده باشه، احتمال پذیرش پاسخ‌های جعلی DNS کاهش پیدا می‌کنه؛ چون Resolver می‌تونه امضاهای نامعتبر رو تشخیص بده.

نکته مهم: DNSSEC جایگزین HTTPS نیست.
DNSSEC صحت و اصالت اطلاعات DNS رو بررسی می‌کنه، اما ارتباط بین مرورگر و وب‌سایت رو رمزنگاری نمی‌کنه. در مقابل، HTTPS با استفاده از TLS از محرمانگی و یکپارچگی ارتباط محافظت می‌کنه و هویت سرور رو هم براساس گواهی دیجیتال بررسی می‌کنه.

پس این دو فناوری مکمل هم هستن، نه جایگزین یکدیگر.

@JustMyLogss

سناریوی عملی: اعتبارسنجی DNSSEC از Root تا دامنه مقصد
فرض کنیم یک کاربر در شبکه سازمان می‌خواد وارد سایت www.example.com بشه.

سیستم برای پیدا کردن IP سایت، از DNS Resolver استفاده می‌کنه و این Resolver هم باید اعتبار پاسخ دریافتی رو بررسی کنه.

برای اینکه بهتر متوجه مسیر اعتبارسنجی بشیم، فرض می‌کنیم DNSSEC برای دامنه مقصد به‌درستی فعال شده و Resolver هم قابلیت DNSSEC Validation رو داره.

مرحله اول: شروع از Root Zone

Resolver از نقطه اعتماد اولیه خودش، یعنی کلید معتبر Root Zone، شروع می‌کنه. این کلید از قبل به‌عنوان Trust Anchor در Resolver تنظیم شده.

مرحله دوم: اعتبارسنجی TLD
Resolver اطلاعات مربوط به دامنه سطح بالای .com رو دریافت می‌کنه. رکورد DS مربوط به .com در Root Zone قرار داره و با استفاده از اطلاعات معتبر Root Zone بررسی می‌شه.
سپس Resolver رکورد DNSKEY مربوط به .com رو دریافت می‌کنه و بررسی می‌کنه که با DS موجود در Root Zone مطابقت داشته باشه. بعد از تأیید این ارتباط، امضاهای معتبر مربوط به اطلاعات .com قابل بررسی هستن.

مرحله سوم: اعتبارسنجی دامنه مقصد

حالا Resolver سراغ example.com می‌ره. رکورد DS این دامنه در Zone مربوط به .com قرار داره.
Resolver ابتدا اعتبار DS رو با استفاده از اطلاعات معتبر .com بررسی می‌کنه. بعد رکورد DNSKEY دامنه example.com رو دریافت می‌کنه و تطبیق اون با DS رو بررسی می‌کنه.
اگر این مرحله موفق باشه، Resolver می‌تونه از کلید معتبر دامنه برای بررسی امضاهای رکوردهای اون استفاده کنه.

مرحله چهارم: بررسی رکورد A
در این مرحله Resolver رکورد A مربوط به www.example.com رو دریافت می‌کنه. این رکورد شامل آدرس IPv4 سایت هست.
Resolver با استفاده از کلید عمومی معتبر دامنه، رکورد RRSIG مربوط به مجموعه رکوردهای A رو بررسی می‌کنه. اگر امضا معتبر باشه، در بازه زمانی مجاز قرار داشته باشه و زنجیره اعتماد هم سالم باشه، پاسخ به‌عنوان پاسخ معتبر پذیرفته می‌شه.

مرحله پنجم: نتیجه اعتبارسنجی

اگر تمام مراحل موفق باشن، Resolver آدرس IP رو در اختیار کلاینت قرار می‌ده. اما اگر مثلاً رکورد A دست‌کاری شده باشه و امضای معتبر نداشته باشه، Resolver اعتبارسنج باید پاسخ رو رد کنه.

نکته مهم اینه که وجود رکوردهای DS، DNSKEY و RRSIG به‌تنهایی کافی نیست؛ ارتباط این رکوردها باید از طریق زنجیره اعتماد به یک Trust Anchor معتبر برسه.
جمع‌بندی سناریو

Root Trust Anchor → DS مربوط به .com → DNSKEY مربوط به .com → DS مربوط به example.com → DNSKEY مربوط به example.com → RRSIG رکورد A

در نهایت، Resolver بررسی می‌کنه که آیا پاسخ DNS واقعاً از یک زنجیره اعتماد معتبر عبور کرده یا خیر. به همین دلیل، DNSSEC می‌تونه جلوی پذیرش بسیاری از پاسخ‌های جعلی DNS رو بگیره؛ البته به شرطی که اعتبارسنجی به‌درستی فعال و پیکربندی شده باشه.

@JustMyLogss