Обмеження максимального обмеження термінів DNS-інтерактивності перевищено в записі SPF?

Як постачальник хостингу, ми надсилаємо електронну пошту від імені наших клієнтів, тому ми допомагаємо їм налаштувати записи електронної пошти DKIM та SPF у своєму DNS, щоб отримати можливість доставки електронної пошти якнайкраще. Ми радили їм скористатися http://mail-tester.com, щоб перевірити, що вони нічого не пропустили, і мені цей інструмент дуже подобається.

Одна з проблем, з якою ми стикалися кілька разів, і я не впевнений у цьому, - це обмеження DNS для запису SPF на основі доменного імені. Тож якщо у вас це є:

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

Ви отримаєте

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

Так:

У мене є деякі питання з цього приводу.

1. Я нараховую шість доменних імен тут, а не 10, тож чому тут потрапляє "десять" DNS-запитів? Відповіли тут

2. Чи обмежує цей 10 інтерактивний термін DNS обмеження попередженням або реальною помилкою? наприклад, нам слід піклуватися? Це трохи настоює наших клієнтів, і вони надсилають нам електронну пошту для підтримки. Відповіли тут

3. Чи обмежує цей інтерактивний термін 10 DNS справжню проблему в сьогоднішній мережі? Як бачите, цей клієнт має безліч послуг, що надсилають їм електронні листи, і всі вони є законними. Можливо, цей ліміт DNS був встановлений у 2000 році, коли делегування таких електронних служб не було поширеним?

Так, ми можемо змусити наших клієнтів змінити включення до IP-адреси у записі SPF, але це ставить нас перед обов'язком, якщо ми коли-небудь змінимо IP-адреси, купа речей клієнтів порушиться. Дійсно не хочу цього робити ..

Які обхідні шляхи існують для цього?

1. В основному вже відповіли, будь ласка, зверніть увагу, включаючи Google, цей спосіб є неправильним - ви хочете використовувати _spf.google.comабо стягувати штраф за переадресацію:

   ○ → host -t txt aspmx.googlemail.com
   aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
   
   ○ → host -t txt _spf.google.com
   _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
   

Цей пошук споживає 5/10 все самостійно - 4/10 все одно смокче, але на 20% менше.

2. Він припинить обробку і поверне постійну помилку - вирішувати, як вона хоче ставитись до постійної помилки, вирішуватиме двигун, що використовує SPF.

3. Так - без обмежень на обробку механізми SPF можуть використовуватися як підсилювач DoS проти третьої сторони або другої сторони.

Як вирішення, електронні листи можуть надходити з піддомену основної властивості - community.largecorporation.comнаприклад.

1. Якщо припустити, що надлишки (на зразок декількох посилань _spf.google.comі записів, на які вона посилається) зараховуються лише один раз, я рахую 17 пошукових запитів з того місця, де ви вже шукали початковий запис. (Дивіться нижче.)

2. Він відмовляється шукати всі записи, необхідні для оцінки вашого запису SPF, оскільки це було б "занадто багато роботи". Імовірно, це означає, що він поводитиметься з вашим доменом так, як ніби він не має SPF-запису (або, можливо, його відхиляє). Спеціалізація каже, що це призводить до пермерора , що залишає його досить відкритим для того, щоб отримувач міг вирішити, що робити .

3. Я думаю, що зловживання, як правило, зростають, а не зменшуються. Цей ліміт, мабуть, покликаний перешкоджати зловживаючим доменам відправника, які в противному випадку зможуть переповнити одержувача величезними ланцюжками SPF, що потенційно може призвести до DoS.

Я думаю, що в той час як аутсорсинг електронної пошти є загальним, це насправді не так спільно для передачі електронної пошти шести різних постачальників. Вам доведеться якось оптимізувати запис SPF.
(З одного боку, посилання на aspmx.googlemail.comздається марнотратним, оскільки воно негайно переспрямовує на інше ім’я.)

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

Як зрозуміла прийнята відповідь на одне із пов’язаних питань , багато основних інструментів для систем UNIX дійсно застосовують цей ліміт (хоча і не все точно так само), тому будь-яка реалізація SPF, яка їх використовує, - що майже все в UNIX - також застосовуватиме ці межі. Системи Windows - це закон для себе, і я не можу пролити на них ніякого світла.

Вирішення проблеми полягає в тому, щоб мати роботу з cron, яка оцінює ваш ланцюжок аутсорсингових SPF-записів, виражає їх усі як ipv4 та ipv6 netblocks і вносить це у ваш запис. Не забувайте -all.

У вашому випадку ви хочете, щоб клієнти могли публікувати запис SPF, який їм потім не потрібно підтримувати. Однією з можливостей було б, щоб кожен клієнт опублікував запис, що містить redirect=spf.client1.jeffs-company.example, і тоді ви виконаєте роботу із підтримання списку неттоблоків на jeffs-company.example.

Можливо, цей ліміт DNS був встановлений у 2000 році, коли делегування таких служб електронної пошти було нечасто?

Цей ліміт ускладнює передачу вашої електронної пошти на шість-сім великих операцій; але, мабуть, якщо ви робите це, ви все-таки втратили контроль над своєю електронною поштою.

Десь, колись, якийсь програміст з субпідрядниками, про існування якого ви абсолютно не знали і над яким у вас немає контролю, втратить крапку з комою, і тонна фальшива електронна пошта буде надіслана прямо з вашим SPF імперіматуром прямо на неї. Повний контроль над вашою електронною поштою вимагає повного контролю над вашою електронною поштою, і це, на мою думку, цілком суперечить такому сильному аутсорсингу.

Інший спосіб вирішити ці проблеми - це переконання, яке саме програмне забезпечення використовується для перевірки параметрів SPF. У моєму випадку це cluebringer / PolicyD, який Mail::SPF::Serverзрештою використовує і приймає аргументи, що розслаблюють інакше жорстко обмежені межі. Проблема полягає в тому, що сам Cluebringer не підтримує розслаблення цих аргументів , але це може змінитися в майбутньому, і можна просто повідомити приймаючим послуг про ці можливості розслабити їх налаштування.

Якщо вони вирішать це зробити, звичайно, поза контролем, але це принаймні шанс.