Guía de API de políticas de dirección de gestión de tráfico

Utilice la API de REST de Oracle Cloud Infrastructure DNS para crear y configurar políticas de gestión de tráfico.

Utilice la siguiente guía para obtener más información sobre cómo se crean las políticas con la API de REST de DNS.

Autenticación y autorización

Cada servicio de Oracle Cloud Infrastructure se integra con IAM con fines de autenticación y autorización para todas las interfaces (la consola, el SDK o la CLI, y la API de REST).

Un administrador de una organización tiene que configurar grupos, compartimentos y políticas que controlen qué usuarios pueden acceder a qué servicios, recursos y el tipo de acceso. Por ejemplo, las políticas controlan quién puede crear usuarios nuevos, crear y gestionar la red en la nube, crear instancias, crear cubos, descargar objetos, etc. Para obtener más información, consulte Gestión de dominios de identidad. Para obtener detalles específicos sobre la escritura de políticas de los distintos servicios, consulte Referencia de políticas.

Si es un usuario normal (no un administrador) que debe utilizar los recursos de Oracle Cloud Infrastructure que posee la compañía, póngase en contacto con un administrador para configurar su ID de usuario. El administrador puede confirmar qué compartimento o compartimentos puede utilizar.

Componentes de la política de dirección de gestión de tráfico

La siguiente lista describe los componentes utilizados para crear una política de dirección de gestión de tráfico.

POLÍTICAS DE DIRECCIÓN: Una estructura global para definir el comportamiento de gestión de tráfico para las zonas. Las políticas de dirección contienen reglas que ayudan a proporcionar respuestas de DNS de forma inteligente.
ASOCIACIONES: Permite enlazar una política de dirección a zonas. Una asociación de una política de dirección a una zona ocluye todos los registros de su dominio que son de un tipo de registro cubierto, construyendo respuestas de DNS a partir de su política de dirección en lugar de a partir de esos registros del dominio. Un dominio puede tener como máximo una asociación que cubra cualquier tipo de registro concreto.
REGLAS: Las políticas de dirección de directrices se utilizan para filtrar las respuestas según las propiedades de una solicitud de DNS, como la geolocalización de solicitudes o el estado de los puntos finales.
RESPUESTAS: Las respuestas contienen los datos de registro de DNS y los metadatos que se procesarán en una política de dirección.
PLANTILLAS: Las plantillas son secuencias de reglas predefinidas que crean un tipo de política y su comportamiento previsto. Ejemplo: la plantilla FAILOVER proporciona respuestas comprobando primero la consulta de DNS en una regla FILTER y, a continuación, las siguientes reglas sucesivamente: HEALTH, PRIORITY y LIMIT. Esto proporciona la capacidad de failover dinámico de dominio. Las políticas que definen el campo template con cualquier política que no sea CUSTOM deben seguir la secuencia de reglas indicada para ese tipo de política; de lo contrario, se devuelve un error de código de estado 400 al crear la política.
CASOS: Una regla puede incluir opcionalmente una secuencia de casos que definen configuraciones alternativas para el comportamiento durante el procesamiento de una consulta de DNS concreta. Cuando una regla no tiene una secuencia de casos, siempre se evalúa con la misma configuración durante el procesamiento. Cuando una regla tiene una secuencia de casos vacía, siempre se ignora durante el procesamiento. Cuando una regla tiene una secuencia de casos que no está vacía, su comportamiento durante el procesamiento lo configura el primer caso de coincidencia en la secuencia. Un caso de regla sin caseCondition siempre coincide. Un caso de regla con caseCondition solo coincide cuando dicha expresión se evalúa como verdadera para la consulta específica.

Creación de políticas de dirección con plantillas

En la siguiente sección se explica la configuración de reglas para cada tipo de plantilla de política de dirección seguida de una solicitud POST de ejemplo ( CreateSteeringPolicy ) que muestra cómo configurar cada plantilla.

FAILOVER

