Phenquestions
DNS-resolutie
- U moet een website zoals newdomain registreren.com, nieuwdomein.org, nieuwdomein.biz, nieuwdomein.hosting, enz. Tegenwoordig zijn er veel nieuwe TLD's zoals .werk, .hosting enz. van een van de domeinregistreerders. De meest voorkomende zijn als Godday.com, domein.com, NaamGoedkoop.com, Bluehost.com
- Zodra je de domeinnaam van de bovenstaande registrar hebt gekocht, moeten we nu een hostingaccount vinden (het kan een shared hosting / reseller-hosting zijn of een VPS / dedicated server) . Als je een gedeeld/wederverkoperaccount hebt, zullen ze ons meestal een paar naamservers leveren die moeten worden gebruikt om het domein naar hun servers te verwijzen. ALS u een vps/dedicated servers aanschaft, moeten we mogelijk de server instellen met een DNS-server waarvoor we voornamelijk Named- of Bind-pakketten gebruiken.
- Als u zelf registrar-naamservers gebruikt, moet u alle dns-records handmatig in dat paneel maken. Als u een gedeelde hosting van cpanel / plesk gebruikt, worden meestal alle dns-records gemaakt tijdens het maken van het account en hoeft u alleen de naamservers van de hostingprovider naar de registrar te verwijzen.
- Eenmaal aangegeven, kan het tot 24 - 72 uur duren voordat de wijzigingen op internet zijn verspreid.
De DNS-records begrijpen
DNS-records zijn instellingen die ons helpen een domein en zijn verscheidenheid aan services naar die juiste servers of IP-adres te verwijzen. Dns-records fungeren als een instructeur, zoals dat domein naar dat ip verwijst, dat subdomein naar een ander ip verwijst, enz. Zonder de juiste DNS-records zullen mensen het IP-adres moeten onthouden en het onthouden van een IP-adres zal een vervelende taak zijn en dat is hoe het belang van DNS in het spel komt.
We hoeven geen IP-adres te onthouden, omdat het voor mensen altijd een probleem zal zijn om het IP-adres te gebruiken om naar de website te gaan. Daarom registreren we de domeinnaam en gebruiken we dns om deze correct naar de hostingserver te laten verwijzen. Voordat DNS-servers of -pakketten werden gemaakt, moet men het IP-adres in de browser typen en hetzelfde onthouden. Met de introductie van IPV6 is het letterlijk onmogelijk om het IP-adres te onthouden, zelfs voor degenen met de beste geheugencapaciteit.
Er zijn meer dan 70 + dns-records en u kunt de onderstaande link lezen voor alle mogelijke DNS-records en de details ervan
https://www.iana.org/toewijzingen/dns-parameters/dns-parameters.xml
Ik bespreek de onderstaande records die het meest nodig zijn voor een leek om zijn site gehost te krijgen en de e-mailstroom soepel te laten verlopen.
- SOA-record
- TTL-waarde
- Een opname
- AAA-record
- NS-record
- MX-record
- TXT-record
- SPF-record
- DKIM-record
- DMARC-record
- PTR-record
- CNAME-record
- SRV-record
- RP-record
- DNSKEY-recordzo
1. SOA (START VAN AUTORITEIT) Record
SOA-record is het belangrijkste en toch niet zo populaire record. Het is een must om een DNS-zonebestand te laten werken en ons resultaten te geven. Dit specifieke record heeft de naam van de zone, het e-mailadres van de verantwoordelijke persoon die het zonebestand van het domein verwerkt, het huidige serienummer, de primaire of hoofdnaamserver voor de zone en enkele tijdselementen die worden gemeten en weergegeven in seconden.
Hieronder vindt u een voorbeeld van een SOA-record:
domein.com. 86400 IN SOA ns1.domein.com. e-mailadres van de eigenaar.domein.com. (2017100505 ;Serienummer
3600 ;vernieuwen
7200 ;probeer opnieuw
1209600 ;verlopen
86400)
Het exacte formaat hiervoor is het onderstaande:
@ IN SOA primary-name-server hostmaster-email (
serienummer
tijd om te vernieuwen
tijd om opnieuw te proberen
tijd om te verstrijken
minimum-TTL )
Primaire-naamserver : Het toont de naamserver die de originele dns-records bevat.
Hostmaster-e-mail : E-mailadres van de eigenaar die verantwoordelijk is voor het domein. Een periode ".” wordt gebruikt ter vervanging van een @-symbool. Voor e-mailadressen met een ".” al in dat zal worden ontsnapt met een “/”.
Serienummer : Het is het versienummer van de Zone en het zal blijven toenemen met elke update van het Zone-bestand.
Tijd om te vernieuwen: Deze waarde geeft de wachttijd aan voor het controleren op een update van het serienummer. Dit is vooral nodig wanneer u een secundair dns- of dns-cluster hebt dat moet controleren op een update van het hoofdbestand en dat de laatste moet worden gekopieerd naar de andere servers in het cluster. Alleen van toepassing op degenen die secundaire dns of clusterconfiguratie hebben.
Tijd om opnieuw te proberen: Het bepaalt hoe lang een naamserver moet wachten voor het opnieuw proberen te vernieuwen als de laatste poging is mislukt.Alleen van toepassing op degenen die secundaire dns of clusterconfiguratie hebben.
Tijd om te verlopen: het bepaalt hoe lang we moeten wachten voordat we de gegevens van de secundaire of andere clusternaamservers als ongeldig beschouwen en stoppen met reageren op de vragen voor de respectieve zone.
minimum-TTL : Hoe lang moet een nameserver of resolvers een negatief antwoord cachen?.
2. TTL-waarde (Time to Live)
TTL-waarde is de tijd in seconden dat een dns-record wordt gecached door een externe dns-server of naamserver en daarna moet het de cache worden vernieuwd en de nieuwste waarde hebben . Het belangrijkste hiervan is dat u een migratie plant en dns-wijzigingen nodig heeft zonder enige downtime van dns. Wijzigingen aan nameservers kunnen altijd downtime veroorzaken, omdat we daar geen controle over hebben. Dus voor de migratie veranderen we normaal gesproken de TTL-waarde naar 300 sec 1 - 2 dagen voorafgaand aan zichzelf, zodat we na de migratie de naamserver-ip's aan het registrar-einde zullen veranderen en ook de IP's van alle zonebestanden in de oude server naar nieuwe ip's zullen veranderen zodat het in beide gevallen begint op te lossen naar een nieuwe server, dat wil zeggen als de dns naar de oude server gaat, dan zal het het domein van die server naar de nieuwe server verwijzen en als de nieuw bijgewerkte naamservers worden gebruikt, zal het ook beginnen met laden vanaf nieuwe server.
Als er geen ttl-waarde wordt vermeld, is dit de belangrijkste standaardwaarde voor alle dns-records, tenzij we een andere waarde hebben opgegeven in de records.
Voorbeeldinvoer$TTL 14400
3. Een opname
Een record wordt ook wel adresrecords of hostrecords genoemd. Dit wordt voornamelijk gebruikt om het domein/subdomein enz. naar het ip-adres van de server te verwijzen. Een record wordt alleen omgezet in een ip-adres en er zijn geen andere argumenten / variabelen in het A-record. A-records worden alleen gebruikt om naar een IPV4-adres te verwijzen.
Voorbeeld A Record is de onderstaande:domein.com. 14400 IN A 192.168.1.1
We kunnen ook een wildcard dns-record gebruiken die alle subdomeinen naar één ip . laadt
*.domein.com 14400 IN A 192.168.1.14. AAA-record
AAAA-record is hetzelfde als het bovenstaande Record en doel en gebruik van dit record is allemaal hetzelfde. Het enige verschil is dat dit wordt gebruikt om het domein naar een IPV6-IP te verwijzen en als het domein ook een IPv6-versie heeft, dan moeten we dit A-record ook wijzen .
Voorbeeld van een AAAA-record is het onderstaande:
domein.com 14400 IN AAAA 0133:4237:89bc:cddf:0123:4267:89ab:cddf5. NS (naamserver) record
Ideale situatie is dat zowel de naamserver op registrar-niveau als het dns-zonebestand hetzelfde zijn en niet-overeenkomende ns-records kunnen problemen veroorzaken bij sommige internetproviders, maar normaal gesproken is die mismatch niet zo'n probleem. Dus primaire naamserver-records moeten aanwezig zijn in zowel registrar als dns-zonebestand op de server die wordt vermeld in registrar.
Voorbeeldinvoerdomein.com. 86400 IN NS ns1.hoofddomein.com.
domein.com. 86400 IN NS ns2.hoofddomein.com.
Als je de nameservers voor hetzelfde domein hebt, zorg er dan voor dat je A-records toevoegt voor deze nameservers .In het bovenstaande voorbeeld gebruikt het een andere geregistreerde naamserver zoals ns1.hoofddomein.com. Maar als u ns1 . wilt gebruiken.domein.com zelf als nameserver in registrar en server, moet u HOST-records instellen in het register (dat is het GLUE-record) en moet u ook de onderstaande A-records toevoegen
ns1 14400 IN A 192.168.1.1ns2 14400 IN A 192.168.1.1
6. MX (Mail Exchange) Record
Dit is een ander belangrijk dns-record dat het lot van uw inkomende e-mails naar een domein bepaalt. Wanneer iemand een e-mail stuurt naar een e-mailaccount onder een domein, stuurt de externe server e-mails naar de server die wordt vermeld in de MX-records en die met de laagste waarde in prioriteit die in feite de hoogste prioriteit heeft
Voorbeeld MX-records
domein.com 14400 IN MX 10 mail_1.domein.comdomein.com 14400 IN MX 20 mail_2.domein.com
domein.com 14400 IN MX 30 mail_3.domein.com
In dit voorbeeld, als mail_1.domein.com is niet beschikbaar, e-mail wordt afgeleverd op mail_2.domein.com. Als mail_2.voorbeeld.com is ook niet beschikbaar, de e-mail wordt bezorgd op mail_3.domein.com.Dit wordt voornamelijk gebruikt wanneer u een domein op meerdere servers hebt toegevoegd en e-mail daarin hebt geconfigureerd. Maar die e-mails zullen naar die servers worden verspreid en het kan zijn dat u die handmatig moet controleren.
Als u de MX-records met dezelfde domeinnaam gebruikt, moet u de juiste dns A-records toevoegen. Zoals de onderstaande . Maar als u Google-apps, Outlook enz. Gebruikt, hoeft u hiervoor geen extra A-record toe te voegen, omdat u daar geen controle over heeft en die door die providers moeten worden toegevoegd.
mail_1 14400 IN A 192.168.1.1mail_2 14400 IN A 192.168.1.2
mail_3 14400 IN A 192.168.1.3
7. TXT (tekst) opnemen
Een TXT-record of tekstrecord speelt eigenlijk geen rol bij domeinfunctionaliteit en wordt meestal gebruikt voor het weergeven van wat info of voor sommige verificaties, zoals wanneer u zich aanmeldt met Google Apps of Outlook Mail-service, dan zullen ze u vragen om een TXT-record dat ze vragen (een unieke code) zodat ze het eigendom van het domein kunnen verifiëren. SPF/DKIM-records zijn ook gebaseerd op TXT, maar ze hebben een functionaliteit om uit te voeren. Deze kunnen ook worden gebruikt als een optie om uw eigendom te verifiëren terwijl ze ook worden toegevoegd aan het Google Webmaster-account en andere aan Google gerelateerde services.
Hieronder vindt u een voorbeeld van een dns-vermelding voor Google-verificatie
domein.com. 300 IN TXT google-site-verification=gBmnBtGTIz_esMKJBKT-PxLH50M8. SPF (Sender Policy Framework) Record
SPF-record is in feite een TXT-record, dat normaal gesproken alle aangewezen mailservers voor een domein of subdomein publiceert. Het belangrijkste gebruik van dit record is om de legitimiteit van de e-mails te bewijzen en vervalste e-mails te voorkomen. Een bestemmingsmailserver kan e-mails weigeren als deze niet afkomstig zijn van de geregistreerde of genoemde e-mailservers op basis van dit record.
Voorbeeldinvoerdomein.com. IN TXT "v=spf1 +a +mx +ip4:192.168.1.5 -alle"
Dit zegt dat dit domein alleen legitieme e-mails verzendt vanaf A-record, MX-recordservers en ook vanaf ip 192.168.1.5 en alle andere kunnen worden afgewezen . Met het bovenstaande SPF-record controleert de ontvangende server alle servers en ipaddress die wordt vermeld in de SPF. Als het ip-adres overeenkomt, wordt de controle doorstaan, en als dat niet het geval is, mislukt het (bericht wordt automatisch afgewezen) en als we "~all" gebruiken, wat een zachte fout is, wordt het bericht gemarkeerd als FAIL maar niet afgekeurd.
U kunt meer sytanx raadplegen via deze link.
9. DKIM (DomainKeys Identified Mail)Record
Dit is ook een TXT-record dat ook een e-mailverificatieprotocol is dat iets gecompliceerder is dan SPF. Dit record is gemaakt voor een subdomein met een unieke selector voor de sleutel en heeft dan een ".Door zo'n record toe te voegen, wordt een digitale handtekening toegevoegd aan de koppen van het e-mailbericht. Deze handtekening wordt gevalideerd met behulp van de door DKIM-record gepubliceerde openbare sleutel. Dit is een beetje ingewikkeld en als je in cpanel zit, bieden ze een optie om dit gemakkelijk voor elkaar te krijgen met één klik inschakelen.
Voorbeeldinvoerstandaard._domainkey 14400 IN TXT "v=DKIM1; k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmDb9e2q41oLc0ZDtSNo2Ik4khVMUMkv98N1Y0
FehUCcFUIUIUIUIUIuiuicfhdyeytrytrryuytytfyfyfytrytrytrtyrytrytrytrytrytdyBQ3XatuaEj
qGR0zfaY6RSU++gqGF8ZRpjJd+O3AcqRZT4ZT8d7Uhye6Ctgcv3kQEd5I2dTSpodIzWey8reysHJMdCvulRJYdP"
UWj5PrHfkwY7ec0ZNggTOpmlByXIPRx0Q/oBS9TLlAs785XJMNWjubyyjC6V5JUQ+tRyhwa28TWM/l6/EIcYNBZE
fWx8oHQsBFLT0dNsRhq9ExX0UDMmbddD0zWoKtx+Wb7ItG0HPPVqne8jWkeXQIDAQAB\;
10. DMARC-record
DMARC-record werkt alleen als er de juiste SPF- en SKIM-records zijn. Het is een beleid van het e-mailauthenticatieproces en hoe de ontvangende server de e-mail moet behandelen als dit het beleid schendt. Wanneer een inkomende e-mail op de externe server binnenkomt, zal deze naar zijn DMARC-record vragen en ervoor zorgen dat de onderstaande vragen worden beantwoord:
> Zijn de inkomende e-mails DKIM-handtekening correct? ?
> Kwam het bericht van een geautoriseerde ip/server-hostnaam zoals vermeld in het SPF-record?.
> Of de koptekst van de inkomende e-mails de juiste uitlijning heeft volgens de RFC 5322.
Voorbeeldinvoer
_dmarc.domein.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:[email protected]\;ruf=mailto:[e-mail beveiligd]\; pct=100"
_dmarc.domein.com: Subdomein dat is ingesteld voor authenticatie van DMARC Alone.
v=DMARC1 : Dmarc-versie in gebruik.
p=geen : vermeldt de voorkeursbehandeling van de polis
rua=mailto:[e-mail beveiligd] : Geaggregeerde rapporten worden naar deze verzonden
ruf=mailto:[e-mail beveiligd] : Foreincsische rapporten moeten naar dit e-mailaccount worden verzonden
pct=100: dit is het percentage e-mails waarvan de eigenaar het record wil laten controleren en gebruiken voor beleidsupdates
DMARC/SPF/DKIM is allemaal nodig voor een goede authenticatie voor maildiensten
11. PTR (aanwijzer) opname
PTR-records zijn ook bekend als Reverse DNS voor de ip. PTR-records worden normaal gesproken ingesteld op Hosting Provider of Server Provider niveau. PTR-records helpen ons om een IP-adres te koppelen aan een domein of een subdomein (normaal gesproken aan een FQDN volledig gekwalificeerde domeinnaam), wat zal helpen om de reverse dns-query's correct te laten werken.
Dus als een vereiste om reverse dns voor een ip in te stellen, vragen tegenwoordig Hosting / Server Providers eerst om een record voor het domein/subdomein in te stellen voor dat IP en zodra dat is gebeurd, zal het datacenter de RDNS (Reverse DNS) instellen Vermelding).
12.CNAME-record (canonieke naam)
CNAME-record helpt om een domein of subdomein naar een ander domein of subdomein te verwijzen.
Voorbeeldinvoer:nieuwdomein.com 14400 IN CNAME domein.com.
mail 14400 IN CNAME-mail.domein.com.
Voorbeeld 1, wijst naar het nieuwe domein.com naar domein.com waar als het tweede voorbeeld mail verwijst.nieuwdomein.com naar mail.domein.com. Met deze records, wanneer een verzoek naar een nieuw domein komt.com, zal het een CNAME-record naar het domein vinden.com. Daarna zal het een nieuwe zoekopdracht voor het domein starten.com en het zal het verzoek naar het domein sturen.com en hetzelfde is ook het geval met de tweede plaat.
13.SRV (Service)-record
SRV-record helpt ons om te verwijzen naar een bepaalde service die op uw domein of subdomein naar een doeldomein draait. Dit helpt ons om verkeer voor bepaalde services zoals chatserver of berichtenservices naar een andere server te leiden.
Voorbeeldinvoer:
_sipfederationtls._tcp. 3600 IN SRV 100 1 5061 sipfed.online.Lync.com._onderhoud._protocol.voorbeeld.com 3600 IN SRV 10 0 5060 service.voorbeeld.com
_onderhoud._proto.naam. TTL klasse SRV prioriteit gewicht poort doel.
Onderhoud : naam van de services moet beginnen met een onderstrepingsteken "_" en wordt gevolgd door een ".” service kan van alles zijn zoals _chat, _xmpp, _sipfederationtls (die wordt gebruikt voor Microsoft Exchange-servers) enz.
Protocol :De naam van het protocol moet ook beginnen met een onderstrepingsteken en vervolgens een ".” in dit geval is het “_tcp.” en het vertelt ons dat het een TCP-protocol is dat in gebruik is.
Naam : Naam of Domeinnaam is het domein dat oorspronkelijk verkeer voor deze service zal ontvangen.
Prioriteit : Het is het eerste nummer dat in de bovenstaande voorbeelden wordt genoemd (respectievelijk 100 en 10) helpt u om de prioriteit voor de doelserver in te stellen en een lager nummer betekent een hogere prioriteit. Dit is vergelijkbaar met MX-recordprioriteit en werkt op dezelfde manier omdat we een ander record kunnen instellen als terugvallen met een andere prioriteit.
Gewicht : Als we vergelijkbare records met dezelfde prioriteit maken, is deze specifieke waarde de beslissende factor. Gewicht is respectievelijk 1 en 0 in de bovenstaande voorbeelden.
Poort : dit toont de TCP- of UDP-poort waarop de service draait.
Doelwit : dit is het doelsubdomein of domein waarnaar deze service wordt omgeleid en het moet een geldig A / AAAA-record hebben om dit verkeer naar daar te laten omleiden.
14. RP (Verantwoordelijke Persoon) Record
Dit is normaal gesproken tegenwoordig niet nodig omdat er een e-mailadres is gekoppeld aan het SOA-record. Maar als een domein specifiek moet worden vermeld, afgezien van het standaard SOA-record e-mailaccount, dan kunnen we een RP-record toevoegen.
15. DNSKEY-record
DNSkey-record bevat een openbare sleutel die door de resolvers wordt gebruikt om dnssec-handtekeningen te verifiëren verify.
Voorbeeldinvoer
domein.com. 300 IN DNSKEY 257 3 5 Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd==
Naam ttl-klasse RRtype flags_filed Protocolalgoritme public_key
Naam : het is normaal gesproken de domeinnaam of hostnaam
IN : Vertegenwoordig de recordklasse en standaard is IN (wat internet betekent)
Opnametype : record type is het type record en in dit geval is het DNSKEY
Vlaggen : Gearchiveerde vlaggen zijn in een bekabeld formaat dat een teken van 2 bytes lang is. Mogelijke waarden zijn 0, 256 en 257. Als de waarde 256 is, betekent dit dat het dnskey-record ZSK (Zone-signing key) betaald bevat en als de waarde 257 is, dan bevat het KSK (key-signing keycomponent. In het kort bevat dit veld een ODD-nummer wanneer het een KSK-sleutelpaar bevat.
Protocol: Dit heeft altijd een waarde van 3, voor DNSSEC.
Publieke sleutel : openbare sleutel zijn de sleutelgegevens en in dit geval is dit "Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd=="
Algoritme: Helpt ons om public_keys te identificeren met behulp van verschillende algoritmen en hieronder zijn de meest gebruikte
- 1 = RSA/MD5
- 2 = Diffie-Hellman (Dit wordt niet ondersteund door BIND)
- 3 = DSA
- 4 = Gereserveerd
- 5 = RSA/SHA1
- 6 = DSA/SHA1/NSEC3
- 7 = RSA/SHA1/NSEC3
- 8 = RSA/SHA-256
- 10 = RSA/SHA-512
Conclusie
Ik hoop dat dit jullie allemaal echt helpt DNS te begrijpen en ervoor te zorgen dat je hosting correct is ingesteld.
