Vraag Waarom heeft u de awverify CNAME-record voor Azure nodig?


Zie d.w.z. Hoe CNAME zo te configureren dat deze naar Azure wijst

of de tekst binnen de azure portal:

Manage custom domains text

Waarom is dit in de eerste plaats nodig? Waarom wijst de domeinnaam via een A-record  niet bewijzen dat ik de eigenaar van het domein ben?

Ik bedoel .. hoe kun je anders een DNS-record in de eerste plaats veranderen?

Welke mishandeling voorkomt deze regel?


7
2017-09-02 08:57


oorsprong


Wil je de neerwaartse stemming toelichten, zodat ik mijn vraag kan bijwerken? - Dirk Boer
Je vraagt ​​willekeurige vreemden op internet om het beleid van een bedrijf uit te leggen. Het zou veel logischer zijn om dat bedrijf te vragen. - Jenny D
Ik ben er vrij zeker van dat er eigenlijk een technische reden voor is. Mensen die veel weten over DNS en cloud, weten misschien waarom - en hebben mij en anderen veel meer inzicht gegeven in deze systemen en hun beperkingen. Daarnaast is de Azure eigenlijk verwijzend om StackOverflow te gebruiken voor vragen, dus in theorie vraag ik het ze. - Dirk Boer
Ik ben me ervan bewust dat ze hier mensen doorverwijzen. Ik ben me niet bewust van de mensen die hun hulp aanbieden omdat ze in dienst zijn van Azure. We zijn slim en behulpzaam, maar wij zijn ze niet. - Jenny D
Mijn inschatting waarom ze dit kiezen, is dat ze een ontwerpbeslissing hebben genomen toen ze hun verificatiesysteem bouwden dat het systeem naar een CNAME en niet een A-record zou zoeken. Waarom zij die beslissing hebben genomen, kunnen zij alleen maar beantwoorden. - Jenny D


antwoorden:


Als u controle hebt over een DNS-zoekopdracht voor een computer of een hostrecord kunt injecteren, kunt u een A-record voor die machine vervalsen en naar een Azure-website verwijzen (er is eigenlijk niets dat u daarmee tegenhoudt voor een VM hoewel)

Door u een cname-record te laten maken en deze onafhankelijk te verifiëren (via hun interne / openbare DNS-systeem), betekent dit dat u wel controle over het domein hebt en dat u het domein van iemand anders niet vervalst.


6
2017-09-08 03:54



Waarom werd dit antwoord geaccepteerd als het onnauwkeurig is, zegt het maar heel weinig en zijn er veel betere (en meer geaccentueerde) antwoorden? - Massimo
@Massimo lijkt er net zo opgewekte antwoorden te zijn! en voel je vrij om het te bewerken als je denkt dat het 'onnauwkeurig' is of een juist antwoord levert. Persoonlijk vond ik dat de andere antwoorden geen antwoord gaven op de vraag waarom een ​​cname wordt gebruikt, dus heb ik een antwoord bijgedragen dat de reden uitlegde. Op het moment van schrijven was er één antwoord dat niet klopte. - Michael B
De vraag was waarom een ​​CNAME wordt gebruikt in plaats van andere recordtypen, niet het basisonderwerp van "u moet wijzigingen aanbrengen in DNS om het eigendom van het domein te bewijzen"; het juiste antwoord is "omdat Azure-websites dynamische IP-adressering hebben en daarom verwijzen ze naar hun openbare namen". Bovendien, jouw punt over spoofing betekent hier niet echt iets ... - Massimo
@Massimo volgens Azure-documentatie "Azure wijst ook een virtueel IP-adres toe" en "Voor web-apps maakt u een A-record of een CNAME-record." ook: "Het IP-adres kan veranderen als u uw web-app verwijdert en opnieuw maakt, of de webapp-modus terugzet naar gratis" - De vraag "waarom is dit noodzakelijk / welk misbruik stopt het", dat is de vraag die ik heb beantwoord. het awverify-record heeft niets te maken met het verbinden met de website - het is te verifiëren (de hint staat in de naam) - Michael B


Om de controle over het domein te bewijzen, moet u wat informatie in een DNS-record in het domein plaatsen, waarmee uw Azure-account wordt geïdentificeerd.

Dergelijke informatie kan worden ingesloten in de domeinnaam waarnaar een CNAME verwijst. Het deel van het domein dat in uw bericht was weggelaten, zou ik verwachten uw specifieke Azure-account te identificeren.

