Domein naam zelfde als website naam

[Tsquare]

Goedemiddag,

Onze ICT-afdeling heeft een fout gemaakt bij het configureren van onze nieuwe domein.
Nu dat alles ongeveer weer werkend is zijn we erachter gekomen dat wij op onze locale netwerk niet meer op onze website kunnen komen. Dit komt omdat ons domein naam hetzelfde is geworden als onze website.
Als een client nu pingt naar bijvoorbeeld onzewebsite.nl krijgt hij het IP terug van onze server. Wij hebben geprobeerd om een "www" A record aan te maken die www.onzewebsite.nl verwijst naar het juiste ip wat onze hosting nodig heeft om de website te laten zien, maar dit werkt hedendaags niet meer. Omdat de browsers tegenwoordig www uit de url haalt. Een lege A record aanmaken is ook geen optie, omdat we er al 1 hebben die natuurlijk naar onze server zelf moet verwijzen om de gebruikers in te laten loggen binnen ons domein. We hebben geen IIS draaien op onze exchange server. Heeft iemand een oplossing om dit dns probleem op te lossen.

Met vriendelijke groet,
Tsquare

[Room42]

Je bedoelt het Windows domein? Zie dan https://serverfault.com/q...-how-can-i-get-to-my-exte

[Knee-Buckler]

^^ hierboven de link legt het goed en mooi uit dit is hoe het hoort "maar vaak ook niet gedaan wordt" en dan krijgen we het houtje touwtje effect

Ik zelf zou echt gewoon een nieuw domein opzetten met een alternatieve naam...

[pennywiser]

Je kunt geen dezelfde A records hebben, dus je zult iets moeten bedenken voor je KA.

[Knee-Buckler]

pennywiser schreef op dinsdag 17 december 2019 @ 13:25:
Je kunt geen dezelfde A records hebben, dus je zult iets moeten bedenken voor je KA.

Ja, een nieuw domein aanmaken en zorgen dat die niet hetzelfde heet als je website

[Tsquare]

Hetzelfde probleem als daar wordt geschreven inderdaad. Punt 1 en 3 wat op stackoverflow is geplaatst is geen optie, Weten jullie misschien een betere oplossing?

[pennywiser]

Knee-Buckler schreef op dinsdag 17 december 2019 @ 13:26:
[...]


Ja, een nieuw domein aanmaken en zorgen dat die niet hetzelfde heet als je website

Is dat de enige oplossing, of kan een extra subdomein/A record ook? Ik vraag het even vanwege je stelligheid?

[Ora et Labora]

Of een alternatief A record maken, bijvoorbeeld www.internet.nl of internal.onzewebsite.nl wat wijst naar jullie website.
Exact dezelfde domeinnaam en website ga je anders niet oplossen behalve IIS of een andere domein of websitenaam gebruiken.

[ Voor 5% gewijzigd door Ora et Labora op 17-12-2019 13:27 ]

[AW_Bos]

Gelukkig bestaat er voor dit soort gedoe ook een .local .tld die je in je lokale netwerk bekend maakt.
Ik ken meerdere grote bedrijven die dit gebruiken.

[ Voor 19% gewijzigd door AW_Bos op 17-12-2019 13:31 ]

[Verwijderd]

Wellicht is dit wat: https://docs.microsoft.co...plit-brain-dns-deployment

[Tsquare]

Ora et Labora schreef op dinsdag 17 december 2019 @ 13:27:
Of een alternatief A record maken, bijvoorbeeld www.internet.nl of internal.onzewebsite.nl wat wijst naar jullie website.
Exact dezelfde domeinnaam en website ga je anders niet oplossen behalve IIS of een andere domein of websitenaam gebruiken.

Het is inderdaad exact hetzelfde. Is er een manier om een alternatief A record te maken?

[pennywiser]

AW_Bos schreef op dinsdag 17 december 2019 @ 13:30:
Gelukkig bestaat er voor dit soort gedoe ook een .local .tld die je in je lokale netwerk bekend maakt.
Ik ken meerdere grote bedrijven die dit gebruiken.

