Eergisteren mijn domein verhuist naar Freedom en dat was een bumpy ride (met ook pech, een storing aan de dns infra):
alles wat je in DNS aan wil maken, is kennelijk gekoppeld aan regels, die niet in de interface uitgelegd worden, dus veel zoeken en helpdesk benaderen waren het gevolg. Bij bewaren krijg je geen foutmelding, maar wordt je record niet aangemaakt, hier dus ook op letten.
Mail controle van Soverin moet uitgezet als je enig record wil laten verwijzen naar mail (gek genoeg is het symptoom alleen het _dmarc record, je moet het maar aan elkaar koppelen)
C-name records krijgen automatisch je domeinnaam cadeau, óók en juist als je dit niet wilt. Een punt op het einde voorkomt dit (maar ontdek dat maar eens).
Ik ben prima geholpen, hoop dat bovenstaande anderen kan helpen
De “bewaar” button voor opslaan na onderaan iets hebben toegevoegd toevoegen, zit wmb ook op een rare plaats.
Ook zou ik graag zien dat de DNS voor MX/Mail, simpel op een eigen pagina zou staan.
Verder zijn sommige boodschappen cryptisch en onduidelijk met wat er mis zou zijn.
Zelf controleer ik altijd of iets echt gelukt is en ook doorgevoerd door zaken op DNS server 1.1.1.1 op te vragen.
Ook doe ik mijn wijzigingen, is wat omslachtig, per stuk met bewaren. Ik hoop dat er (ooit) een de soms genoemde API komt om o.a. de DNS tabellen te kunnen bijwerken en die ook te kunnen exporteren. NB: met wat moeite & rommelen, is de source uit de webbrowser om te zetten naar lijst. Voor een webdesigner/maker is dit dus nog makkelijker en vooral een kwestie van “dat” willen faciliteren.
Die punt aan het einde van een naam, ligt idd niet voor de hand maar is wel conform DNS/RFC specificatie(s). Een naamsverwijzing die niet eindigt op “punt”, word aangevuld met de waarde van de bovenliggende zone-origin; dat in ons geval, de “eigen” domeinnaam is.
Door in DNS te eindigen met een “punt” wordt de waarde een zg. Root verwijzing of zo noemt, een FullQulifiedDomainName.
Die afsluitende punt (onbewust) vergeten kan idd zorgen voor niet onderkende fouten.
@ voorstad
Je laatste zin zegt het precies, reden van mijn post.
Helpdesk ook al getipt dit mee te nemen, het staat deels in de help pagina’s (nog beter zou zijn om meer tips in de DNS interface te geven).
Voor de community heb ik het topic wat extra verwijzingen gegeven, beter te vinden.
@anon0224
Bewaar knop viel mij ook op.
Dat de eindigende punt RFC compliant zou zijn, heb ik bij nu 3 eerdere hosters niet gezien, compliancy betekent gek genoeg niet altijd dat het wordt toegepast
Die hosters (als ze het al zelf weten) richten zich veelal op consumenten.
Zonder punt te eisen, scheelt het in call-center belasting. En als iedereen ergens dan Frans voor Hans doet, is er niets aan de hand.
RFC-compliancy is voor een normaal mens, laat staan de onderliggende overerving principes van veldwaarden, niet bepaald begrijpelijk.
Het staat mij bij dat in een (ver) verleden de makers van software voor/van DNS-records, wel eens iets niet goed interpreteerden. Er zijn ook verschillende implementaties voor dezelfde functies.
Bij Freedom aka. Soverin gebruiken ze op/voor hun DNS servers, bij mijn weten, de “powerdns” implementatie die voor een FQDN, kennelijk de normale punt verwacht.
In de RFC’s is (d8 ik) ook niet keihard te vinden dat een punt onderscheidenlijk moet. Die punt is feitelijk alleen van toepassing met hoe iemand een veld aanstuurt. De punt had bij wijze ook een kunnen zijn.
Er staat in de RFC’s alleen dat er een onderscheid is tussen een volledige (dwz rootnaam) en een naam als onderdeel van een DNS zone(origin).
Los daarvan is een RequestForComment geen wet maar een afspraak om het zo te doen.
RFC1034 heeft daar wel iets over te zeggen in paragraaf 3.1
En door die afspraken werkt het internet
Ondanks dat het nog steeds Request for Comments heten, geeft RFC8700 een uitleg hoe dit is ontstaan en dat de comments nu vooral het commentaar vooraf gevraagd wordt.
Cool en leuk dingen te verversen !!!
Had 'm ooit 's terloops vastgehouden maar niet meer op het netvlies.
bron: rfc1034
The most common interpretation uses the root “.” as either the single
origin or as one of the members of the search list, so a multi-label
relative name is often one where the trailing dot has been omitted to
save typing.
Kortom, punt weglaten is dan dat die inhoud wordt aangevuld met die van het bovenligende zone/domein.
De angel is het niet zo vrijblijvende van een “afspraak” waardoor het internet werkt zo als het werkt. Ik moet nog steeds omdenken dat woordstrekkingen als “recommended/should/shall/may/must(not)”, technisch een wat andere lading hebben dan mensen zelf hanteren.
Toch leuk om zo even een rfc uit 1987 te lezen, heerlijk nerd gehalte!
En het staat er allemaal in, ook het woord often, categorie “recommended/should/shall/may/must(not)”.
Voor een domain naam ZONDER . aan het eind is het normaal (in de DNS server) dat dan .@. (= eigen domain naam wordt toegevoegd). Dat is als de DNS server volgens RFC normen werkt.
Dat allerlei hosters voor “gebruikers” gemak, of juist “klantbinding” daarvan afwijken wil niet zeggen dat het ook correct is.
Hie weet je dat wat je invult ook letterlijk op de DNS server terecht komt, en niet langs vertaal hulpjes gestuurd wordt.
IMHO dus eerder een feature dan een “bug” of iets om voor op te passen.
dat er (ooit) een de soms genoemde API komt om o.a. de DNS tabellen te kunnen bijwerken en die ook te kunnen exporteren.
?
kunnen zijn.
Cool en leuk dingen te verversen !!!