نام (NAME)

ldns-dane - اعتبارسنجی یا ایجاد احراز هویت TLS با پروتکل DANE (RFC6698)

خلاصه دستور (SYNOPSIS)

ldns-dane [OPTIONS] verify name port

ldns-dane [OPTIONS] -t tlsafile verify

ldns-dane [OPTIONS] create name port

[ Certificate-usage [ Selector [ Matching-type ] ] ]

ldns-dane -h

ldns-dane -v

توضیحات (DESCRIPTION)

در حالت نخست: یک اتصال TLS به name:port برقرار می‌شود. رکورد(های) منبع TLSA برای name جهت احراز هویت اتصال استفاده می‌شوند.

در حالت دوم: رکورد(های) TLSA از tlsafile خوانده شده و برای احراز هویت سرویس TLS که به آن ارجاع می‌دهند، استفاده می‌شوند.

در حالت سوم: یک اتصال TLS به name:port برقرار شده و برای ایجاد رکورد(های) منبع TLSA که اتصال را احراز هویت می‌کنند به کار می‌رود. پارامترهای ایجاد رکورد منبع (rr) TLSA عبارتند از:

Certificate-usage:

0 | PKIX-TA: محدودیت مرجع صدور گواهی (CA constraint)
1 | PKIX-EE: محدودیت گواهی سرویس (Service certificate constraint)
2 | DANE-TA: اثبات لنگر اعتماد (Trust anchor assertion)
3 | DANE-EE: گواهی صادرشده توسط دامنه (پیش‌فرض)

Selector:

0 | Cert: گواهی کامل
1 | SPKI: SubjectPublicKeyInfo (پیش‌فرض)

Matching-type:

0 | Full: بدون استفاده از هش
1 | SHA2-256: SHA-256 (پیش‌فرض)
2 | SHA2-512: SHA-512

گزینه‌ها (OPTIONS)

-4

برقراری اتصال TLS فقط از طریق IPv4.

-6

برقراری اتصال TLS فقط از طریق IPv6.

-a address

برای تحلیل یا حل کردن name تلاش نکن، بلکه به جای آن به address متصل شو.

این گزینه ممکن است بیش از یک بار مشخص شود.

-b

چاپ در قالب "name. TYPE52 \# size hexdata" به جای قالب نمایشی TLSA.

-c certfile

اتصال TLS به name:port برقرار نکن، بلکه در عوض گواهی (یا زنجیره گواهی) موجود در certfile را احراز هویت کن (یا برای آن رکوردهای TLSA بساز).

-d

معتبر بودن DNSSEC را فرض کن، حتی زمانی که رکوردهای TLSA به‌صورت ناامن (insecure) دریافت شده باشند یا ساختگی (bogus) باشند.

-f CAfile

استفاده از CAfile برای اعتبارسنجی.

-h

نمایش راهنمای کوتاه استفاده و خروج.

-i

امکان تعامل پس از برقراری اتصال.

-k keyfile

مشخص کردن فایلی که شامل یک رکورد منبع معتمد DNSKEY یا DS است. کلید(ها) هنگام ردیابی امضاها (یعنی در صورت مشخص شدن -S) استفاده می‌شوند.

این گزینه ممکن است بیش از یک بار مشخص شود.

همچنین، در صورتی که -k مشخص نشده باشد، و یک لنگر اعتماد پیش‌فرض (/etc/trusted-key.key) وجود داشته و حاوی یک رکورد معتبر DNSKEY یا DS باشد، از آن به عنوان لنگر اعتماد استفاده خواهد شد.

-n

نام کارساز را در گواهی بررسی و اعتبارسنجی نکن.

-o offset

هنگام ایجاد یک رکورد منبع TLSA از نوع «اثبات لنگر اعتماد» (Trust anchor assertion)، گواهی با موقعیت offset را از انتهای زنجیره اعتبارسنجی انتخاب کن. مقدار 0 به معنای آخرین گواهی است، 1 یکی مانده به آخر، 2 دومی مانده به آخر و به همین ترتیب.

هنگامی که offset برابر با -1 باشد (پیش‌فرض)، آخرین گواهی استفاده می‌شود (مشابه 0) که باید خودامضاشده (self-signed) باشد. این کار کمک می‌کند اطمینان حاصل شود که لنگر اعتماد مدنظر (خودامضاشده) واقعاً در زنجیره گواهی کارساز وجود دارد (که یکی از الزامات DANE است).

-p CApath

استفاده از گواهی‌های موجود در دایرکتوری CApath برای اعتبارسنجی.

-s

هنگام ایجاد رکوردهای منبع TLSA با کاربرد گواهی «محدودیت CA» و «محدودیت گواهی سرویس»، اعتبارسنجی انجام نده و فرض کن PKIX معتبر است.

برای «محدودیت CA» این بدان معناست که اعتبارسنجی باید با یک گواهی خودامضاشده به پایان برسد.

-S

ردیابی امضا(ها) تا رسیدن به یک کلید شناخته‌شده.

بدون این گزینه، به شبکه محلی برای ارائه یک تحلیل‌گر DNSSEC اعتماد می‌شود (یعنی بیت AD بررسی می‌شود).

-t tlsafile

خواندن رکورد(های) TLSA از tlsafile. هنگامی که name و port نیز مشخص شده باشند، فقط رکوردهای TLSA که با name، port و transport مطابقت دارند استفاده می‌شوند. در غیر این صورت، نام مالک رکورد(های) TLSA برای تعیین name، port و transport به کار می‌رود.

-T

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

-u

استفاده از پروتکل انتقال UDP به جای TCP.

-v

نمایش نسخه و خروج.

فایل‌ها (FILES)

/etc/trusted-key.key: فایلی که در صورت مشخص نشدن گزینه -k، کلیدهای معتمد برای ردیابی امضا از آن بارگذاری می‌شوند.

همچنین ببینید (SEE ALSO)

unbound-anchor(8)

نویسندگان (AUTHORS)

نوشته‌شده توسط تیم ldns به عنوان نمونه‌ای برای نحوه استفاده از ldns.

گزارش اشکال (REPORTING BUGS)

گزارش اشکالات را به <dns-team@nlnetlabs.nl> ارسال کنید.