Назад | Перейти на главную страницу

Является ли использование подстановочных DNS-записей плохой практикой?

Я попросил своего хостера добавить три поддомена, все указывающие на IP-адрес записи A. Похоже, он просто добавил DNS-запись с подстановочными знаками, потому что теперь любой случайный поддомен разрешается на мой IP-адрес. Для меня это нормально с технической точки зрения, поскольку нет никаких поддоменов, указывающих куда-либо еще. С другой стороны, мне не нравится, что он не делает то, о чем я просил. И поэтому мне интересно, есть ли другие причины сказать ему изменить это. Есть ли?

Единственный минус, который я обнаружил, это то, что кто-то может ссылаться на мой сайт, используя http://i.dont.like.your.website.mywebsite.tld.

Если вы когда-нибудь поместите компьютер в этот домен, вы получите причудливые сбои DNS, когда при попытке посетить какой-нибудь случайный сайт в Интернете вы попадете на свой.

Учтите: вы владеете доменом example.com. Вы настраиваете свою рабочую станцию ​​и даете ей имя. ... скажем так, yukon.example.com. Теперь вы заметите в его /etc/resolv.conf в нем есть строка:

search example.com

Это удобно, потому что это означает, что вы можете выполнять поиск имени хоста, например www который затем будет искать www.example.com автоматически для вас. Но у него есть и обратная сторона: если вы зайдете, скажем, в Google, он будет искать www.google.com.example.com, и если у вас есть DNS с подстановочными знаками, то это разрешится на ваш сайт, и вместо того, чтобы обращаться к Google, вы попадете на свой собственный сайт.

Это в равной степени относится и к сервер на котором вы запускаете свой веб-сайт! Если ему когда-либо придется вызывать внешние службы, поиск имени хоста может завершиться таким же образом. Так api.twitter.com например внезапно становится api.twitter.com.example.com, направляется прямо на ваш сайт и, конечно же, не работает.

Вот почему я никогда используйте подстановочные знаки DNS.

Является ли использование подстановочных DNS-записей плохой практикой?

Лично мне это не нравится. Особенно, когда в этом домене есть машины. Опечатки не проверяются, ошибки менее очевидны ... но в этом нет ничего принципиально неправильного.

Единственный минус, который я обнаружил, это то, что кто-то может ссылаться на мой сайт, используя http: //i.dont.like.your.website.mywebsite.tld.

Попросите свой http-сервер перенаправлять все такие запросы на правильные канонические адреса или вообще не отвечать. Для nginx это будет что-то вроде:

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;
    }

а затем обычный

server {
    listen  80;
    server_name mywebsite.tld;
    [...]
    }

Все зависит от мнения. Для меня это неплохая практика.

Я создаю мультитенантное приложение, которое использует базу данных для каждого клиента. Затем он выбирает базу данных для использования на основе поддомена.

Например milkman.example.com будет использовать tenant_milkman база данных.

Вот так я разделил таблицы для каждого арендатора, например, tenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.users, которое, на мой взгляд, намного проще поддерживать для этого конкретного приложения, вместо того, чтобы иметь всех пользователей из всех компаний в одной таблице.

[edit - Michael Hampton has a good point]

При этом, если вы не есть конкретная причина для принятия любого (переменного) субдомена, как у меня, тогда вы не должны принимать их.

Еще одна проблема - это SEO: если все *.example.com показывая то же содержание, ваш сайт будет плохо упоминаться, по крайней мере, со стороны Google (https://support.google.com/webmasters/answer/66359).

Это действительно плохая идея. Предположим, что если вы хотите разместить один поддомен a.company.com на одном веб-сервере, а b.company.com на другом веб-сервере, это может быть другой интернет-провайдер. Что ты сделаешь ?. Таким образом, DNS с подстановочными знаками не является вариантом, он должен быть точным, создать запись A для каждого поддомена и указать на соответствующий IP-адрес. Есть шанс перенести ваш веб-сервер от одного провайдера к другому, что в этом случае вы будете делать?

Я знаю, что это старый вопрос, однако я хотел бы поделиться реальным примером того, как использование доменов с подстановочными знаками может вызвать проблемы. Однако я собираюсь изменить доменное имя и также спрятать полную запись SPF, чтобы избежать затруднений.

Я помогал кому-то, у кого были проблемы с DMARC, в рамках проверок я всегда ищу запись DMARC с помощью DIG.

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

Я также получил тот же результат, когда искал их запись DKIM.

Следовательно, электронные письма, отправленные из этого домена, получат ошибку DKIM, поскольку модуль DKIM попытается проанализировать запись SPF для ключа DKIM и потерпит неудачу, а также получит Permerror для DMARC по той же причине.

Домены с подстановочными знаками могут показаться хорошей идеей, но неправильно настроенные они могут вызвать самые разные проблемы.

Является ли использование подстановочных DNS-записей плохой практикой?

Нет, и в отличие от других я считаю, что это хорошая практика.

Большинство интернет-пользователей в какой-то момент теребят DNS-имя. Они напечатают ww.mycompany.com или wwe.mycompany.com Что бы вы предпочли: «Ой, мы не смогли найти этот сайт» или чтобы они открыли вашу главную домашнюю страницу? Чаще всего предпочтительнее, чтобы они не открывали вашу главную домашнюю страницу. Это то, что делает МНОГО людей.

Даже если кто-то ссылку на i.dont.like.your.website.whatever.com он все равно подтянется ваш домашняя страница, которая вам и нужна. В конце концов, они не могут этого сделать i.dont.... сайт переходит на их сервер, вы по-прежнему контролируете маршрутизацию DNS, поэтому она идет на ваш.

Я думаю, что лучшая причина не иметь DNS-запись с подстановочными знаками - это, в первую очередь, избежать передачи IP-адреса вашего сервера потенциальному злоумышленнику и снизить вероятность DDOS-атак. Cloudflare также рекомендует эту настройку: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/