Vanwege SSL issues hiermee moet je dit niet meer doen.

[Tijntje]

De verstandigste oplossing is om je domain name aan te passen.
Is geen leuke klus maar niet onmogelijk.

[tweakict]

Verwijderd schreef op dinsdag 17 december 2019 @ 13:31:
Wellicht is dit wat: https://docs.microsoft.co...plit-brain-dns-deployment

Exact; zie ook hier: https://www.mcleanit.ca/blog/case-split-horizon-dns/ voor de TS

Goed leesvoer: https://argonsys.com/micr...in-dns-on-windows-server/

[ Voor 16% gewijzigd door tweakict op 17-12-2019 13:38 ]

[Knee-Buckler]

pennywiser schreef op dinsdag 17 december 2019 @ 13:27:
[...]

Is dat de enige oplossing, of kan een extra subdomein/A record ook? Ik vraag het even vanwege je stelligheid?

Het kan natuurlijk op meerdere manieren, maar de enige goede manier is een nieuw domein aanmaken. Dit om vooral problemen in de toekomst te voorkomen.

[Tijntje]

tweakict schreef op dinsdag 17 december 2019 @ 13:37:
[...]


Exact; zie ook hier: https://www.mcleanit.ca/blog/case-split-horizon-dns/ voor de TS

Goed leesvoer: https://argonsys.com/micr...in-dns-on-windows-server/

Dit lost zijn probleem niet op.
Dit is als je vanuit intern een externe DNS naam wil omzetten naar een intern IP adres.

[Tsquare]

We zitten namelijk met het probleem dat ook al we onze domeinnaam weer om zullen gooien dat het certifcaat van de exchange dan weer zegt dat het domeinnaam niet klopt.

[BCC]

Nieuw certificaatje kopen dus.

[Tijntje]

Of Let's Encrypt gaan gebruiken, goede Windows Client om de bindings en renewals te doen
https://github.com/PKISharp/win-acme/

[tweakict]

toch lijkt mij een DNS policy in Server 2016 en hoger met split-brain configuratie de beste optie in deze. Hiermee kun je specifieke policy's toepassen op DNS verzoeken voor (www).domeinnaamextern.xyz elders laten uitkomen dan op je domeincontroller... Het is eerder gedaan en tegenwoordig een best practice voor Exchange

[iFap]

Het ziet er naar uit dat er een verkeerde design keuze is gemaakt en of dat er niet goed is nagedacht over de DNS inrichting. Dit terwijl DNS een cruciale onderdeel is van je KA omgeving. Ook zie ik hier heel veel reacties staan wat je absoluut niet zomaar moet gaan uitvoeren. Ik zou zeggen, schakel zo snel mogelijk een consultant in die je nieuwe omgeving analyseert en zo tot een oplossing kan komen. Het gebruik maken van een publieke domeinnaam als interne windows domein moet mogelijk zijn, echter moet hier wel goed over nagedacht worden.

[Tsquare]

tweakict schreef op dinsdag 17 december 2019 @ 14:42:
toch lijkt mij een DNS policy in Server 2016 en hoger met split-brain configuratie de beste optie in deze. Hiermee kun je specifieke policy's toepassen op DNS verzoeken voor (www).domeinnaamextern.xyz elders laten uitkomen dan op je domeincontroller... Het is eerder gedaan en tegenwoordig een best practice voor Exchange

We gaan dit proberen en kijken of het werkt.

[Hero of Time]

Ik heb op mijn werk exact hetzelfde. Dat ga ik oplossen door het interne domein uit te faseren en de gebruikers te migreren naar een apart subdomein. Mail hebben we bij O365, dat is geen issue. Gebruikers worden dmv UPN of een andere attribuut gekoppeld, dus dat is ook te doen.

Om de site te kunnen benaderen, heb ik als work-around tot de domeinmigratie IIS op de AD staan en als reverse proxy ingericht.

