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ă).