Puncte:0

De ce AWS Route 53 / Application Load balancer rezolvă un subdomeniu pe mai multe niveluri

drapel ru

În AWS, reziliez TLS la un Application Load Balancer. Am configurat un certificat TLS wildcard cu AWS' Certificate Manager (ACM), de ex. *.example.com. Am rezolvarea AWS Route 53 *.example.com, dar nu am nimic pentru *.*.example.com deoarece nu am nevoie de asta.

Știu că nu puteți configura certificate wildcard pentru domenii cu mai multe niveluri, cum ar fi *.*.example.com.

https://x.example.com este totul bine și răspunde cu un certificat valabil. Primesc o eroare de certificat cu https://y.x.example.com, ceea ce are sens. Nu am nevoie să deservesc subdomenii cu mai multe niveluri, cum ar fi *.*.example.com.

Aș dori să pot bloca toate solicitările de domenii pe mai multe niveluri, cum ar fi https://y.x.example.com sau pur și simplu nu rezolvă ruta 53. Practic vreau o regulă care spune orice gazdă pentru https://*.*.example.com returnați 404 sau pentru ca Gazda să nu fie rezolvată.

În aplicația de echilibrare a încărcăturii am 2 ascultători portul 80 și portul 443.

Pot configura o regulă pentru ascultătorul portului 80 care funcționează bine pentru http://x.y.example.com și pot returna un 404, când configurez aceeași regulă pentru portul 443 nu funcționează. Ceea ce cred că are sens, deoarece browserul nu poate finaliza strângerea de mână TLS.

Dacă completez un nslookup pentru x.example.com și y.x.example.com Primesc aceleași NameServers, nu m-am așteptat ca Route 53 să se rezolve y.x.example.com.

Așadar, caut răspuns la una dintre cele două întrebări:

  1. Cum se configurează AWS Load balancer pentru a bloca toate subdomeniile cu mai multe niveluri cu caractere wildcard pe portul 443?
  2. De ce se rezolvă Route 53 y.x.example.com/ cum să opresc rezolvarea Route 53 la fel?
Puncte:0
drapel cn
  1. Dacă este vorba în special despre cazul HTTPS/TLS, nu văd că acest lucru este posibil în vreun fel semnificativ.
    Dacă nu aveți un certificat valid pentru numele la care clientul încearcă să se conecteze, nu aveți mijloacele de a trimite un răspuns valid (cum ar fi răspunsul 404 menționat în întrebare) în primul rând, indiferent de configurație pe partea serverului.
    Pentru cazul HTTP simplu, este posibil să faceți ceva asemănător cu ceea ce a fost cerut pe baza unui Starea gazdei, dar nu sunt sigur că este de fapt posibil să distingem cazul cu un singur nivel și cazul cu mai multe niveluri acolo. Oricum, nu sunt sigur că cazul HTTP simplu este atât de interesant în zilele noastre.

  2. Așa funcționează metacaracterele în DNS. Căutarea unui nume DNS care nu face parte dintr-o ramură existentă a arborelui (indiferent dacă una sau mai multe etichete lipsesc) se va potrivi cu o înregistrare wildcard deasupra acestuia.
    De asemenea, este de remarcat faptul că * funcționează ca wildcard numai atunci când este eticheta cea mai din stânga. *.example.com funcționează ca un wildcard, *.foo.example.com funcționează ca un wildcard, dar foo.*.example.com, foo*.example.com sau *foo.example.com nu sunt wildcards în DNS.
    Nu cred că aveți un mod practic de a folosi metacaracterele în timp ce obțineți funcționalitatea „un singur nivel” pe care o solicitați (cu metacaracterele DNS în general sau Route53 în special). Luați în considerare, în schimb, să adăugați numele specifice de care aveți nevoie de fapt (dinamic, dacă este necesar), sau, altfel, să trăiți cu comportamentul obișnuit cu wildcard.

În general, bănuiesc că cea mai bună opțiune este să nu folosiți wildcard-uri în DNS și apoi să nu aveți problema clienților care se conectează la ELB folosind aceste nume nedorite.

Patrick Mevzek avatar
drapel cn
+1 la „cea mai bună opțiune este să nu folosiți metacaracterele în DNS”. Ele creează adesea mai multe probleme decât soluții. Au fost create într-un moment în care DNS erau doar fișiere text fără niciun fel de instrumente de automatizare sau de furnizare. În zilele noastre există multe alte posibilități de a configura serverele de nume „dinamic”, fără a fi nevoie să se bazeze pe wildcards. Wildcardurile pot fi folosite, dacă sunt înțelese corect, desigur, sunt descrise complet. Cu toate acestea, fac totul mai complex, începând cu DNSSEC.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.