Ik weet niet waar je het SSL certificaat op je Exchange precies voor gebruikt, maar als het puur voor de mail is en niets van de interne communicatie of wat dan ook, is dat alsnog bruikbaar door je externe domeinnaam te houden zodat je certificaat gewoon geldig is. Voor andere zaken kan ik er niets over zeggen, aangezien ik geen Exchange expert ben.

Heel veel succes iig. Probeer een domein rename, want nieuw opbouwen betekend ook je on-premise Exchange opnieuw inrichten.

[Question Mark]

Tsquare schreef op dinsdag 17 december 2019 @ 13:19:
Wij hebben geprobeerd om een "www" A record aan te maken die www.onzewebsite.nl verwijst naar het juiste ip wat onze hosting nodig heeft om de website te laten zien, maar dit werkt hedendaags niet meer. Omdat de browsers tegenwoordig www uit de url haalt.

Da's toch alleen de weergave in de addressbar toch maar? (en overigens ook weer uit te schakelen).

Removing WWW and M subdomains From the Browser's Address Bar

[Room42]

Question Mark schreef op woensdag 18 december 2019 @ 11:29:
[...]

Da's toch alleen de weergave in de addressbar toch maar? (en overigens ook weer uit te schakelen).

Removing WWW and M subdomains From the Browser's Address Bar

Klopt, dit is cosmetisch. @Tsquare Waarschijnlijk redirect jullie site naar het www-loze domein. Browsers kunnen nog gewoon werken met www.host.tld.

[Tsquare]

Question Mark schreef op woensdag 18 december 2019 @ 11:29:
[...]

Da's toch alleen de weergave in de addressbar toch maar? (en overigens ook weer uit te schakelen).

Removing WWW and M subdomains From the Browser's Address Bar

probeer dit maar eens in de nieuwste chrome 79 dit werkt niet meer. Ik zie de betreffende Omnibox UI Hide Steay-State URL Scheme and Trivial er niet meer tussen staan.

https://www.ghacks.net/20...ome-browsers-address-bar/

[ Voor 19% gewijzigd door Tsquare op 18-12-2019 14:01 ]

[mrc4nl]

Tsquare schreef op dinsdag 17 december 2019 @ 13:55:
We zitten namelijk met het probleem dat ook al we onze domeinnaam weer om zullen gooien dat het certifcaat van de exchange dan weer zegt dat het domeinnaam niet klopt.

Dat kan je toch met een interne dns server oplossen?
door een aparte entry aan te maken voor het domein en stiekem laten verwijzen naar je interne ip.

[Question Mark]

Tsquare schreef op woensdag 18 december 2019 @ 13:57:
[...]


probeer dit maar eens in de nieuwste chrome 79 dit werkt niet meer. Ik zie de betreffende Omnibox UI Hide Steay-State URL Scheme and Trivial er niet meer tussen staan.

https://www.ghacks.net/20...ome-browsers-address-bar/

Zou kunnen dat het weer veranderd is, maar volgens het artikel blijft het alleen aanpassing in de weergave in de addressbar. Technisch is het nog steeds mogelijk om een A-record te maken naar www.domain.com, en die te gebruiken in een browser. Dat een browser dat weergeeft als domain.com in een adresbalk is een tweede.

[twieren]

Op wat voor platform draait jullie website? In veel gevallen is het in een dergelijke situatie, lokale domeinnaam en domeinwebsite (extern) het zelfde, mogelijk om de website te laten “luisteren” naar www. ipv zonder www.

Voorbeeld; binnen WordPress is het mogelijk om een website te laten luisteren op www en in browsers alsnog www. weer te geven en te laten gebruiken.

[Wim-Bart]

AW_Bos schreef op dinsdag 17 december 2019 @ 13:30:
Gelukkig bestaat er voor dit soort gedoe ook een .local .tld die je in je lokale netwerk bekend maakt.
Ik ken meerdere grote bedrijven die dit gebruiken.

Vroegah ja, maar dat is nog oude legacy shit wat sterk wordt afgeraden.

Gewoon een domein voor interne domein zoals:

ad.bedrijf.tld
internal.bedrijf.nl
forest.bedrijf.nl

