Primele browsere web nu urmează SRV
înregistrări, așa că, chiar dacă le puteți proiecta, sunt inutile.
Acum, având în vedere procesul generic pentru a ști ce intră în orice înregistrare, luând SRV
ca exemplu.
IANA este gardianul lucrurilor, așa că mergeți la https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 unde poți vedea pentru SRV
că este definit în RFC 2782
Acolo este definit astfel:
Iată formatul SRV RR, al cărui cod de tip DNS este 33:
_Service._Proto.Name Clasa TTL SRV Prioritate Greutate Port Target
cu apoi respectiv:
Serviciu
Numele simbolic al serviciului dorit, așa cum este definit în Atribuit
Numere [STD 2] sau local. Se adaugă o liniuță de subliniere (_).
identificatorul serviciului pentru a evita coliziunile cu etichetele DNS care
apar în natură.
și
Proto
Numele simbolic al protocolului dorit, cu un caracter de subliniere
(_) adăugat pentru a preveni coliziunile cu etichetele DNS care apar
în natură. _TCP și _UDP sunt în prezent cele mai utile valori
pentru acest câmp, deși orice nume definit de Numere atribuite sau
local poate fi utilizat (ca și pentru Service). Proto este cazul
insensibil.
Referința [STD 2] este RFC 1700, dar RFC 3232 l-a depășit pentru a face o bază de date online cu valori posibile... care este din nou administrată de IANA.
Acum este acolo: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml și rețineți că este practic ceea ce găsiți în fișier /etc/services
în orice cutie Unix.
Deci, luând înapoi exemplele (numerele tale de porturi sunt greșite în mai multe SRV
înregistrările descrise totuși):
mysql
este într-adevăr definit pentru port 3306
deci este valabil ca nume de serviciu și, prin urmare, într-un SRV
record
- pentru port
27017
, numele serviciului este mongodb
, nu mongo
(dar clienții Mongo onorează SRV
înregistrări?)
http
este într-adevăr definit pentru port 80
deci este un nume de serviciu valid (și https
pentru portul 443)
mqtt
este definit ca nume de port valid, pentru port 1883
. Dar aceeași întrebare ca mai sus, folosesc clienții SRV
înregistrări deloc?
Rețineți, de asemenea, că există în sălbăticie diverse SRV
înregistrări care nu respectă cele de mai sus. Dacă pot fi publicate, „funcționează”, asta nu va împiedica rezolvarea lor la nivel DNS, chiar dacă nu folosesc un nume de serviciu înregistrat ca mai sus, atâta timp cât o aplicație le citește, desigur.
De exemplu, puteți găsi o mulțime de exemple cu _sip._tls
sau _sipfederationtls._tcp
online, care sunt ambele greșite: tls
nu este un protocol valid și sipfederantiontls
nu este un nume de serviciu valid (și, de fapt, este prea lung, așa cum https://www.rfc-editor.org/rfc/rfc6335.html#section-5.1 specifică că ar trebui să aibă cel mult 15 caractere). Deci, un instrument/UI poate împiedica crearea acelor înregistrări într-un fișier zone, iar unele servere de nume pot refuza să le încarce, dar în cele mai multe cazuri vor funcționa (dacă aplicațiile le consumă).