Як ввести міцний (довгий) ключ DKIM у DNS?

19

Я намагаюся ввести ключ DIM 4028 біт у DNS, і, здається, я перевищую граничну кількість байтів UDP 512, а також максимальний розмір запису для запису TXT.

Як хтось належним чином створює великий ключ (мається на увазі більший закодований розмір) та імпортує його в DNS?

— goodguys_activate
джерело

Потрібна більш детальна інформація; що таке програмне забезпечення сервера DNS?

— JGurtz

1

Ви ретельно обміркували свій розмір ключа? RFC зазначає: "Перевіряючі ПОВИННІ мати змогу перевірити підписи ключами від 512 до 2048 біт, і вони МОЖНА мати можливість перевірити підписи більшими ключами". Тож ваш довгий ключ може не перевірити.

— HTTP500

@JGurtz Ми використовуємо "UltraDNS" - це розміщена послуга.

— goodguys_activate

@Jason - Ми можемо зробити 2048, але я думаю, що довжина бітів може перевищувати ліміт пакету UDP.

— goodguys_activate

1

Можливо, вам слід врахувати, що проблеми, які ви створюєте завдяки використанню незвично довгого ключа, значно переважають переваги, які ви сподіваєтеся отримати від цього.

— Джон Гарденєр

25

Потрібно розділити їх у текстовому полі. Я вважаю, що 2048 рік є практичним обмеженням для ключових розмірів. Розділіть текстове поле на частини 255 символів або менше. Для кожного розколу є накладні витрати.

Є два формати для довгих полів.

TXT "частина перша" \ "частина друга"

TXT ("частина перша" "частина друга")

Обидва вони поєднуватимуться як "частина одна частина друга". Детальніше з Zytrax.

Щоб створити запис у dkim, я вставляю файл із відкритим ключем і загортаю його у лапки.
Мій файл відкритого ключа містить наступне:

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD78Ki2d0zmOlmjYNDC7eLG3af12KrjmPDeYRr3
q9MGquKRkRFlY+Alq4vMxnp5pZ7lDaAXXwLYjN91YY7ARbCEpqapA9Asl854BCHMA7L+nvk9kgC0
ovLlGvg+hhqIPqwLNI97VSRedE60eS+CwcShamHTMOXalq2pOUw7anuenQIDAQAB

Після редагування ключа в моєму файлі зони dns з'являється наступне:

dkim3._domainkey        IN      TXT     ("v=DKIM1; t=s; p=" 
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD78Ki2d0zmOlmjYNDC7eLG3af12KrjmPDeYRr3"
"q9MGquKRkRFlY+Alq4vMxnp5pZ7lDaAXXwLYjN91YY7ARbCEpqapA9Asl854BCHMA7L+nvk9kgC0"
"ovLlGvg+hhqIPqwLNI97VSRedE60eS+CwcShamHTMOXalq2pOUw7anuenQIDAQAB")

DNS повертає його наступним чином:

 bill:~$ host -t TXT dkim3._domainkey.systemajik.com
 dkim3._domainkey.systemajik.com descriptive text "v=DKIM1\; t=s\; p=" "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD78Ki2d0zmOlmjYNDC7eLG3af12KrjmPDeYRr3" "q9MGquKRkRFlY+Alq4vMxnp5pZ7lDaAXXwLYjN91YY7ARbCEpqapA9Asl854BCHMA7L+nvk9kgC0" "ovLlGvg+hhqIPqwLNI97VSRedE60eS+CwcShamHTMOXalq2pOUw7anuenQIDAQAB"

DNS розглядає його як один довгий рядок без зайвих пробілів, де з'єднуються лінії. Усі " "послідовності ігноруються.

— BillThor
джерело

Чи можете ви навести приклад? для цього я не можу зрозуміти, як зрозуміти, що таке частина 1 та частина 2. #threadnecro

— січень

1

@janw Я додав один із своїх ключів як приклад. Цей ключ становить лише 1024 біта.

— BillThor

5

Tnx для швидкої відповіді. Але цей ключ вписується в ключ 255. Тому я все ще не розумію, як ви розділите його на кілька клавіш.

— січень

1

Не DNS ігнорує " "послідовності, і ви насправді доводите це у своїй останній цитаті. Саме розділ 3.1.3 SPF RFC 4408 визначає, що конкатенація повинна використовуватися додатками, що читають записи DNS для перевірки SPF.

— Філ

3

@Alnitak Придатним RFC для цього випадку є tools.ietf.org/html/rfc6376#section-3.6 . Рядки об'єднані без проміжків між ними. SPF та інші формати дотримуються тих же правил, що дозволяють розміщувати перерви у довільних місцях. Це можна зробити для читання чи обмеження розміру запису.

— BillThor

1

Якщо це Amazon Route 53, то не використовуйте нові рядки (лише пробіли) між шматками.

"do it" "this way"

"not like"
"this"

Дивіться /server//a/763871/80856

— Месса
джерело

1

Якщо ви використовуєте інтерфейс poweradmin для pdns, ви можете просто ввести весь рядок dkim у поле введення.

v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxtR3bw1Kbh1B7q4+5aWjTj2YEFwv230gcv+NMp4KouOSLdIr0mCMiwDZpY+7zCdks0zMXtz+F5TPij/NkSAxIKBbJqbIO3mvAhgeI0Vy5aQ5prwnIyXUj54po6AsXbv5Ud2tFbGSsdIhvWiC755d3WaFs8mdWFkpSxprlW6PobCzOWDayWGCvsNfHpjmTxHZinkd3TmLQqE/O6Nb1YnRwQwUCLioSyudV+5Bd2+rXZ2V9FYAOiK2aQi2aSTiUaLCVxft9H6xen3JDaKsuu43QMBrhydoJOCV2QaY82IxqE3GgZrlADu6YEOfotdwD2aA9GRwVB88GqdXL8HwgEGTbwIDAQAB

— Йоганнес Вінтер
джерело

0

Добре, якщо запис перевищує межу 512-байт UDP, оскільки DNS використовуватиме TCP.

Це повинно бути прозорим для користувача, але іноді помилкові пристрої брандмауера (наприклад, Cisco PIX / ASA) фільтрують / блокують ці великі запити.

— JGurtz
джерело

0

Я знаю, що ця публікація є давньою, але я знайшов її сьогодні під час запиту "DKIM 2048 бітовий ключ з UltraDNS". Моя команда DNS намагалася розділити ключ на дві частини цитатами навколо них та пробілом між ними. Це змусило UltraDNS обслуговувати 3 пакети (один в центрі був порожній), що спричинило непослідовні результати перевірки.

Що працювало для мене на панелі управління UltraDNS - це просто подати весь запис у лапках без декількох наборів лапок, роздільників тощо. Працює так, як очікувалося зараз.

— Джо Сазерленд
джерело

-1

Якщо ви використовуєте MySQL / MariaDB в якості резервного файлу DNS, як PowerDNS, ви можете змінити розмір стовпця вмісту.

Тривалість вмісту PowerDNS за замовчуванням - VARCHAR (255)

Таким чином, ваш підпис DKIM буде оброблений на 255 символів

щоб виправити це

просто змініть розмір вмісту за допомогою MySQL CLI / MariaDB CLI

mysql -u root -p

USE powerdns;
alter table records modify column content text not null;

перезапустіть службу DNS (наприклад, PowerDNS)

service pdns restart

— вебмайстер
джерело