Of wanneer je bedrijf bijvoorbeeld ABC BV heet.

ad.abcintern.nl
netbiosnaam.abcintern.nl

Maar nooit bedrijf.nl

[Bor]

pennywiser schreef op dinsdag 17 december 2019 @ 13:32:
[...]

Vanwege SSL issues hiermee moet je dit niet meer doen.

En die issues zijn?

[pennywiser]

Bor schreef op woensdag 18 december 2019 @ 20:43:
[...]


En die issues zijn?

Dat een SSL uitgever deze fqdn's niet meer accepteert. Dus moet je gaan werken met self-signed certificaten. Verbaast me wel een beetje dat dit gevraagd wordt door iemand die zich karma keizer noemt van allerlei security gerelateerde zaken.

[Hero of Time]

pennywiser schreef op woensdag 18 december 2019 @ 20:47:
[...]

Dat een SSL uitgever deze fqdn's niet meer accepteert. Dus moet je gaan werken met self-signed certificaten. Verbaast me wel een beetje dat dit gevraagd wordt door iemand die zich karma keizer noemt van allerlei security gerelateerde zaken.

Hoezo? Hij stelt een terechte vraag. Want het is al heul lang mogelijk om een server naar een compleet andere naam te laten luisteren dan deze zelf draagt.

Of denk je echt dat alle servers in het Tweakers domein 'tweakers.net' en 'gathering.tweakers.net' heten?

Echt, het is maar een naam van een machine, niet de naam waarop de dienst wordt benadert.

[pennywiser]

Hero of Time schreef op woensdag 18 december 2019 @ 20:52:
[...]

Hoezo? Hij stelt een terechte vraag. Want het is al heul lang mogelijk om een server naar een compleet andere naam te laten luisteren dan deze zelf draagt.

Of denk je echt dat alle servers in het Tweakers domein 'tweakers.net' en 'gathering.tweakers.net' heten?

Echt, het is maar een naam van een machine, niet de naam waarop de dienst wordt benadert.

Ik had alleen het over .lan en .local tlds. Wel bij de les blijven.

[Bor]

pennywiser schreef op woensdag 18 december 2019 @ 20:47:
[...]

Dat een SSL uitgever deze fqdn's niet meer accepteert. Dus moet je gaan werken met self-signed certificaten. Verbaast me wel een beetje dat dit gevraagd wordt door iemand die zich karma keizer noemt van allerlei security gerelateerde zaken.

Daar zijn diverse oplossingen voor. Doorgaans hang je servers met .local of .tld hostnamen ook niet direct aan het internet. .local en .tld zijn op het internet geen geldige TLD's wat direct de reden is waarom deze vaak worden gekozen.

pennywiser schreef op woensdag 18 december 2019 @ 20:56:
[...]

Ik had alleen het over .lan en .local tlds. Wel bij de les blijven.

Daarvoor geldt hetzelfde wat @Hero of Time aangeeft.

Dat 3rd party CA's er geen certificaat voor uitgeven komt omdat .local en .tld etc aangeduid zijn als internal gTLDs (sectie 2.2.1.2.1 "Reserved Names" in het ICANN Applicant Guidebook).

[ Voor 27% gewijzigd door Bor op 18-12-2019 21:03 ]

[johnkeates]

Je mag .local niet gebruiken, net als dat je geen andere reserved namen/ranges mag gebruiken. En 'mag' betekent niet dat de politie dan op de stoep staat, maar het betekent slechts dat je er een bende van aan het maken bent, vooral problemen creeert die nergens voor nodig zijn, en dat alle software die wel RFC-compliant is gewoon niet goed gaat werken.

Gebruik een naam die je er speciaal voor registreert, of gebruik een subdomein. Alle andere opties is gewoon vragen om problemen, ook al zijn die problemen er misschien pas in de toekomst. En gebruik ook niet je bedrijfsnaam als de kans bestaat dat je van naam verandert of opgekocht wordt.

[ Voor 29% gewijzigd door johnkeates op 18-12-2019 21:02 ]

[pennywiser]