Políticas de failover del usuario para priorizar el orden en el que se proporcionan las respuestas en una política (por ejemplo, Principal y Secundario). Las supervisiones y los sondeos a demanda de Oracle Cloud Infrastructure Health Checks se aprovechan para evaluar el estado de las respuestas en la política. Si se detecta que la respuesta principal no está en perfectas condiciones, el tráfico de DNS se dirige automáticamente a la respuesta secundaria. Cada una de las siguientes reglas se debe definir en el orden especificado en el campo rules del cuerpo de la solicitud al utilizar una plantilla FAILOVER:


Orden	Regla	Restricciones	Comentarios
`1`	`FILTRO`	No se permiten casos. Los datos de respuesta se deben definir en `defaultAnswerData` utilizando el siguiente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`ESTADO`	No se permiten casos.	Solo se incluye si se define `healthCheckMonitorId` para la política.
`3`	`PRIORIDAD`	No se permiten casos. Los datos de respuesta se deben definir en la propiedad `defaultAnswerData` para la regla. Cada respuesta debe tener una propiedad de pool. `defaultAnswerData` restricciones: No se puede hacer referencia a las respuestas por su propiedad de nombre en expresiones `answerCondition`, su propiedad de pool debe hacer referencia a ellas. Se debe hacer referencia a cada grupo de respuestas una y otra vez. PRIORIDAD PRIORIDAD
`4`	`LÍMITE`	No se permiten casos.

Ejemplo de una política POST /steeringPolicies al utilizar la plantilla FAILOVER:

{
  "compartmentId": "ocid1...",
  "displayName": "failover between endpoints",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "FAILOVER",
  "answers": [
    {
      "name": "server-primary",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "primary"
    },
    {
      "name": "server-secondary",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "secondary"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.pool == 'primary'",
          "value": 1
        },
        {
          "answerCondition": "answer.pool == 'secondary'",
          "value": 99
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

LOAD_BALANCE

Las políticas del equilibrador de carga distribuyen el tráfico entre varios puntos finales. Puede asignar pesos iguales a los puntos finales para distribuir el tráfico de manera uniforme entre los puntos finales o puede asignar pesos personalizados para el equilibrio de carga de ratio. Se aprovechan las supervisiones y los sondeos a demanda de Oracle Cloud Infrastructure Health Checks para evaluar el estado del punto final. El tráfico de DNS se distribuye automáticamente a los otros puntos finales, si se detecta que un punto final no está en buen estado. Cada una de las siguientes reglas se debe definir en el orden especificado en el campo rules del cuerpo de la solicitud al utilizar una plantilla LOAD_BALANCE:


Orden	Regla	Restricciones	Comentarios
`1`	`FILTRO`	No se permiten casos. Los datos de respuesta se deben definir en `defaultAnswerData` utilizando el siguiente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`ESTADO`	No se permiten casos.	Solo se incluye si se define `healthCheckMonitorId` para la política.
`3`	`PESADO`	No se permiten casos. Los datos de respuesta se deben definir en la propiedad defaultAnswerData para la regla. Su propiedad de pool no puede hacer referencia a las respuestas en las expresiones answerCondition, su propiedad de nombre debe hacer referencia a ellas.
`4`	`LÍMITE`	No se permiten casos.

Ejemplo de una política POST /steeringPolicies mediante la plantilla LOAD_BALANCE:

{
  "compartmentId": "ocid1...",
  "displayName": "Weighted load balance for a set of answers with health checks",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "LOAD_BALANCE",
  "answers": [
    {
      "name": "server1",
      "rtype": "A",
      "rdata": "192.168.0.2"
    },
    {
      "name": "server2",
      "rtype": "A",
      "rdata": "192.168.0.3"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "WEIGHTED",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.name == 'server1'",
          "value": 99
        },
        {
          "answerCondition": "answer.name == 'server2'",
          "value": 1
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_GEO

Las políticas de geolocalización basadas en políticas de dirección distribuyen el tráfico de DNS a diferentes puntos finales según la ubicación del usuario final. Los clientes pueden definir regiones geográficas compuestas por el continente de origen, los países o estados/provincias (Norteamérica) y definir un punto final independiente o un juego de puntos finales para cada región. Cada una de las siguientes reglas se debe definir en el orden especificado en el campo rules del cuerpo de la solicitud al utilizar una plantilla ROUTE_BY_GEO:


Orden	Regla	Restricciones	Comentarios
`1`	`FILTRO`	No se permiten casos. Los datos de respuesta se deben definir en `defaultAnswerData` utilizando el siguiente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`ESTADO`	No se permiten casos.	Solo se incluye si se define `healthCheckMonitorId` para la política.
`3`	`PRIORIDAD`	La propiedad `defaultAnswerData` no se puede utilizar en esta regla. Debe definir al menos un caso. Si hay muchos casos, el caso final puede proporcionar un caso de "captura total". La propiedad `caseCondition` en los casos solo puede utilizar `query.client.geoKey` en la expresión condicional. No se puede hacer referencia a las respuestas por su propiedad de nombre en expresiones `answerCondition`, su propiedad de pool debe hacer referencia a ellas. Cada respuesta debe tener una propiedad de pool. Para `answerData` de cada caso: Se debe hacer referencia a cada grupo de respuestas una y otra vez. Cada pool de respuestas debe tener una propiedad de valor única (en el caso). Cada referencia del pool de respuestas debe coincidir con la propiedad del pool en una o varias respuestas definidas en la lista de respuestas para la política.
`4`	`LÍMITE`	No se permiten casos.

Ejemplo de cuerpo de solicitud POST /steeringPolicies con la plantilla ROUTE_BY_GEO:

{
  "compartmentId": "ocid1...",
  "displayName": "Geolocations mapped to answer pools",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "ROUTE_BY_GEO",
  "answers": [
    {
      "name": "US Server 1",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "US"
    },
    {
      "name": "US Server 2",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "US"
    },
    {
      "name": "EU Server 1",
      "rtype": "A",
      "rdata": "192.168.0.4",
      "pool": "EU"
    },
    {
      "name": "EU Server 2",
      "rtype": "A",
      "rdata": "192.168.0.5",
      "pool": "EU"
    },
    {
      "name": "rest of world 1",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Global"
    },
    {
      "name": "rest of world 2",
      "rtype": "A",
      "rdata": "203.0.113.3",
      "pool": "Global"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.geoKey in (geoKey '6255149')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.geokey in (geokey '6255148')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_ASN

Las políticas de dirección basadas en ASN permiten dirigir el tráfico de DNS en función de números de sistema autónomos (ASN). Las consultas de DNS que se originan a partir de un ASN específico o un juego de ASN se pueden dirigir a un punto final especificado. Cada una de las siguientes reglas se debe definir en el orden especificado en el campo rules del cuerpo de la solicitud al utilizar una plantilla ROUTE_BY_ASN:


Orden	Regla	Restricciones	Comentarios
`1`	`FILTRO`	No se permiten casos. Los datos de respuesta se deben definir en `defaultAnswerData` utilizando el siguiente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`ESTADO`	No se permiten casos.	Solo se incluye si se define `healthCheckMonitorId` para la política.
`3`	`PRIORIDAD`	La propiedad defaultAnswerData no se puede utilizar en esta regla. Debe definir al menos un caso. Si hay muchos casos, el caso final puede proporcionar un caso de "captura total". La propiedad caseCondition en los casos solo puede utilizar query.client.asn en la expresión condicional. No se puede hacer referencia a las respuestas por su propiedad de nombre en expresiones answerCondition, su propiedad de pool debe hacer referencia a ellas. LÍMITE Para answerData de cada caso: Cada grupo de respuestas se debe hacer referencia una y otra vez. Cada pool de respuestas debe tener una propiedad de valor única (en el caso). Cada referencia del pool de respuestas debe coincidir con la propiedad del pool en una o más respuestas definidas en la lista de respuestas de la política.
`4`	`LÍMITE`	No se permiten casos.

Ejemplo de cuerpo de solicitud POST /steeringPolicies con la plantilla ROUTE_BY_ASN:

{
  "compartmentId": "ocid1...",
  "displayName": "ASNs mapped to pools",
  "ttl": 30,
  "template": "ROUTE_BY_ASN",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.asn == 3",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.asn == 16591",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_IP

Las políticas de dirección basadas en prefijos de IP permiten a los clientes dirigir el tráfico DNS basado en el prefijo de IP de la consulta de origen. Cada una de las siguientes reglas se debe definir en el orden especificado en el campo rules del cuerpo de la solicitud al utilizar una plantilla ROUTE_BY_IP:


Orden	Regla	Restricciones	Comentarios
`1`	`FILTRO`	No se permiten casos. Los datos de respuesta se deben definir en `defaultAnswerData` utilizando el siguiente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`ESTADO`	No se permiten casos.	Solo se incluye si se define `healthCheckMonitorId` para la política.
`3`	`PRIORIDAD`	La propiedad `defaultAnswerData` no se puede utilizar en esta regla. Debe definir al menos un caso. Si hay muchos casos, el caso final puede proporcionar un caso de "captura total". La propiedad `caseCondition` de los casos sólo puede utilizar query.client.address en la expresión condicional. No se puede hacer referencia a las respuestas por su propiedad de nombre en expresiones `answerCondition`, su propiedad de pool debe hacer referencia a ellas. Cada respuesta debe tener una propiedad de pool. Para `answerData` de cada caso: Se debe hacer referencia a cada grupo de respuestas una y otra vez. Cada pool de respuestas debe tener una propiedad de valor única (en el caso). Cada referencia del pool de respuestas debe coincidir con la propiedad del pool en una o varias respuestas definidas en la lista de respuestas para la política.
`4`	`LÍMITE`	No se permiten casos.

Ejemplo de cuerpo de solicitud POST /steeringPolicies con la plantilla ROUTE_BY_IP:

{
  "compartmentId": "ocid1...",
  "displayName": "IP subnets mapped to answer pools",
  "ttl": 30,
  "template": "ROUTE_BY_IP",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.address in (subnet '10.0.3.0/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.address in (subnet '192.0.2.2/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

PERSONALIZADA

Utilice políticas personalizadas para crear políticas complejas que combinan las capacidades de failover, equilibrio de carga, geolocalización, dirección de prefijo de IP y ASN. Las plantillas personalizadas no necesitan una secuencia reglamentada de reglas, por lo que recomendamos que se ponga en contacto con el servicio de soporte de Oracle Cloud Infrastructure antes de crear una política personalizada.

Tipos de reglas

FILTRO: Utiliza datos booleanos asociados a respuestas, que mantienen las respuestas solo si el valor shouldKeep de la regla es true.
ESTADO: Utiliza supervisiones y sondeos bajo demanda de OCI Health Checks para evaluar el estado de los puntos finales y agregar y eliminar respuestas de la política según sea necesario. Se debe hacer referencia a una supervisión de comprobación del sistema en una regla de estado para afectar a la política. Para obtener más información sobre Comprobaciones del sistema, consulte Comprobaciones del sistema.
PONDERADA: Utiliza un número entre 0 y 255 utilizado para evaluar la frecuencia con la que se proporciona una respuesta en relación a otras respuestas. Es más probable que se devuelvan respuestas con valores más altos.
PRIORIDAD: Utiliza un entero asociado a cada respuesta para ordenar las respuestas del valor más bajo al más alto. Ejemplo: se devolverá una respuesta con un valor de prioridad de 1 antes de una respuesta con un valor de prioridad de 10 en la lista de respuestas. Las respuestas que no tienen un valor de prioridad asignado se mueven al final de la lista de respuestas.
LÍMITE: Utiliza una propiedad de recuento para filtrar todas las respuestas, excepto las primeras de la lista.

Documentación de Oracle Cloud Infrastructure