U hoeft die naam eigenlijk niet geheim te houden. Het wordt tenslotte publiekelijk zichtbaar zodra u het in een DNS-record plaatst.

De reden dat ze hetzelfde niet konden doen met een A-record, is dat er onvoldoende entropie in een A-record is om dezelfde beveiliging te bereiken.

Dat betekent niet dat de CNAME de enige methode is die ze kunnen gebruiken. Andere methoden die kunnen hebben gewerkt zijn onder meer:

  • Een TXT-record
  • Een AAAA-record
  • Meerdere A-records

Persoonlijk beschouw ik een TXT-record op een subdomein dat willekeurig is gegenereerd door de verificateur als de beste methode, omdat dit het minst indringend is. Maar dat lijkt niet te worden ondersteund in uw geval.


2
2017-09-04 09:53



Hallo @kasperd, bedankt voor je gedetailleerde antwoord. Wat bedoel je met 'niet voldoende entropie'? Misschien heeft dat te maken met dat Engels niet mijn moedertaal is :) - Dirk Boer
@DirkBoer Als twee gebruikers ooit zouden proberen om voor hetzelfde domein tegelijkertijd te worden geverifieerd, zouden ze verschillende IP-adressen moeten hebben toegewezen om te weten welke van de gebruikers erin slaagden te verifiëren. En de IP-adressen kunnen beter zo verschillend zijn dat niemand per ongeluk in de ander terechtkomt doordat de gebruiker een typefout maakt. Zoiets doen op een robuuste manier vereist meer adressen dan beschikbaar zijn vanwege het tekort aan IPv4. - kasperd
@DirkBoer U kunt redelijkerwijs geen 2 ^ 16 IPv4-adressen toewijzen alleen voor dergelijke verificaties. En dat zou nog steeds maar 16 bits entropie opleveren. Met IPv6 zou je 2 ^ 80 adressen kunnen toewijzen zonder de minste zorg, wat je veel entropie zou geven, dus een AAAA-record zou werken. Een CNAME- of TXT-record zou een tekstreeks bevatten die nog meer entropie zou kunnen bevatten. - kasperd


Laat me proberen uw vraag te beantwoorden door twee zaken te geven. In beide gevallen moet u nog steeds verifiëren dat u de eigenaar bent, het is slechts een beveiligingsstap.

1) www.example.com wordt niet bezocht en niet in productie

2) www.example.com is momenteel in productie en wordt zwaar gebruikt

1) Als uw domein nu wordt ingesteld of niet wordt gebruikt / wordt geopend, kunt u een CNAME-record maken waarnaar wordt verwezen yoursite.azurewebsites.net. Nee awverify.myhost.azurewebsites.net nodig zijn.

2) Als uw domein momenteel intensief wordt gebruikt en momenteel wordt geopend en u wilt testen om te zien of Azure de wijzigingen in uw DNS-records ziet, kunt u een subdomein maken met de naam 'awverify' als in awverify.example.com en wijs het naar een gemaakt subdomein awverify.myhost.azurewebsites.net. Dit heeft geen invloed op uw huidige gebruikers die uw website bezoeken www.example.com. Nadat Azure heeft geverifieerd dat het de wijziging in CNAME ziet, kunt u gebruikers op de hoogte stellen van onderhoud en het A-record wijzigen. Als u alleen het A-record wijzigt, kan de site maximaal 8 uur als offline worden beschouwd.

Dus om uw vraag eenvoudig te beantwoorden, hoeft u deze niet te gebruiken awverify. Alleen het wijzigen van de CNAME kan ook werken. Als u alleen het A-record wijzigt, wordt al het verkeer omgeleid yourdomain.com naar yoursite.azurewebsites.net

Ik hoop dat dit helpt.


2
2017-09-02 19:26