Bor schreef op woensdag 18 december 2019 @ 20:58:
[...]


Daar zijn diverse oplossingen voor. Doorgaans hang je servers met .local of .tld hostnamen ook niet direct aan het internet. .local en .tld zijn op het internet geen geldige TLD's wat direct de reden is waarom deze vaak worden gekozen.


[...]


Daarvoor geldt hetzelfde wat @Hero of Time aangeeft.

Ik snap dat het mogelijk is, bedankt voor de uitleg. Of je het van security wege nog steeds moet doen daar verschillen wij dan over van mening.

[Bor]

pennywiser schreef op woensdag 18 december 2019 @ 21:02:
[...]

Of je het van security wege nog steeds moet doen daar verschillen wij dan over van mening.

Ik ben nog steeds benieuwd naar de "security" reden waarom je geen .local of .tld kunt gebruiken.

[pennywiser]

Bor schreef op woensdag 18 december 2019 @ 21:04:
[...]


Ik ben nog steeds benieuwd naar de "security" reden waarom je geen .local of .tld kunt gebruiken.

Is het moeten gebruiken van een self signed ssl certificaat niet genoeg reden dan?

[Bor]

pennywiser schreef op woensdag 18 december 2019 @ 21:10:
[...]

Is het moeten gebruiken van een selg signed ask certificaat niet genoeg dan?

Die hoef je niet te gebruiken.

[johnkeates]

Bor schreef op woensdag 18 december 2019 @ 21:04:
[...]


Ik ben nog steeds benieuwd naar de "security" reden waarom je geen .local of .tld kunt gebruiken.

Er zijn nogal veel idiote ontwikkelaars die een certificaat en private key met hun software distribueren die soms .local gebruiken om bijv. vanuit de browser tegen een lokale server te praten (denk aan click-to-call skype plugins, video conferencing, companion apps). Onder andere Cisco, Skype, Origin, Steam, AppStores enz., kan je hier onder scharen. Soms doen ze het goed, en gebruiken ze bijvoorbeeld een OS-native URL handler, maar dat gebeurt lang niet altijd. En het probleem is ook niet dat het vaak of breed toegepast hoeft te worden, want het hoeft maar een keer mis te gaan om een hele grote doelgroep te pakken te krijgen.

Waarom is dat buiten de intrinsieke security issues ook een probleem als je dat gaat mengen met AD? Nou, om dat de meeste software die met AD praat niet aan public key pinning doet. En om dat er tot dat er kerberos gebruikt wordt ook geen controle in beide richtingen is. Dus als je zo'n certificaat en key in handen krijgt kan je iemand een versleutelde 'correcte' pagina of verbinding voorschotelen die ze dan niet van echt kunnen onderscheiden. En dat geldt ook voor APIs (lokaal dus) en zaken als email inline source referenties.

[pennywiser]

Bor schreef op woensdag 18 december 2019 @ 21:11:
[...]


Die hoef je niet te gebruiken.

Waar kan je deze nog laten issuen dan?

[johnkeates]

pennywiser schreef op woensdag 18 december 2019 @ 21:11:
[...]

Waar kan je deze nog laten issuen dan?

Als gewone gebruiker kan dat niet. Als sub-CA of cross-signed CA wel. Maar dan niet als je CT aan hebt staan, want dan wordt je distrusted uit de systeem CA's van Microsoft, Apple, Google en Mozilla en dan blijft er weinig over wat nog wel werkt.

Ander probleem is dat je geen CAA records kan maken, dus zelfs al zou je het willen laten issuen dan kan iemand anders dat dus ook doen.

[ Voor 14% gewijzigd door johnkeates op 18-12-2019 21:13 ]

[Bor]

pennywiser schreef op woensdag 18 december 2019 @ 21:11:
[...]

Waar kan je deze nog laten issuen dan?

Lees de reactie van Hero of Time nog een keer.

[pennywiser]

Bor schreef op woensdag 18 december 2019 @ 21:13:
[...]


Lees de reactie van Hero of Time nog een keer.

