Volver al inicio
Tecnología
Lectura de 29 minutos
Estándar de Nomenclatura Becall
Estándar de nomenclatura para todos los dispositivos Becall — servidores, equipos de usuario y objetos de Active Directory.
Estándar de nomenclatura para todos los dispositivos Becall — servidores, equipos de usuario y objetos de Active Directory.
Este documento define el estándar de nomenclatura para todos los activos gestionados por Becall: servidores físicos y virtuales, instancias cloud y equipos de usuario.
Seguir este estándar garantiza identificación inequívoca de cada activo, compatibilidad con DNS y Active Directory, y una base estable para automatización con herramientas como Terraform, Ansible o cualquier integración con CMDB.
Aplica a todos los servidores (físicos, virtuales, cloud) gestionados por Becall. Los equipos de usuario se cubren en la Parte II.
Los hostnames deben cumplir las especificaciones DNS (RFC 1034/1123):
a–z, 0–9 y guion (-).Windows AD tiene una restricción técnica dura para el atributo sAMAccountName de cuentas de equipo: 15 caracteres (más el $ final). Windows trunca automáticamente el hostname si supera ese límite, generando riesgo de colisiones.
Solución adoptada: nombre corto para AD (ver sección 2.3.1). El FQDN completo del servidor se conserva en el atributo description del objeto AD y en CMDB.
Para resolver definitivamente la limitación de 15 caracteres, se define un nombre corto exclusivo para el objeto de equipo en AD. Este nombre no sustituye al hostname DNS; es el nombre con el que el servidor se une al dominio.
Estructura: BCL-<PAIS>SV-<ID>
| Componente | Descripción |
|---|---|
BCL | Prefijo corporativo Becall (Be Call, empresa del grupo propietaria del dominio). |
<PAIS> | Prefijo del código ISO 3166-2 del país donde está físicamente el servidor (ES, PT, FR…). Para servidores en regiones cloud genéricas, se usa el país del datacenter físico (p. ej., un nodo en eus2 ubicado en Madrid → ES). |
SV | Infijo fijo que identifica el objeto como servidor. Evita colisiones con objetos de equipo de usuario en AD. |
<ID> | Identificador aleatorio de 5 caracteres alfanuméricos (A–Z, 0–9) en mayúsculas. 36⁵ = 60.466.176 combinaciones únicas por país. |
Reglas de uso:
description del objeto AD y en CMDB como fuente de verdad operativa (p. ej., es-m-dmg-prd-fsr-001.prd.es-m.dmg.becall.local). Usar el FQDN —no solo el hostname— permite identificar inequívocamente el entorno, la ubicación y el dominio directamente desde la consola de AD, sin necesidad de consultar CMDB.<ID> generado no existe ya en AD antes de asignarlo.Atributo dNSHostName (gestionado automáticamente por Windows):
Al unir un servidor al dominio, Windows rellena automáticamente el atributo dNSHostName con el nombre corto de AD más el sufijo del dominio AD (p. ej., BCL-ESSV-K2M9P.becall.local). Este atributo no debe confundirse con el FQDN operativo definido en la sección 3.2:
| Atributo | Ejemplo | Gestión | Uso |
|---|---|---|---|
dNSHostName | BCL-ESSV-K2M9P.becall.local | Automática (Windows) | Resolución interna por Kerberos / LDAP |
description | es-m-dmg-prd-fsr-001.prd.es-m.dmg.becall.local | Manual (según este estándar) | Identificación operativa en consola AD y CMDB |
FQDN DNS (becall.net o becall.local) | es-m-dmg-prd-fsr-001.prd.es-m.dmg.becall.local | DNS interno / Cloudflare | Acceso de red y monitorización |
El
dNSHostNameresuelve al nombre corto de AD, no al hostname DNS largo. Los sistemas de monitorización y CMDB deben usar el FQDN DNS (campodescriptiono registro CMDB), nuncadNSHostName, para referenciar el servidor.
<LOC>-<PLT>-<ENV>-<ROL>-<NNN>| Campo | Descripción | Longitud | Ejemplos |
|---|---|---|---|
LOC | Ubicación geográfica (ISO 3166-2 completo en minúsculas) | 4–6 chars | es-m, es-b, pt-11, fr-75, euw1 |
PLT | Plataforma / Proveedor | 3–4 chars | dmg, aws, azr, gcp, onp |
ENV | Entorno | 3 chars | prd, pre, tst, dev, lab |
ROL | Rol funcional | 2–4 chars | app, web, dbs, api, mq |
NNN | Secuencia numérica | 3 dígitos | 001, 002, 099 |
Ejemplo completo:
es-m-onp-prd-dir-001Advertencia — Capitalización del campo
LOC: en la Parte I (servidores), el campoLOCse escribe siempre en minúsculas (es-m,pt-11). En la Parte II (equipos de usuario), se escribe en mayúsculas (ES-M,PT-11). Esta diferencia es intencionada y permite distinguir visualmente ambos inventarios. Todos los pipelines de automatización deben aplicar la transformación correspondiente según el tipo de activo. Véase Anexo C para expresiones regulares de validación.
<hostname>.<env>.<loc>.<provider>.<dominio_corporativo>Dominio corporativo:
| Dominio | Uso | Gestión |
|---|---|---|
becall.net | Zona pública y servicios expuestos a internet | Cloudflare |
becall.local | Zona interna de Active Directory (uso transitorio) | DNS interno del DC |
Nota de transición: el uso de
.localcomo sufijo de dominio de AD no está recomendado por las mejores prácticas actuales (conflictos con mDNS/Bonjour, incompatibilidad con ciertos servicios cloud). El objetivo es migrar todos los registros internos abecall.netgestionado con split-horizon DNS (ver sección 7.2). Mientras la migración no esté completada,becall.localse mantiene como dominio interno válido y debe contemplarse en todas las herramientas de validación.
Ejemplo (zona pública / becall.net):
es-m-onp-prd-dir-001.prd.es-m.onp.becall.netEjemplo (zona interna / becall.local — uso transitorio):
es-m-dmg-prd-fsr-001.prd.es-m.dmg.becall.localLOC) — ISO 3166-2 completo en minúsculasSe usa el código ISO 3166-2 completo (incluyendo el prefijo de país) en minúsculas. Para regiones cloud genéricas (sin subdivisión geográfica concreta), se usan códigos de región abreviados.
Sedes actuales con infraestructura de servidor:
| Código LOC | Ubicación | Código ISO 3166-2 oficial |
|---|---|---|
es-m | Madrid, España | ES-M |
es-b | Barcelona, España | ES-B |
pt-11 | Lisboa, Portugal | PT-11 |
fr-75 | París, Francia | FR-75 |
Regiones cloud genéricas:
| Código | Descripción | País físico real |
|---|---|---|
euw1 | Europa Oeste 1 (eu-west-1) | Irlanda (Dublin) |
euw3 | Europa Oeste 3 (eu-west-3) | Francia |
eus2 | Europa Sur 2 (eu-south-2) | España |
euc1 | Europa Central 1 (eu-central-1) | Alemania |
use1 | US Este 1 (us-east-1) | EEUU Este |
usw2 | US Oeste 2 (us-west-2) | EEUU Oeste |
Cuando se usa un código de región cloud genérico como
LOC, el campo<PAIS>del nombre corto de AD se determina por el país físico real del datacenter (ver sección 2.3.1).
PLT)| Código | Proveedor / Plataforma |
|---|---|
onp | On-Premise (CPD propio) — incluye servidores físicos y VMs cuando el hipervisor no es operativamente relevante |
dmg | DMG Cloud |
aws | Amazon Web Services |
azr | Microsoft Azure |
gcp | Google Cloud Platform |
vmw | VMware vSphere — usar exclusivamente para los propios hipervisores VMware (ROL: hvs) |
kvm | KVM / Proxmox — usar exclusivamente para los propios hipervisores KVM/Proxmox (ROL: hvs) |
Criterio de uso
onpvsvmw/kvm: usaronppara todos los servidores on-premise (físicos y VMs). Reservarvmwykvmúnicamente para los servidores que actúan como hipervisores (ROLhvs), donde identificar la plataforma de virtualización tiene relevancia operativa directa. Las VMs que corren sobre esos hipervisores siguen usandoonp.
ENV)| Código | Descripción |
|---|---|
prd | Producción |
pre | Preproducción |
tst | Testing / QA |
dev | Desarrollo |
lab | Laboratorio / PoC |
ROL)| Código | Descripción |
|---|---|
app | Servidor de aplicación general |
api | Backend API / Microservicios |
web | Servidor web (frontend) |
job | Servidor de jobs / batch |
mq | Servidor de mensajería (RabbitMQ, Kafka) |
cti | Servidor de Contact Center / CTI (integración PBX, grabación de llamadas, OCM, etc.) |
mail | Servidor de correo (SMTP/IMAP/POP3, Exchange, Postfix, etc.) |
| Código | Descripción |
|---|---|
dbs | Servidor de base de datos |
dbc | Clúster de base de datos |
rds | Réplica de lectura DB |
| Código | Descripción |
|---|---|
dir | Directorio (Active Directory, LDAP) |
dns | Servidor DNS |
dhcp | Servidor DHCP |
vpn | VPN Gateway (software) |
prx | Proxy / Reverse Proxy |
fwl | Firewall aplicativo (software) |
| Código | Descripción |
|---|---|
mon | Monitorización (Prometheus, Zabbix, Wazuh, etc.) |
log | Logs centralizados (ELK, Graylog) |
cfg | Configuración / Orquestación (Ansible, Puppet) |
bkp | Servidor de backup |
| Código | Descripción |
|---|---|
fsr | File Server (SMB / NFS) |
nas | NAS / Storage Appliance |
s3g | Object Storage Gateway |
| Código | Descripción |
|---|---|
hvs | Hypervisor Server |
kmn | Kubernetes Master / Control Plane |
kwn | Kubernetes Worker Node |
dkr | Docker Host |
| Código | Descripción |
|---|---|
rtr | Router L3 |
swt | Switch L2/L3 |
fwh | Firewall Hardware |
vpnh | VPN Hardware Gateway |
lbh | Load Balancer Hardware |
pdu | PDU (Power Distribution Unit) |
ups | SAI / UPS |
pbx | Servidor PBX / centralita IP (Asterisk, FreePBX, SBC, etc.) |
NNN)001, 002, 003… 999 (siempre 3 dígitos con ceros a la izquierda).001–999. El valor 000 está explícitamente excluido y no debe asignarse bajo ninguna circunstancia.001–099 para nodos principales, 101–199 para réplicas).Nota operativa — LOC de un solo carácter tras el guion: algunos códigos ISO 3166-2 producen segmentos de un solo carácter en el campo
LOC(p. ej.,es-m→ Madrid,es-b→ Barcelona,es-a→ Alicante). Visualmente, el guion separador y el carácter de subdivisión pueden confundirse con un guion simple. Al construir o validar hostnames con estos códigos, prestar especial atención a que el LOC seaes-my noesnimde forma independiente. Los pipelines de validación deben cubrir esta casuística explícitamente (ver Anexo C).
es-m-dmg-prd-app-001.prd.es-m.dmg.becall.net
es-m-dmg-prd-app-002.prd.es-m.dmg.becall.net
eus2-aws-dev-api-001.dev.eus2.aws.becall.netNodos físicos:
es-m-onp-prd-dbs-001.prd.es-m.onp.becall.net
es-m-onp-prd-dbs-002.prd.es-m.onp.becall.netAliases funcionales (CNAMEs):
prd-db-writer.prd.es-m.onp.becall.net → es-m-onp-prd-dbs-001
prd-db-reader.prd.es-m.onp.becall.net → es-m-onp-prd-dbs-002es-m-dmg-prd-web-001.prd.es-m.dmg.becall.net
es-m-dmg-prd-web-002.prd.es-m.dmg.becall.net
www.becall.net → prd-web-vip.prd.es-m.dmg.becall.net (CNAME/VIP)es-m-onp-prd-dir-001.prd.es-m.onp.becall.net
es-m-onp-prd-dns-001.prd.es-m.onp.becall.net
es-m-dmg-prd-mon-001.prd.es-m.dmg.becall.net
es-m-dmg-prd-bkp-001.prd.es-m.dmg.becall.netes-m-onp-prd-hvs-001.prd.es-m.onp.becall.net
es-m-vmw-prd-hvs-002.prd.es-m.vmw.becall.netControl plane:
eus2-aws-prd-kmn-001.prd.eus2.aws.becall.net
eus2-aws-prd-kmn-002.prd.eus2.aws.becall.netWorkers:
eus2-aws-prd-kwn-001.prd.eus2.aws.becall.net
eus2-aws-prd-kwn-002.prd.eus2.aws.becall.netLos equipos de red siguen el mismo patrón general: <LOC>-<PLT>-<ENV>-<ROL>-<NNN>. Un dispositivo de red puede ser on-premise o estar en cloud (p. ej., un router virtual en AWS).
es-m-onp-prd-rtr-001.prd.es-m.onp.becall.net
es-m-onp-prd-swt-001.prd.es-m.onp.becall.net
es-m-onp-prd-fwh-001.prd.es-m.onp.becall.net
euw1-aws-prd-rtr-001.prd.euw1.aws.becall.netNota: el dominio interno de Active Directory es
becall.local. Los FQDNs internos usanbecall.localen lugar debecall.net. La zona públicabecall.netse gestiona en Cloudflare para servicios expuestos a internet.
BCL-<PAIS>SV-<ID> verificando que no existan colisiones en AD.activo, IP, SO, proveedor, propietario, BU, centro de coste y proyecto. Registrar también el nombre corto de AD.becall.net → crear registro en Cloudflare.becall.local (zona interna, uso transitorio) → crear registro en el DNS interno del DC (Windows DNS). No crear registros becall.local en Cloudflare.description (p. ej., es-m-dmg-prd-app-001.prd.es-m.dmg.becall.net).Si un servidor cambia de ubicación geográfica (diferente código ISO 3166-2 en LOC), se debe renombrar para reflejar la nueva ubicación.
LOC actualizado.description en el objeto AD con el nuevo FQDN completo.Nota: si el cambio de ubicación implica cambio de país, se genera un nuevo nombre corto de AD con el prefijo ISO 3166-2 del nuevo país.
PLT actualizado; usar CNAMEs funcionales para transición transparente.decomisionado con fecha y motivo.Zona raíz: becall.net
Subzonas delegadas por proveedor y entorno:
prd.es-m.dmg.becall.net (Producción DMG Cloud Madrid)
dev.es-m.dmg.becall.net (Desarrollo DMG Cloud Madrid)
prd.eus2.aws.becall.net (Producción AWS EU South — Madrid)
prd.es-m.onp.becall.net (Producción On-Premise Madrid)Subzonas DNS internas (becall.local) creadas en el DC:
dmg.becall.local (DMG Cloud — DNS interno)
es-m.dmg.becall.local (DMG Cloud Madrid — DNS interno)
prd.es-m.dmg.becall.local (Producción DMG Cloud Madrid — DNS interno)*.dmg.becall.net o *.onp.becall.net, resolver vía DNS privado.sql2022, win2019).becall.local para registros DNS de servidores internos de AD hasta que se complete la migración a becall.net con split-horizon (ver sección 3.2 y sección 7.2).becall.net o becall.local) para facilitar la planificación de la migración.| Campo | Valor |
|---|---|
| Hostname DNS | es-m-dmg-prd-app-001 |
| FQDN | es-m-dmg-prd-app-001.prd.es-m.dmg.becall.net |
| Nombre corto AD | BCL-ESSV-A1B2C |
| sAMAccountName | BCL-ESSV-A1B2C$ |
| Descripción AD | es-m-dmg-prd-app-001.prd.es-m.dmg.becall.net |
| IP Privada | 10.20.30.40 |
| SO | Windows Server 2022 |
| BU (en CMDB) | A3/ERP |
| Etiquetas cloud | BU=a3erp, Environment=production, ManagedBy=terraform |
| Campo | Valor |
|---|---|
| Hostname DNS | es-m-onp-dev-dbs-001 |
| FQDN | es-m-onp-dev-dbs-001.dev.es-m.onp.becall.net |
| Nombre corto AD | BCL-ESSV-D4E5F |
| sAMAccountName | BCL-ESSV-D4E5F$ |
| Descripción AD | es-m-onp-dev-dbs-001.dev.es-m.onp.becall.net |
| IP Privada | 172.16.10.50 |
| SO | Ubuntu 22.04 LTS |
| BU (en CMDB) | Corporativo / IT Interno |
| Campo | Valor |
|---|---|
| Hostname DNS | eus2-aws-prd-kwn-005 |
| FQDN | eus2-aws-prd-kwn-005.prd.eus2.aws.becall.net |
| Nombre corto AD | BCL-ESSV-G7H8I |
| sAMAccountName | BCL-ESSV-G7H8I$ |
| Descripción AD | eus2-aws-prd-kwn-005.prd.eus2.aws.becall.net |
| IP Privada | 10.100.5.20 |
| SO | Amazon Linux 2 |
| BU (en CMDB) | Finanzas |
| Etiquetas AWS | BU=finanzas, Environment=production, K8sCluster=prod-01 |
| Campo | Valor |
|---|---|
| Hostname DNS | es-m-onp-prd-rtr-001 |
| FQDN | es-m-onp-prd-rtr-001.prd.es-m.onp.becall.net |
| IP Gestión | 192.168.1.1 |
| Fabricante | Cisco |
| BU (en CMDB) | Infraestructura / Shared Services |
Nota: los equipos de red con roles
rtr,swt,fwh,vpnh,lbh,pduyupsno se unen al dominio de Active Directory y, por tanto, no requieren nombre corto AD nisAMAccountName. Su gestión se realiza mediante credenciales locales o sistemas de gestión de red (NMS) específicos.
| Campo | Valor |
|---|---|
| Hostname DNS | es-m-dmg-prd-fsr-001 |
| FQDN | es-m-dmg-prd-fsr-001.prd.es-m.dmg.becall.local |
| Nombre corto AD | BCL-ESSV-K2M9P |
| sAMAccountName | BCL-ESSV-K2M9P$ |
| Descripción AD | es-m-dmg-prd-fsr-001.prd.es-m.dmg.becall.local |
| IP Privada | 172.30.0.20 |
| SO | Windows Server |
| BU (en CMDB) | Infraestructura / IT Interno |
Aplica a todos los equipos de usuario (portátiles, sobremesas, tablets, teléfonos corporativos, etc.). Los servidores se cubren en la Parte I.
BCL-<LOC>-<NNN>| Campo | Descripción |
|---|---|
BCL | Prefijo corporativo Becall (Be Call, empresa del grupo). |
<LOC> | Código ISO 3166-2 completo en mayúsculas correspondiente a la sede de adscripción del empleado al que está asignado el equipo (p. ej., ES-M para Madrid, ES-LE para León, PT-11 para Lisboa). |
<NNN> | Contador numérico secuencial de 3 dígitos global por sede (LOC). Rango 001–999. |
Sede de adscripción vs. ubicación física:
LOCrefleja la sede organizativa a la que pertenece el empleado, no dónde está el equipo en cada momento. Un trabajador en remoto conserva el código de su sede de referencia. La ubicación física real se registra en CMDB y en el atributolocationde AD si es relevante para soporte o logística.
Ejemplos:
BCL-ES-M-001 (Equipo asignado a empleado de la sede de Madrid)
BCL-ES-LE-001 (Equipo asignado a empleado de la sede de León)
BCL-ES-B-001 (Equipo asignado a empleado de la sede de Barcelona)
BCL-PT-11-001 (Equipo asignado a empleado de la sede de Lisboa)El código
LOCes el mismo estándar ISO 3166-2 que en servidores, en mayúsculas. Esto permite cruzar datos de CMDB entre ambos inventarios de forma directa.
Advertencia — Diferencia de capitalización entre Parte I y Parte II: el campo
LOCse escribe en minúsculas en hostnames de servidor (es-m,pt-11) y en mayúsculas en nombres de equipo de usuario (ES-M,PT-11). Esta diferencia es intencionada y facilita distinguir visualmente ambos inventarios, pero puede provocar errores si se construyen nombres de forma manual o en scripts que mezclan ambas convenciones. Todos los pipelines de automatización deben aplicar la transformación de mayúsculas/minúsculas según el tipo de activo. Véase Anexo C para expresiones regulares de validación.
LOC (ISO 3166-2 completo en mayúsculas)Sedes actuales Becall:
| Código LOC | Provincia / Ciudad |
|---|---|
ES-LE | León |
ES-AV | Ávila |
ES-M | Madrid |
ES-O | Asturias (Gijón) |
ES-B | Barcelona |
ES-A | Alicante |
Expansión internacional (ejemplos):
| Código LOC | Localidad |
|---|---|
PT-11 | Lisboa, Portugal |
FR-75 | París, Francia |
DE-BE | Berlín, Alemania |
IT-RM | Roma, Italia |
GB-LND | Londres, Reino Unido |
NNN (Contador secuencial)001 a 999, siempre 3 dígitos con ceros a la izquierda.001–999. El valor 000 está explícitamente excluido y no debe asignarse bajo ninguna circunstancia. Los sistemas de inventario y los pipelines de validación deben rechazar cualquier nombre que contenga -000 como sufijo.LOC): todos los equipos de una misma sede comparten la misma serie numérica, independientemente del tipo de dispositivo.El tipo de dispositivo no forma parte del nombre del equipo. Se registra como atributo en CMDB y en Active Directory:
| Tipo | Valor recomendado en CMDB / AD |
|---|---|
| Laptop / Portátil | LP |
| Desktop / Sobremesa | DT |
| Workstation (alto rendimiento) | WK |
| Tablet | TB |
| Teléfono corporativo (móvil) | PH |
| All-in-One | AIO |
| Otros (casos especiales) | OT |
El nuevo patrón BCL-<LOC>-<NNN> produce nombres que caben dentro del límite de 15 caracteres de sAMAccountName en la mayoría de casos, eliminando el problema de truncado que existía con el patrón anterior.
| Nombre de equipo | Longitud | ¿Entra en 15 chars? |
|---|---|---|
BCL-ES-M-001 | 13 chars | Sin truncado |
BCL-ES-LE-001 | 14 chars | Sin truncado |
BCL-ES-AV-001 | 14 chars | Sin truncado |
BCL-PT-11-001 | 14 chars | Sin truncado |
BCL-GB-LND-001 | 15 chars | Sin truncado (límite exacto) |
El nombre del equipo se usa directamente como cn y sAMAccountName en AD sin necesidad de nombre corto adicional.
LOC representa la sede de adscripción del empleado, no su ubicación física en cada momento.location de AD y en CMDB, pero no afecta al nombre del equipo.LOC y consultar el siguiente NNN disponible para esa sede.location en AD con la nueva sede.Ejemplo: empleado de León trasladado definitivamente a Ávila. Su portátil BCL-ES-LE-015 pasa a llamarse BCL-ES-AV-004 (asumiendo que el último equipo registrado en Ávila era el 003).
| Atributo AD | Contenido |
|---|---|
description | Nombre completo del equipo, usuario asignado, modelo, número de serie del fabricante. |
extensionAttribute1 | Tipo de dispositivo (LP, DT, WK, TB, PH, AIO, OT). |
location / physicalDeliveryOfficeName | Ubicación física actual: sede, edificio, planta, sala o “Remoto – domicilio”. |
extensionAttribute2–15 | Datos personalizados: centro de coste, proyecto, etc. |
| Nombre | Tipo (en CMDB/AD) | Sede de adscripción |
|---|---|---|
BCL-ES-LE-001 | LP | León |
BCL-ES-LE-002 | DT | León |
BCL-ES-AV-001 | DT | Ávila |
BCL-ES-M-001 | LP | Madrid |
BCL-ES-M-002 | WK | Madrid |
BCL-ES-O-001 | LP | Gijón (Asturias) |
BCL-ES-B-001 | LP | Barcelona |
BCL-ES-B-002 | AIO | Barcelona |
BCL-ES-A-001 | TB | Alicante |
BCL-PT-11-001 | LP | Lisboa (Portugal) |
BCL-FR-75-001 | LP | París (Francia) |
BCL-<LOC>-TST-<NNN> (p. ej., BCL-ES-M-TST-001) seguido de identificador libre, documentado en inventario. El campo <LOC> sigue el mismo formato ISO 3166-2 en mayúsculas que el resto de la Parte II.BCL-<LOC>-TMP-<NNN> (p. ej., BCL-ES-LE-TMP-001) hasta asignación definitiva a un empleado y sede. El campo <LOC> indica la sede de origen o almacén del equipo.Nota: los nombres de excepción
TSTyTMPno pasan el regex estándar C.4 (que valida el patrónBCL-<LOC>-<NNN>). Deben validarse con un patrón específico de excepciones y registrarse explícitamente en CMDB con el campotipo_nombre = excepcion.
Esta sección regula el tratamiento de los servidores que existían antes de la publicación del presente estándar (versión 1.1, marzo 2026) y que por tanto tienen nombres no conformes.
Al publicarse este estándar, todos los servidores existentes deben ser inventariados en CMDB con el campo conformidad_nomenclatura con uno de estos valores:
| Valor | Descripción |
|---|---|
conforme | El nombre cumple el estándar en todos sus campos. |
no_conforme | El nombre no cumple el estándar (nombre libre, formato incorrecto, nombre corto AD no aleatorio, etc.). |
exento | El servidor ha sido declarado exento por el Comité de Nomenclatura con justificación documentada. |
Los servidores no_conforme deben ser migrados al nuevo estándar en un plazo máximo de 6 meses desde la publicación de este estándar (fecha límite: 17 de septiembre de 2026), siguiendo este orden de prioridad:
| Prioridad | Criterio | Plazo máximo |
|---|---|---|
| 1 — Alta | Servidores de producción (prd) con nombre libre o ininteligible | 2 meses (17/05/2026) |
| 2 — Media | Servidores de producción con nombre parcialmente conforme (p. ej., ID AD no aleatorio) | 4 meses (17/07/2026) |
| 3 — Baja | Servidores de entornos no productivos (pre, tst, dev, lab) | 6 meses (17/09/2026) |
Durante el período de migración, para cada servidor no_conforme se debe registrar en CMDB:
nombre_actual: el nombre en uso hoy.nombre_objetivo: el nombre conforme al estándar que tendrá tras la migración.fecha_migracion_prevista: fecha estimada de renombrado.responsable: equipo o persona encargada de ejecutar el renombrado.El renombrado sigue el mismo procedimiento de la sección 6.2 (Cambio de Ubicación Geográfica), con estas particularidades:
nombre_corto_ad_anterior.description en AD con el nuevo FQDN completo.conformidad_nomenclatura = conforme, registrar nombre anterior y fecha de migración.Los servidores que no puedan migrarse en el plazo establecido (p. ej., por dependencias críticas de aplicación, restricciones contractuales de soporte o servidores en proceso inminente de decomisión) pueden ser declarados exentos por el Comité de Nomenclatura. Toda exención debe:
LOC, PLT, ENV, ROL), tabla de mapeo BU → etiquetas cloud, ejemplos por tipo de dispositivo, procedimiento para solicitar nuevos códigos e histórico de cambios.Responsables: Equipo de Arquitectura / Plataforma IT.
Funciones:
Proceso de aprobación de nuevos códigos:
Referencia completa de códigos para el campo LOC con sede en España:
| ISO 3166-2 | Provincia | ISO 3166-2 | Provincia |
|---|---|---|---|
ES-VI | Álava | ES-M | Madrid |
ES-AB | Albacete | ES-MA | Málaga |
ES-A | Alicante | ES-MU | Murcia |
ES-AL | Almería | ES-NA | Navarra |
ES-AV | Ávila | ES-OR | Ourense |
ES-BA | Badajoz | ES-O | Asturias |
ES-PM | Illes Balears | ES-P | Palencia |
ES-B | Barcelona | ES-GC | Las Palmas |
ES-BU | Burgos | ES-PO | Pontevedra |
ES-CC | Cáceres | ES-SA | Salamanca |
ES-CA | Cádiz | ES-TF | S.C. Tenerife |
ES-CS | Castellón | ES-S | Cantabria |
ES-CR | Ciudad Real | ES-SG | Segovia |
ES-CO | Córdoba | ES-SE | Sevilla |
ES-C | A Coruña | ES-SO | Soria |
ES-CU | Cuenca | ES-T | Tarragona |
ES-GI | Girona | ES-TE | Teruel |
ES-GR | Granada | ES-TO | Toledo |
ES-GU | Guadalajara | ES-V | Valencia |
ES-SS | Gipuzkoa | ES-VA | Valladolid |
ES-H | Huelva | ES-BI | Bizkaia |
ES-HU | Huesca | ES-ZA | Zamora |
ES-J | Jaén | ES-Z | Zaragoza |
ES-LE | León | ES-CE | Ceuta |
ES-L | Lleida | ES-ML | Melilla |
ES-LO | La Rioja | ||
ES-LU | Lugo |
Este anexo proporciona patrones regex formales para validar los nombres definidos en este estándar. Están diseñados para su uso directo en pipelines CI/CD (Terraform, Ansible), scripts de aprovisionamiento y herramientas de auditoría de CMDB.
Convención: todos los patrones se expresan como anclas completas (
^...$) para evitar coincidencias parciales. Los ejemplos se muestran en sintaxis compatible con Python (re), JavaScript (RegExp) y herramientas POSIX ERE.
Patrón: <LOC>-<PLT>-<ENV>-<ROL>-<NNN>
^(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)-(onp|dmg|aws|azr|gcp|vmw|kvm)-(prd|pre|tst|dev|lab)-(app|api|web|job|mq|dbs|dbc|rds|dir|dns|dhcp|vpn|prx|fwl|mon|log|cfg|bkp|fsr|nas|s3g|hvs|kmn|kwn|dkr|rtr|swt|fwh|vpnh|lbh|pdu|ups|cti|mail|pbx)-([0-9]{3})$Restricciones adicionales aplicadas por este regex:
| Restricción | Aplicación |
|---|---|
| Solo minúsculas y guiones | Todos los segmentos en minúsculas; [0-9]{3} para NNN |
NNN de exactamente 3 dígitos | [0-9]{3} — rechaza 1, 01, 0001 |
NNN != 000 | Validar programáticamente: int(nnn) >= 1 tras capturar el grupo |
| Longitud total <= 63 chars | Validar programáticamente tras el match |
Ejemplo de uso en Python:
import re
HOSTNAME_RE = re.compile(
r'^(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)'
r'-(onp|dmg|aws|azr|gcp|vmw|kvm)'
r'-(prd|pre|tst|dev|lab)'
r'-(app|api|web|job|mq|dbs|dbc|rds|dir|dns|dhcp|vpn|prx|fwl'
r'|mon|log|cfg|bkp|fsr|nas|s3g|hvs|kmn|kwn|dkr|rtr|swt|fwh|vpnh|lbh|pdu|ups)'
r'-([0-9]{3})$'
)
def validate_server_hostname(name: str) -> bool:
m = HOSTNAME_RE.match(name)
if not m:
return False
nnn = int(m.group(5))
return 1 <= nnn <= 999 and len(name) <= 63Ejemplo de uso en JavaScript:
const HOSTNAME_RE = /^(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)-(onp|dmg|aws|azr|gcp|vmw|kvm)-(prd|pre|tst|dev|lab)-(app|api|web|job|mq|dbs|dbc|rds|dir|dns|dhcp|vpn|prx|fwl|mon|log|cfg|bkp|fsr|nas|s3g|hvs|kmn|kwn|dkr|rtr|swt|fwh|vpnh|lbh|pdu|ups)-([0-9]{3})$/;
function validateServerHostname(name) {
const m = name.match(HOSTNAME_RE);
if (!m) return false;
const nnn = parseInt(m[5], 10);
return nnn >= 1 && nnn <= 999 && name.length <= 63;
}Patrón: <hostname>.<env>.<loc>.<provider>.<dominio_corporativo>
Dos dominios en uso (estado transitorio): durante el período de migración de
becall.localabecall.net, los validadores deben aceptar ambos sufijos. El dominio objetivo a largo plazo esbecall.netcon split-horizon DNS (ver sección 3.2).
Patrón zona pública (becall.net):
^[a-z][a-z0-9-]{0,61}[a-z0-9]\.(prd|pre|tst|dev|lab)\.(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)\.(onp|dmg|aws|azr|gcp|vmw|kvm)\.becall\.net$Patrón zona interna (becall.local — uso transitorio):
^[a-z][a-z0-9-]{0,61}[a-z0-9]\.(prd|pre|tst|dev|lab)\.(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)\.(onp|dmg|aws|azr|gcp|vmw|kvm)\.becall\.local$Notas:
[a-z][a-z0-9-]{0,61}[a-z0-9]) sigue RFC 1034: empieza por letra, termina en letra o dígito, máximo 63 chars.. y comparar los campos individualmente (ver C.1).Ejemplo en Python:
import re
FQDN_NET_RE = re.compile(
r'^[a-z][a-z0-9-]{0,61}[a-z0-9]'
r'\.(prd|pre|tst|dev|lab)'
r'\.(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)'
r'\.(onp|dmg|aws|azr|gcp|vmw|kvm)'
r'\.becall\.net$'
)
# Transitorio: válido mientras existan servidores en becall.local
FQDN_LOCAL_RE = re.compile(
r'^[a-z][a-z0-9-]{0,61}[a-z0-9]'
r'\.(prd|pre|tst|dev|lab)'
r'\.(es-m|es-b|pt-11|fr-75|euw1|euw3|eus2|euc1|use1|usw2)'
r'\.(onp|dmg|aws|azr|gcp|vmw|kvm)'
r'\.becall\.local$'
)
def validate_fqdn(fqdn: str) -> bool:
if len(fqdn) > 255:
return False
return bool(FQDN_NET_RE.match(fqdn) or FQDN_LOCAL_RE.match(fqdn))Patrón: BCL-<PAIS2>SV-<ID5>
^BCL-([A-Z]{2})SV-([A-Z0-9]{5})$Restricciones adicionales:
| Restricción | Aplicación |
|---|---|
| Longitud total <= 15 chars | BCL- (4) + 2 + SV- (3) + 5 = 14 chars con paises de 2 chars — siempre dentro del limite |
<PAIS> en lista aprobada | Validar contra: ES, PT, FR, DE, GB, IT, IE, US |
<ID> unico en AD | Verificación programática contra AD antes de asignar |
Ejemplo en Python:
import re
AD_SHORT_SRV_RE = re.compile(r'^BCL-([A-Z]{2})SV-([A-Z0-9]{5})$')
VALID_COUNTRIES = {'ES', 'PT', 'FR', 'DE', 'GB', 'IT', 'IE', 'US'}
def validate_ad_short_server(name: str) -> bool:
m = AD_SHORT_SRV_RE.match(name)
if not m:
return False
return m.group(1) in VALID_COUNTRIES and len(name) <= 15Patrón: BCL-<LOC_MAYUS>-<NNN>
El campo <LOC> admite los códigos ISO 3166-2 de las sedes aprobadas. Por su variabilidad, se recomienda validar el LOC contra la tabla maestra en lugar de codificarlo en el regex. El patrón base valida la estructura:
^BCL-([A-Z]{2,3}-[A-Z0-9]{1,3})-([0-9]{3})$Este patrón cubre la forma general ISO 3166-2 (
XX-YYoXX-YYY). Para validación estricta, complementar con la lista de sedes aprobadas.
Restricciones adicionales:
| Restricción | Aplicación |
|---|---|
NNN != 000 | int(nnn) >= 1 tras capturar el grupo |
| Longitud total <= 15 chars | Validar len(name) <= 15 |
LOC en lista de sedes aprobadas | Verificar contra tabla maestra de LOC |
Ejemplo en Python:
import re
USER_DEVICE_RE = re.compile(r'^BCL-([A-Z]{2,3}-[A-Z0-9]{1,3})-([0-9]{3})$')
APPROVED_LOC = {
'ES-LE', 'ES-AV', 'ES-M', 'ES-O', 'ES-B', 'ES-A',
'PT-11', 'FR-75', 'DE-BE', 'IT-RM', 'GB-LND',
# Anadir nuevas sedes aqui tras aprobacion del Comite de Nomenclatura
}
def validate_user_device(name: str) -> bool:
m = USER_DEVICE_RE.match(name)
if not m:
return False
loc = m.group(1)
nnn = int(m.group(2))
return loc in APPROVED_LOC and nnn >= 1 and len(name) <= 15Ejemplo en JavaScript:
const USER_DEVICE_RE = /^BCL-([A-Z]{2,3}-[A-Z0-9]{1,3})-([0-9]{3})$/;
const APPROVED_LOC = new Set(['ES-LE','ES-AV','ES-M','ES-O','ES-B','ES-A','PT-11','FR-75','DE-BE','IT-RM','GB-LND']);
function validateUserDevice(name) {
const m = name.match(USER_DEVICE_RE);
if (!m) return false;
const nnn = parseInt(m[2], 10);
return APPROVED_LOC.has(m[1]) && nnn >= 1 && name.length <= 15;
}Los patrones completos con todos los valores enumerados se encuentran en las secciones C.1–C.4. Esta tabla es solo un índice de referencia rápida.
| Ámbito | Patrón (esquemático — ver sección indicada) | Validaciones adicionales |
|---|---|---|
| Hostname servidor | ^(LOC)-(PLT)-(ENV)-(ROL)-([0-9]{3})$ — ver C.1 | NNN >= 001; longitud <= 63 |
FQDN servidor (becall.net) | ^hostname.(ENV).(LOC).(PLT).becall.net$ — ver C.2 | Longitud <= 255; coherencia ENV hostname vs subzona |
FQDN servidor (becall.local, transitorio) | ^hostname.(ENV).(LOC).(PLT).becall.local$ — ver C.2 | Longitud <= 255; coherencia ENV hostname vs subzona |
| Nombre corto AD servidor | ^BCL-([A-Z]{2})SV-([A-Z0-9]{5})$ — ver C.3 | País en lista aprobada; ID único en AD; longitud <= 15 |
| Equipo de usuario | ^BCL-([A-Z]{2,3}-[A-Z0-9]{1,3})-([0-9]{3})$ — ver C.4 | NNN >= 001; LOC en lista aprobada; longitud <= 15 |
Mantenimiento: cuando se añadan nuevos códigos
LOC,PLT,ENVoROLal estándar, actualizar simultáneamente los patrones de este Anexo C y el documento maestro de códigos (sección 18.1). El Comité de Nomenclatura es responsable de mantener la sincronía entre ambos.