Hallo @ Massassimo / Yudhistre, bedankt voor het uitgebreide antwoord. Maar wat ik nog steeds niet krijg - hoe verifieert een CNAME dat ik de eigenaar ben, en een A-record doet dat niet? - Dirk Boer
Een recordpunt naar IP-adressen, CNAME-records verwijzen naar namen (dit zijn aliassen). U gebruikt geen A-records om naar Azure-services te verwijzen, omdat ze dynamische IP-adressering gebruiken en een A-record moet verwijzen naar een statisch IP-adres; in plaats daarvan hebben Azure-services opgelost namen, dus u moet CNAME-records gebruiken om ernaar te verwijzen. - Massimo
U kunt eigenlijk een statisch IP-adres reserveren ( blogs.msdn.com/b/benjaminperkins/archive/2014/05/05/... ) - daarnaast vertellen ze explitly over het wijzen van een A-record naar uw IP (is d.w.z. vaak noodzakelijk voor naakte domeinen) - Dirk Boer
Dus ik neem aan dat er ergens een andere moet zijn technisch reden voor het hele awverify-proces. - Dirk Boer
Uw tweede 1) is onjuist, u kunt geen verkeer naar een website op Azure leiden, tenzij u de stap awverify hebt uitgevoerd. (Ik heb dit zojuist geverifieerd) U gaat eenvoudig naar een pagina met de tekst: "De eigenaar van de webapp heeft een aangepast domein geregistreerd om naar de Microsoft Azure App-service te verwijzen, maar heeft Azure nog niet geconfigureerd om het te herkennen." - Michael B


1) Ik heb verschillende sites ingesteld op Azure en ze hebben allemaal hetzelfde IP-adres in het A-record. Ik weet niet of het A-record IP-adres ook aan een ander account kan worden toegewezen, maar misschien is dat een mogelijkheid. Als dat het geval is, kan iemand de Azure-website van iemand anders eenvoudigweg openen door het domein in te voeren in zijn eigen Azure-dashboard. Dit is slechts een theorie, ik weet niet of het op afstand mogelijk is.

2) Zoals hierboven vermeld, is de CNAME-record eigenlijk een inert record. Het leidt geen verkeer om. Toen ik een grote site en het bijbehorende SSL-certificaat migreerde, was het een zegen om het eigendom van de awsverify te kunnen claimen, het domein en het SSL-certificaat te kunnen configureren en vervolgens alle code op Azure te kunnen testen. Weken later veranderde ik de A-record om live te gaan. Het punt is dat het A-record niet is gewijzigd tot het moment van go-live, weken na het gebruik van de awsverify om het eigendom in het domein te valideren. Dus in mijn geval was het nuttig.


0
2017-11-23 15:26





Niet dat ik het hiermee eens ben, maar hier is het antwoord dat ik rechtstreeks van Microsoft kreeg. Kort gezegd: hiermee voorkomt u dat iemand een domein toevoegt dat u bezit aan een andere Azure-webtoepassing, maar alleen in hetzelfde datacenter als uzelf. Dus in wezen zou iemand moeten proberen om een ​​domein te registreren waarvan jij de eigenaar bent EN in hetzelfde datacenter (Azure-regio) te zijn om deze bescherming bruikbaar te maken. Vanuit DNS-perspectief is het logisch, omdat ik www.microsoft.com kan toevoegen en een valse webpagina kan maken op elke webserver die ik bezit, maar als ik geen toegang heb om het DNS-record te wijzigen, betekent dit niets. Natuurlijk zou ik dit kunnen doen met een rogue DNS-server op een frauduleus toegangspunt, maar waar heb ik dan een Azure-webapp voor nodig? Ik kan een VM laten draaien en de beperking toch omzeilen. Het slaat echt nergens op en is echt alleen maar een ergernis als het tijd is om een ​​nieuwe site toe te voegen. Het proces dat nu een paar minuten duurt, vertrouwt op DNS voordat ik een domein kan toevoegen aan een webapplicatie. Dit is over het algemeen goed voor nieuwe domeinen, maar als ik een bestaand domein heb, is het lastig. Ik moet dit andere DNS-record maken en het vervolgens verwijderen nadat ik mijn domein aan mijn web-app heb toegevoegd en vervolgens de DNS-record wijzigen die ik eigenlijk wil wijzigen. Hoe dan ook, hier is het antwoord van Microsoft op waarom:

De beveiligingskwestie is, gezien dit scenario, als het iemand toestaat om uw domein aan zijn app toe te voegen voordat u het aan uw web-app kunt doen, dan kunt u uw domein niet opnieuw toevoegen vanwege een schikking, omdat Azure-webapps hetzelfde delen front-end servers binnen hetzelfde datacenter. Dus moet het elk domein / subdomein verifiëren voordat het wordt toegewezen aan een webapp. Als we websites hosten op een virtuele machine, is er geen beperking.


0
2018-04-11 15:14