Heb ik gedaan ik kon het antwoord daar niet vinden sorry. Succes hiermee verder, alles respect maar ik denk hier gewoon fundamenteel anders over.

[FireWood]

Microsoft adviseert om geen .local e.d. meer te gebruiken, aangezien het niet gegarandeerd is dat het in de toekomst ook nog werkt.

Zie voor een uitleg:
https://social.technet.mi...in-and-network-names.aspx

Ik draai op het werk wegens legacy .local, maar heel soms kom je wat tegen wat er voor zorgt dat het gewoon wat meer werk is om het één en ander werkbaar te krijgen dan een subdomein van je eigen domeinnaam. Maar werken gaat het echt wel.

Een nieuw AD gewoon direct goed doen, maar bestaand ga ik echt niet zomaar veranderen.

[Hero of Time]

pennywiser schreef op woensdag 18 december 2019 @ 21:16:
[...]

Heb ik gedaan ik kon het antwoord daar niet vinden sorry. Succes hiermee verder, alles respect maar ik denk hier gewoon fundamenteel anders over.

Servernaam: exchange.kantoor.local
Certificaat: owa.bedrijf.nl

Probleem? Denk 't niet.

[Bor]

pennywiser schreef op woensdag 18 december 2019 @ 21:16:
[...]

Heb ik gedaan ik kon het antwoord daar niet vinden sorry. Succes hiermee verder, alles respect maar ik denk hier gewoon fundamenteel anders over.

Ik vind het juist interessant waarom je hier fundamenteel anders over denkt. Ik lees nu niet kloppende aannames maar mogelijk begrijp ik je verkeerd? Wie weet kunnen we van elkaar leren?

[pennywiser]

Bor schreef op woensdag 18 december 2019 @ 22:37:
[...]


Ik vind het juist interessant waarom je hier fundamenteel anders over denkt. Ik lees nu niet kloppende aannames maar mogelijk begrijp ik je verkeerd? Wie weet kunnen we van elkaar leren?

Eens. Ik moet inderdaad eerlijk zeggen dat ik van exchange onvoldoende afweet oa. dat ik niet begrijp waarom er een .local tlds gebruikt worden waar vervolgens kennelijk niets op connect. Waar dan voorlangs een geldig SSL certificaat gebruikt kan worden. Maar waarom die .local dan nog.

Als je alles wel netjes met een valide SSL af kunt regelen dan is er inderdaad geen issue echter .local en .lan noodzaakt het gebruik van self signed en dat is voor mij nogo. Ook niet in een ka omgeving.

Je eerste vraag bracht mij beetje op verkeerde been over iets in mijn ogen vanzelfsprekends.

[Hero of Time]

Maar dat staat verders compleet los van het issue van de TS, waarbij de AD domeinnaam hetzelfde is als het domein wat ze voor hun site gebruiken.

offtopic:
Dat .local wordt afgeraden en bad practise is, is ondertussen welbekend. Zou het iig moeten zijn. Want Apple gebruikt het voor z'n Bonjour meuk en dat conflicteert dan met je interne domeinnaam.

[Question Mark]

Hero of Time schreef op woensdag 18 december 2019 @ 20:52:
[...]

Hoezo? Hij stelt een terechte vraag. Want het is al heul lang mogelijk om een server naar een compleet andere naam te laten luisteren dan deze zelf draagt.

Dat ligt wel sterk aan de applicatie.... Interne certificaten voor bv. Skype for Business worden gewoon gegenereerd op basis van de fqdn van de host. Altijd feest als daar 3rd party add-ons op moeten integreren. Vanuit security oogpunt moet je deze dan ook met een publiek trusted certificaat gaan onstluiten, en dan ontkom je niet aan het gebruik van een publieke fqdn voor je interne domein.

[pennywiser]

Hero of Time schreef op donderdag 19 december 2019 @ 08:13:
Maar dat staat verders compleet los van het issue van de TS, waarbij de AD domeinnaam hetzelfde is als het domein wat ze voor hun site gebruiken.

