Poprosiłem hostera o dodanie trzech subdomen, z których wszystkie wskazują adres IP rekordu A. Wygląda na to, że po prostu dodał rekord DNS z symbolami wieloznacznymi, ponieważ każda losowa subdomena rozwiązuje się teraz z moim adresem IP. Jest to dla mnie OK z technicznego punktu widzenia, ponieważ nie ma żadnych poddomen wskazujących nigdzie indziej. Z drugiej strony nie lubię, żeby nie robił tego, o co prosiłem. Zastanawiam się więc, czy istnieją inne powody, aby mu to zmienić. Czy są jakieś?
Jedynym minusem, który znalazłem, jest to, że ktoś może link do mojej witryny przy użyciu http://i.dont.like.your.website.mywebsite.tld
.
domain-name-system
subdomain
wildcard
problemator
źródło
źródło
*.blog.example.com
, don musisz skonfigurować każdy z nich osobno.Odpowiedzi:
Jeśli kiedykolwiek umieścisz komputer w tej domenie, dostaniesz dziwne awarie DNS, w których gdy spróbujesz odwiedzić jakąś losową stronę w Internecie, zamiast tego dotrzesz do swojej.
Zastanów się: jesteś właścicielem domeny
example.com
. Skonfigurujesz stację roboczą i nadasz jej nazwę. ... powiedzmy Powiedzmy,yukon.example.com
. Teraz zauważysz,/etc/resolv.conf
że ma linię:Jest to wygodne, ponieważ oznacza, że możesz wyszukiwać nazwy hostów, np.
www
Które będą wyszukiwaćwww.example.com
automatycznie. Ma to jednak ciemną stronę: jeśli odwiedzisz, powiedzmy, Google, będzie szukałwww.google.com.example.com
, a jeśli masz wieloznaczny DNS, rozwiąże to twoją witrynę i zamiast dotrzeć do Google, skończysz na własnej stronie.Dotyczy to w równym stopniu serwera, na którym prowadzisz swoją stronę internetową! Jeśli kiedykolwiek będzie musiał wywoływać usługi zewnętrzne, wówczas wyszukiwanie nazw hostów może zakończyć się niepowodzeniem w ten sam sposób. Tak
api.twitter.com
na przykład nagle stajeapi.twitter.com.example.com
trasy bezpośrednio do Twojej strony, no i oczywiście nie powiedzie się.Dlatego nigdy nie używam wieloznacznego DNS.
źródło
.local
nie jest zarezerwowany i nie powinien być używany. Takie postępowanie narusza RFC i wcale nie jest konieczne. Najlepszą praktyką jest użycie delegowanej subdomeny trzeciego poziomu dla wewnętrznych zasobów, takich jakinternal.company.com
. Tylko dlatego, że często coś widzisz, nie robi to dobrze..local
? Przeczytałem ten RFC co najmniej kilkanaście razy z ludźmi, którzy używają go w tym argumencie i mogę powiedzieć z całą pewnością, że go nie ma..local
domyślnie naprawdę sprawiał, że MS wyglądało pod tym względem na bałagan. SBS został dostarczony z tą konfiguracją, ponieważ był przeznaczony dla klientów nietechnicznych o niskiej wiedzy technicznej. Była to ścieżka najmniejszego oporu, ale faktyczni doktorzy AD zalecają poddomenę trzeciego poziomu już w erze W2K.Osobiście nie lubię tego. Zwłaszcza gdy w tej domenie są maszyny. Literówki nie są zaznaczone, błędy są mniej oczywiste ... ale nie ma w tym nic zasadniczo złego.
Niech Twój serwer HTTP przekieruje wszystkie takie żądania na właściwe, kanoniczne adresy lub w ogóle nie odpowie. Dla Nginx byłoby to coś takiego :
a potem zwykłe
źródło
Wszystko zależy od opinii. Dla mnie nie jest to zła praktyka.
Tworzę aplikację dla wielu dzierżawców, która korzysta z bazy danych dla każdego dzierżawcy. Następnie wybiera bazę danych do użycia na podstawie poddomeny.
Na przykład
milkman.example.com
użyjetenant_milkman
bazy danych.Tak mam oddzielone tabel dla każdego najemcy, jak,
tenant_milkman.users
,tenant_fisherman.users
,tenant_bobs_garage.users
, który moim zdaniem jest ogromny wiele łatwiej utrzymać dla tej konkretnej aplikacji, zamiast wszystkich użytkowników ze wszystkich firm w tej samej tabeli.[edit - Michael Hampton has a good point]
Biorąc to pod uwagę, jeśli nie masz konkretnego powodu, aby zaakceptować dowolną (zmienną) subdomenę, tak jak ja, to nie powinieneś ich akceptować.
źródło
tenant_
. Upewniłem się, że aplikacja nie może się nawet z nimi połączyć.Kolejnym problemem jest SEO: jeśli wszystkie
*.example.com
przedstawiają tę samą treść, twoja witryna będzie źle przywoływana, przynajmniej przez Google ( https://support.google.com/webmasters/answer/66359 ).źródło
To naprawdę zły pomysł, załóżmy, że jeśli chcesz hostować jedną subdomenę a.firma.com na jednym serwerze WWW, a b.firma.com na innym serwerze WWW, może być innym usługodawcą internetowym. Co będziesz robić Tak więc DNS z symbolami wieloznacznymi nie jest opcją, powinien być precyzyjny, utwórz rekord A dla każdej subdomeny i wskazuje odpowiedni adres IP. Istnieją szanse na przeniesienie twojego serwera internetowego z jednego ISP na innego ISP, co w takim przypadku zrobisz?
źródło
Wiem, że to stare pytanie, jednak chciałbym podzielić się z rzeczywistym przykładem tego, gdzie używanie symboli wieloznacznych może powodować problemy. Zamierzam jednak zmienić nazwę domeny, a także ukryć pełny rekord SPF, aby uniknąć wstydu.
Pomagałem komuś, kto miał problemy z DMARC, w ramach kontroli zawsze sprawdzam rekord DMARC z DIG
Ten sam wynik uzyskałem również, gdy szukałem ich rekordu DKIM.
W rezultacie wiadomości e-mail wysłane z tej domeny otrzymają błąd DKIM, ponieważ moduł DKIM spróbuje parsować rekord SPF dla klucza DKIM i zawiedzie, a także dostanie Permerror dla DMARC z tego samego powodu.
Domeny z symbolami wieloznacznymi mogą wydawać się dobrym pomysłem, ale skonfigurowane nieprawidłowo mogą powodować różnego rodzaju problemy.
źródło
Nie i w przeciwieństwie do innych uważam, że jest to dobra praktyka.
Większość użytkowników Internetu w pewnym momencie dotyka nazwy DNS. Będą pisać
ww.mycompany.com
lubwwe.mycompany.com
Co wolisz, aby „ups, nie mogliśmy znaleźć tej witryny” lub aby otworzyli twoją główną stronę główną? Zaleca się, aby częściej nie wyświetlać głównej strony głównej. To właśnie robi DUŻO ludzi.Nawet jeśli ktoś umieści do
i.dont.like.your.website.whatever.com
niego link , nadal wyświetli twoją stronę główną, a właściwie tego właśnie chcesz. W końcu nie mogą zmusić teji.dont....
witryny do przejścia na ich serwer, nadal kontrolujesz routing DNS, więc trafia on na twój.źródło
Myślę, że najlepszym powodem, aby nie mieć wieloznacznego rekordu DNS w pierwszej kolejności, jest uniknięcie przekazania adresu IP serwera potencjalnemu napastnikowi i ograniczenie narażenia na ataki DDOS. Jest to również zalecane przez Cloudflare: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/
źródło