offtopic:
Dat .local wordt afgeraden en bad practise is, is ondertussen welbekend. Zou het iig moeten zijn. Want Apple gebruikt het voor z'n Bonjour meuk en dat conflicteert dan met je interne domeinnaam.

Zo'n dergelijk antwoord vermoedde ik al nu is het ineens off topic. Ts vraagt hoe kan ik dit regelen.

Achterlangs worden door exchange IMAP of exchange connecties gelegd naar die .local welke je geen valide SSL certificaat meer kunt geven. Eens of oneens?

[Tsquare]

twieren schreef op woensdag 18 december 2019 @ 18:49:
Op wat voor platform draait jullie website? In veel gevallen is het in een dergelijke situatie, lokale domeinnaam en domeinwebsite (extern) het zelfde, mogelijk om de website te laten “luisteren” naar www. ipv zonder www.

Voorbeeld; binnen WordPress is het mogelijk om een website te laten luisteren op www en in browsers alsnog www. weer te geven en te laten gebruiken.

Omdat onze website draaide op Wordpress was dit de uiteindelijke oplossing om onze https link om te zetten incl www nu pakt hij onze dns A record op Bedankt!

[pennywiser]

Tsquare schreef op donderdag 19 december 2019 @ 14:53:
[...]


Omdat onze website draaide op Wordpress was dit de uiteindelijke oplossing om onze https link om te zetten incl www nu pakt hij onze dns A record op Bedankt!

Dit is wel kwetsbaar. Jullie wp is nu verantwoordelijk voor de correcte afhandeling van alle ka verkeer. Zodra dit niet goed werkt heeft waarschijnlijk ook je ka verkeer problemen.

[Paul]

pennywiser schreef op vrijdag 20 december 2019 @ 09:25:
Dit is wel kwetsbaar. Jullie wp is nu verantwoordelijk voor de correcte afhandeling van alle ka verkeer. Zodra dit niet goed werkt heeft waarschijnlijk ook je ka verkeer problemen.

Hoe bedoel je dat? Wordpress is verantwoordelijk voor alle verzoeken die (op poort 80/443) naar dat IP-adres worden gestuurd, maar dat was altijd al zo. Als dat niet werkt kan niemand op de hele wereld bij die site; dat KA er niet bij kan is dan maar bijzaak.

Als het goed is doet Wordpress niks met ander KA-verkeer (zoals Exchange, file services, inloggen in het AD), want het lijkt me niet dat ze ineens alle A-records in de DNS naar het IP van de webserver laten wijzen

@Tsquare Verandert hiermee ook hoe de site het extern doet? Wordt er geredirect van domein.tld naar www.domein.tld terwijl dat vroeger anders was? Wordt er niet geredirect en doen ze het nu allebei? Want dit soort aanpassingen hebben ook invloed op je ranking en vindbaarheid in search engines zoals Google...

[pennywiser]

Paul schreef op vrijdag 20 december 2019 @ 09:51:
[...]
Hoe bedoel je dat? Wordpress is verantwoordelijk voor alle verzoeken die (op poort 80/443) naar dat IP-adres worden gestuurd, maar dat was altijd al zo. Als dat niet werkt kan niemand op de hele wereld bij die site; dat KA er niet bij kan is dan maar bijzaak.

Als het goed is doet Wordpress niks met ander KA-verkeer (zoals Exchange, file services, inloggen in het AD), want het lijkt me niet dat ze ineens alle A-records in de DNS naar het IP van de webserver laten wijzen

@Tsquare Verandert hiermee ook hoe de site het extern doet? Wordt er geredirect van domein.tld naar www.domein.tld terwijl dat vroeger anders was? Wordt er niet geredirect en doen ze het nu allebei? Want dit soort aanpassingen hebben ook invloed op je ranking en vindbaarheid in search engines zoals Google...

Ik denk dat je gelijk hebt inderdaad, niet alle verkeer gaat richting wp, maar het komt kwetsbaar over op mij. Denk aan je seo inderdaad.

[twieren]

Tsquare schreef op donderdag 19 december 2019 @ 14:53:
[...]


Omdat onze website draaide op Wordpress was dit de uiteindelijke oplossing om onze https link om te zetten incl www nu pakt hij onze dns A record op Bedankt!

Graag gedaan. Fijn dat ik je heb kunnen helpen! :-)

[Simon Weel]

Is al een oude topic, toch een reactie. De juiste oplossing is een paar keer gegeven. Vroeger raadde Microsoft aan om voor het lokale domein een andere naam / extensie te gebruiken dan voor het externe domein. Dat advies is al een tijdje geleden gewijzigd; lokaal / extern domein dezelfde naam geven. Doe je dit niet, dan is de kans groot dat je vroeg of laat wordt gebeten. Hierbij wordt ook het begrip Split-brain DNS geintroduceerd. Genoeg websites die dat onderwerp uitspitten.
Heb je een externe website, dan moet je in je lokale DNS server in de Forward Lookup Zone een A-record www opnemen (voorop gesteld dat de naam van de website met www begint) met het IP-adres van je website.Zodoende kan je ook vanuit het lokale domein de website bezoeken.

Heb je ook Exchange On-premise, dan doe je er goed aan een aantal alias (cname) records in je lokale DNS server op te nemen voor name, autodiscover en eventueel webmail met als bestemming je lokale Exchange server. Heb je ook geen gemekker meer van Outlook.

[Question Mark]

Simon Weel schreef op woensdag 29 april 2020 @ 13:10:
Dat advies is al een tijdje geleden gewijzigd; lokaal / extern domein dezelfde naam geven. Doe je dit niet, dan is de kans groot dat je vroeg of laat wordt gebeten.

Heb je daar een Microsoft bron bij? Ik ken deze aanbeveling vanuit Microsoft nl. niet. Het meest recente artikel wat ik kan vinden (april 2018), is onderstaande:

DNS Namespace Planning

Daar staat letterlijk het volgende in:

Overlapping internal and external namespaces are not recommended.

Vanuit security oogpunt moet je overigens al niet willen om interne naamgeving of conventies publiekelijk te ontsluiten. Technisch ontkomt je er echter soms niet aan. Vandaar dat ik benieuwd ben naar een officieel statement van MS.Ik weet dat er héél veel over geschreven is door veel partijen, een echt officieel MS document ben ik er nooit over tegengekomen.

[Simon Weel]

Question Mark schreef op donderdag 30 april 2020 @ 19:51:
Heb je daar een Microsoft bron bij?

Ik dacht van wel... Niet dus. I stand corrected. In dit artikel van Microsoft staat het domeinnaam verhaal uitgebreid beschreven.

Maar... in geval van een on-premise Exchange server, wordt het weer een iets genuanceerder verhaal. Dit is het artikel wat ik heb gehanteerd bij het inrichten van ons domein - wij hebben namelijk Exchange on-premise.

[Question Mark]

Simon Weel schreef op maandag 4 mei 2020 @ 12:10:
[...]

Ik dacht van wel... Niet dus. I stand corrected. In dit artikel van Microsoft staat het domeinnaam verhaal uitgebreid beschreven.

En daar staat de best practice in zoals ik deze ken:

Microsoft strongly suggests to work with subdomains, within a publicly registered TLD domain.

Maar... in geval van een on-premise Exchange server, wordt het weer een iets genuanceerder verhaal. Dit is het artikel wat ik heb gehanteerd bij het inrichten van ons domein - wij hebben namelijk Exchange on-premise.

Ik herken de spagaat.... Sommige Microsoft applicaties wijken wat af van de best practice zoals deze voor domeinen aanbevolen wordt. Verschillende productteams, dan krijg je dat...

[Vorkie]

Question Mark schreef op maandag 4 mei 2020 @ 13:25:
[...]
En daar staat de best practice in zoals ik deze ken:

[...]


[...]

Ik herken de spagaat.... Sommige Microsoft applicaties wijken wat af van de best practice zoals deze voor domeinen aanbevolen wordt. Verschillende productteams, dan krijg je dat...

En dan kom je in deze mooie.. oplossing

https://docs.microsoft.co...plit-brain-dns-deployment