DNS: El protocolo que nadie ve...hasta que se convierte en el problema más grande de la arquitectura
En el día a día de operación, el DNS rara vez está en el centro de la conversación. No suele ser el protagonista de los roadmaps, ni el primer punto que se revisa en un diseño nuevo. Muchas veces se asume que "ya está ahí", funcionando, resolviendo nombres sin mayor fricción. Y eso es precisamente lo peligroso. Después de años trabajando con arquitecturas empresariales y de Service Providers, hay una constante difícil de ignorar: el DNS es uno de los componentes más críticos de la infraestructura moderna y, al mismo tiempo, uno de los más subestimados. Cuando todo funciona, nadie pregunta por él. Cuando algo falla, todo lo demás deja de importar. He visto aplicaciones "arriba", enlaces estables, firewalls en verde... pero usuarios incapaces de acceder a un servicio. El problema no estaba en la aplicación ni en la red, sino en ese primer paso que todos damos por sentado: resolver un nombre. DNS en la vida real: cuando la teoría se encuentra con la operación En el papel, el DNS parece simple, pero en producción, no lo es. En arquitecturas reales, el DNS participa activamente en decisiones críticas como: A qué sitio o región se dirige un usuario Qué backend recibe una solicitud Cómo se distribuye la carga entre múltiples data centers Qué tan rápido se recupera un servicio ante una degradación o caída En Service Providers y grandes organizaciones, esto se vuelve evidente durante eventos inesperados. Un sismo, una noticia de alto impacto, un evento deportivo global, una actualización urgente de una aplicación, una app que se vuelve tendencia, un anuncio gubernamental o una contingencia sanitaria pueden disparar el tráfico digital en cuestión de minutos. En estos escenarios, el primer crecimiento significativo no ocurre en HTTP ni en TLS, sino en las consultas DNS. Millones de usuarios abren aplicaciones, refrescan portales y generan resoluciones simultáneas hacia los mismos dominios. Si el DNS no está preparado para absorber ese pico: La aplicación nunca recibe tráfico Los balanceadores no alcanzan a participar La experiencia del usuario se degrada de inmediato Aquí es donde soluciones como F5 BIG-IP DNS dejan de ser un "servicio de nombres" y se convierten en un componente activo de control de tráfico, capaz de tomar decisiones basadas en: Estado real de los servicios Salud de los backends Políticas de disponibilidad y continuidad El boom de la inteligencia artificial y su impacto directo en DNS La llegada masiva de la Inteligencia Artificial no solo ha cambiado cómo se consumen aplicaciones; ha cambiado radicalmente el patrón del tráfico. Las arquitecturas modernas de IA introducen: Más microservicios desacoplados Más APIs internas y externas Endpoints efímeros que aparecen y desaparecen Resoluciones dinámicas y frecuentes Cada llamada a un modelo, cada inferencia distribuida y cada backend que escala automáticamente comienza con una consulta DNS. Pero el impacto va mucho más allá de la teoría. Los datos de 2025 lo confirman de forma contundente: Según Humansecurity, el tráfico generado por sistemas de inteligencia artificial casi se triplicó en un solo año, con un crecimiento mensual del 187% entre enero y diciembre. Y dentro de ese universo, el segmento que más creció fue el de agentes autónomos de IA — bots que ya no solo leen la web, sino que interactúan con ella: navegan, consultan APIs, completan transacciones. Ese tipo de tráfico creció más de un 7,800% interanual. ¿Qué significa esto para el DNS? Cada vez que un agente de IA resuelve una consulta, busca un endpoint o escala un servicio, hay una resolución DNS detrás. Y no estamos hablando de patrones predecibles. El tráfico de IA se comporta de forma diferente al tráfico humano: es más agresivo en ráfagas, menos predecible en horarios, y crece a un ritmo ocho veces mayor que el tráfico generado por personas. A esto se suma que los crawlers de IA — los sistemas que rastrean contenido para entrenamiento, búsqueda y acciones en tiempo real — se han convertido en una de las fuentes más grandes de tráfico automatizado en internet. Durante 2025, solo el crawler de Google generó aproximadamente el 4.5% de todas las solicitudes HTML hacia sitios protegidos por las principales plataformas de seguridad. Y el crawling por "acción de usuario" (cuando un usuario le pide algo a un chatbot y este sale a buscar información en la web) creció más de 15 veces en el mismo periodo. Desde una perspectiva técnica, esto tiene implicaciones claras: Crecimiento sostenido y acelerado del volumen de consultas DNS Mayor sensibilidad a latencia y jitter en la resolución Mayor impacto de fallas parciales o intermitentes Patrones de tráfico menos predecibles y más difíciles de planificar El DNS deja de ser infraestructura "estática" y se convierte en un componente dinámico del plano de datos, íntimamente ligado al desempeño de los modelos y servicios de IA. Y quien no esté dimensionando su infraestructura DNS con esta variable en mente, va a sentir el impacto más temprano que tarde. El DNS como punto crítico en eventos globales A lo largo de los años, múltiples eventos han demostrado el impacto del DNS a escala global. Desde interrupciones masivas de servicios digitales hasta ataques de amplificación, el patrón es consistente: cuando el DNS se ve afectado, el impacto se multiplica. Y no hay que ir lejos para encontrar ejemplos. Solo en octubre de 2025, dos incidentes dejaron muy claro lo que pasa cuando el DNS falla en entornos de producción reales. En el primero, un error en el sistema automatizado de gestión DNS de una de las principales plataformas de nube pública dejó inaccesibles servicios críticos en la región más grande de su infraestructura. Los servidores estaban operativos, las bases de datos intactas... pero el DNS los hacía invisibles. La falla se propagó en cascada a más de cien servicios, afectó a miles de empresas en más de 60 países y generó millones de reportes de caída en cuestión de horas. Plataformas de mensajería, gaming, streaming, servicios financieros y hasta aplicaciones gubernamentales quedaron fuera de línea. No fue un ataque. Fue un error de automatización en DNS. Días después, un proveedor de telecomunicaciones europeo con millones de clientes de red fija experimentó una falla de resolución DNS que dejó sin acceso a internet a gran parte de su base de usuarios durante varias horas. El tráfico observado cayó más del 75%. Y la causa raíz fue, nuevamente, un problema de resolución DNS — no un corte de fibra, no un ataque DDoS, no una caída de energía. F5 Labs ha documentado ampliamente cómo: Ataques volumétricos utilizan DNS como vector principal La amplificación DNS sigue siendo una técnica efectiva Eventos globales generan patrones de tráfico anómalos que exponen debilidades de diseño Estos escenarios no distinguen industria ni tamaño. Afectan por igual a proveedores de servicios, plataformas digitales, infraestructura crítica y aplicaciones empresariales. La diferencia no está en si ocurren, sino en qué tan preparada está la arquitectura para absorberlos sin colapsar. Primero la observabilidad: entender antes de reaccionar Durante mucho tiempo, el DNS fue una caja negra. Funcionaba... o no. Hoy, la conversación cambia por completo cuando incorporamos observabilidad real a la ecuación. F5 Insight, componente clave dentro de la plataforma F5 ADSP, permite: Analizar patrones reales de consultas Identificar picos atípicos y comportamientos anómalos Correlacionar eventos externos con tráfico DNS Entender el porqué detrás del comportamiento del sistema Pero F5 Insight va más allá de dashboards y métricas. Incorpora inteligencia artificial para ofrecer guía proactiva, detección de anomalías y algo que cambia la forma de operar: la capacidad de interactuar con tus datos operacionales en lenguaje natural, usando integración con LLMs y el Model Context Protocol (MCP). En la práctica, esto significa pasar de revisar dashboards buscando qué pasó, a recibir narrativas operacionales que te dicen qué está pasando, por qué, y qué deberías priorizar. Para entornos con alta densidad de consultas DNS, donde los patrones cambian en minutos y los picos pueden ser impredecibles,especialmente con el crecimiento del tráfico de IA, ese salto de reactivo a proactivo no es un lujo, es una necesidad operativa. En escenarios de alto QPS, el problema no siempre es la capacidad, sino cómo se comporta el tráfico. Ver el DNS como datos, no solo como servicio, marca una diferencia enorme en operación y planeación.Plataforma y arquitectura: cuando el DNS ya no es "básico" Plataforma y arquitectura: cuando el DNS ya no es "básico" Cuando el DNS se vuelve crítico, la plataforma importa. Arquitecturas basadas en VELOS permiten separar capacidad, resiliencia y crecimiento del ciclo de vida de la aplicación, soportando cargas DNS masivas con aislamiento, alta disponibilidad y escalamiento ordenado. Por su parte, rSeries ofrece un modelo más compacto y eficiente, ideal para despliegues donde el rendimiento por unidad, la latencia y la eficiencia operativa son clave. Y cuando la aplicación ya no vive en un solo data center, F5 Distributed Cloud Services extiende las capacidades del DNS a arquitecturas híbridas y multicloud, manteniendo: Políticas consistentes Visibilidad unificada Control desde el edge hasta el backend El punto no es dónde corre el DNS, sino que acompañe a la aplicación sin perder control, resiliencia ni observabilidad. Seguridad integrada desde el primer paquete El DNS también es una superficie de ataque. Lo hemos comprobado una y otra vez durante eventos de seguridad globales. Y el panorama no se está simplificando: durante 2025, se identificaron más de 100 millones de dominios nuevos, de los cuales una cuarta parte fue clasificada como maliciosos o sospechosos. Los atacantes están registrando volúmenes sin precedentes de dominios, usando automatización para montar campañas masivas que evaden defensas tradicionales. Ignorar al DNS desde el punto de vista de seguridad es dejar una puerta abierta. Integrar protección dentro de la misma plataforma de entrega permite: Mitigar ataques sin introducir latencia adicional Aplicar políticas de forma consistente Mantener visibilidad unificada del tráfico Seguridad, rendimiento y disponibilidad no son capas separadas; son partes del mismo flujo. En ocasiones olvidamos Que el DNS no suele fallar de forma dramática. Falla de forma silenciosa... y por eso es tan peligroso. Invertir en su diseño, observabilidad y seguridad no es sobreingeniería. Es entender que todo empieza ahí. En un mundo donde la IA está triplicando el volumen de tráfico automatizado año con año, donde los agentes autónomos generan resoluciones DNS a un ritmo que no existía hace 18 meses, y donde un solo error de automatización en DNS puede dejar fuera a miles de empresas en más de 60 países... el DNS vuelve a ocupar el lugar que siempre tuvo en la arquitectura, aunque muchos lo hayan olvidado. La pregunta no es si el DNS es crítico. La pregunta es si tu arquitectura está lista para tratarlo como tal.F5 DNS/GTM External Monitor(EAV) with SNI support and response code check
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. The example DNS/GTM health monitor is for versions before 16.1 as BIG-IP supports SNI for default DNS/GTM HTTPS monitor in the latest version but if you have still not upgraded then this is for you! I have used this monitor for XC Distributed Cloud as the HTTP LB share by default the same tenant IP address and SNI support is needed. You can order dedicated public IP addresses for each HTTP LB and enable "Default Load Balancer" ( https://my.f5.com/manage/s/article/K000152902 ) option but it will cost you extra 😉 The script is a modified version of External https health monitor for SNI-enabled pool as to handle response codes and to set the SNI globally for the entire pool and it's members. If you are uploading from Windows machine see External monitor fails to run as you could hit the bug. This could be needed for F5 DNS/GTM below 16.1 that do not support SNI in HTTPS monitors. The only mandatory variable is "SNI" that should be set in the external monitor config that references this uploaded bash script. The "URI" variable by default is set to "/" and "$2" variable by default is empty or 443, the default expected response code 200. #!/bin/sh # External monitoring script for checking HTTP status code # $1 = IP (::ffff:nnn.nnn.nnn.nnn notation or hostname) # $2 = port (optional; defaults to 443 if not provided) # Default SNI to IP if not explicitly provided node_ip=$(echo "$1" | sed 's/::ffff://') # Remove IPv6 compatibility prefix SNI=${SNI:-"$node_ip"} # Assign sanitized IP to SNI # Default variables MON_NAME=${MON_NAME:-"MyExtMon$$"} pidfile="/var/run/$MON_NAME.$1..$2.pid" # PID file path DEBUG=${DEBUG:-0} # Enable debugging if set to 1 EXPECTED_STATUS=${EXPECTED_STATUS:-200} # Default HTTP status code to 200 URI=${URI:-"/"} # Default URI DEFAULT_PORT=443 # Default port (used if $2 is unset) # Set port to default if $2 is not provided if [ -z "${2}" ]; then PORT=${DEFAULT_PORT} else PORT=${2} fi # Kill old process if pidfile exists if [ -f "$pidfile" ]; then kill -9 -$(cat "$pidfile") > /dev/null 2>&1 fi echo "$$" > "$pidfile" # Perform the HTTP(S) request via single curl (fetch status code only) status_code=$(curl -s -o /dev/null -w '%{http_code}' --connect-timeout 5 --resolve "${SNI}:${PORT}:${node_ip}" "https://${SNI}:${PORT}${URI}") # Cleanup rm -f "$pidfile" > /dev/null 2>&1 # Output server status based on HTTP status code match if [ "$status_code" -eq "$EXPECTED_STATUS" ]; then echo "up" else echo "down" fi # Debugging if [ "$DEBUG" -eq 1 ]; then echo "Debugging on..." echo "SNI=${SNI}" echo "URI=${URI}" echo "IP=${node_ip}" echo "PORT=${PORT}" echo "MON_NAME=${MON_NAME}" echo "STATUS_CODE=${status_code}" echo "EXPECTED_STATUS=${EXPECTED_STATUS}" echo "curl -s -o /dev/null -w '%{http_code}' --connect-timeout 5 --resolve ${SNI}:${PORT}:${node_ip} https://${SNI}:${PORT}${URI}" fiF5 BIG-IP iRule based TCL DNS server
Short Description This code is for the purpose if there is a need to return a custom DNS reply not from the main DNS server but from the F5 Virtual Server. Problem solved by this Code Snippet The code is meant for small lab or dev environments as F5 has F5 DNS/GTM for replying to DNS requests with Intelligent Load Balancing, DNS Express Memory cache etc. How to use this Code Snippet Modify the irule code to configure the custom domain you want replies from the irule code and not the real DNS server. Add the irule to a DNS UDP LB Code Snippet Meta Information Version: 17.1 Coding Language: TCL Code You can find the code and further documentation in my GitHub repository: irule_dns/irule1 at main · Nikoolayy1/irule_dns (github.com)
DNS lite with topology selection
Problem this snippet solves: 19/12/2017 : add lowercase conversion of the requested name to support case insensitive request. BIGIP DNS is a really great product to load balance DNS requests to the best Datacenter. This codes is not a solution to replace the DNS product but to provide a solution to manage small DNS needs. This code isn't full RFC compliant but provide an internal DNS server supporting only A and AAAA query types. The goal of this code was to permit to manage datacenter HA for a single application (exchange in my case). This code search for the preferred network in a data group based on the DNS client IP source. Then, If the request is www.example.com and there is a LTM pool named p_gtm_lite_www.example.com (with virtual servers as members), the active pool members are compared to the preferred network. If no pool member matches the preferred network, the last pool member is selected (no LB is enabled) If the pool does not exist, a NXDOMAIN is answered. How to use this snippet: create a Datagroup named gtm_lite_topology ltm data-group internal gtm_lite_topology { records { 0.0.0.0 { data 192.168.2.0/24 } 192.168.1.0/24 { data 192.168.1.0/24 } } type ip } create a LTM pool with VS as members. don't forget to enable LTM monitor. Note: The pool name must be lowercase. ltm pool p_gtm_lite_www.example.com { members { vs2:https { address 192.168.2.237 } vs1:https { address 192.168.1.237 } } } change domain name in variable static::domain Change the max dns members in response in variable static::dns_max_response Code : when RULE_INIT { set static::DNS_TTL 30 set static::dns_max_response 2 } when CLIENT_ACCEPTED { # Initiate response flags to ANSWER; 16 bits with first set to 1 # qr(1) opcode(0000) AA(1) TC(0) RD(0) RA(0) Z(000) RCODE(0000) ################################################### # DNS RCODE Assignment as defined in RFC 2929 # RCODE Name Description Reference # 0 NoError No Error [RFC 1035] # 1 FormErr Format Error [RFC 1035] # 2 ServFail Server Failure [RFC 1035] # 3 NXDomain Non-Existent Domain [RFC 1035] # 4 NotImp Not Implemented [RFC 1035] # 5 Refused Query Refused [RFC 1035] # 6 YXDomain Name Exists when it should not [RFC 2136] # 7 YXRRSet RR Set Exists when it should not [RFC 2136] # 8 NXRRSet RR Set that should exist does not [RFC 2136] # 9 NotAuth Server Not Authoritative for zone [RFC 2136] # 10 NotZone Name not contained in zone [RFC 2136] # 16 BADVERS Bad OPT Version [RFC 2671] # 16 BADSIG TSIG Signature Failure [RFC 2845] # 17 BADKEY Key not recognized [RFC 2845] # 18 BADTIME Signature out of time window [RFC 2845] # 19 BADMODE Bad TKEY Mode [RFC 2930] # 20 BADNAME Duplicate key name [RFC 2930] # 21 BADALG Algorithm not supported [RFC 2930] set RESPONSE_FLAGS "1000010000000000" # Initiate response resources. each resource type is created in a list allowing multiple resources of same type. set QUESTION_LIST [list]; set ANSWER_LIST [list]; set AUTHORITY_LIST [list]; set ADDITIONAL_LIST [list] # Decode UDP DNS request. If all variables are not set, drop the request if {[binary scan [UDP::payload] SB16SSSSH* ID REQUEST_FLAGS QDCOUNT ANCOUNT NSCOUNT ARCOUNT RESOURCES] < 7} { drop; return } # If ANSWER resource exists or different than 1 question, drop the request if {$ANCOUNT > 0 || $QDCOUNT != 1} { # change RCODE to value 5 (0101) : Refused set RESPONSE_FLAGS [string replace $RESPONSE_FLAGS 12 15 "0101"] } else { # According to RFC, a security-aware name server MUST copy the CD bit from a query into the corresponding response set RESPONSE_FLAGS [string replace $RESPONSE_FLAGS 7 7 [string index $REQUEST_FLAGS 7]] set RESPONSE_FLAGS [string replace $RESPONSE_FLAGS 11 11 [string index $REQUEST_FLAGS 11]] ################################################### ###### extract query name, type and class from resources # DNS Question format as defined in RFC 1035 # - NAME : 255 octets or less containing a sequence of labels (63 octets or less). # - TYPE: two octets containing one of the RR TYPE codes. # - CLASS: two octets containing one of the RR CLASS codes. set QNAME_LIST {} set index 1 set BIN_RESOURCES [binary format H* $RESOURCES] # Read the first label length binary scan $BIN_RESOURCES c label_length while {$index < [string length $BIN_RESOURCES]} { # Read label and the next label length binary scan $BIN_RESOURCES @${index}A${label_length}c label_value next_length lappend QNAME_LIST "$label_value" set index [expr {$index + 1 + $label_length}] set label_length $next_length if {$label_length == 0} { binary scan $BIN_RESOURCES @${index}SS TYPE CLASS #binary scan $BIN_RESOURCES H[expr {$index * 2}] QNAME_HEX # pointer C00C means 12 bytes from ID --> start of Question label set QNAME_HEX "C00C" # extract Question record to insert it in the response binary scan $BIN_RESOURCES H[expr {$index * 2 + 8}] QUESTION_HEX # append Question record in Question RR list lappend QUESTION_LIST $QUESTION_HEX # Join all labels with dot separator. set QNAME [string tolower [join $QNAME_LIST "."]] break } } unset index if {$TYPE == 12 && $QNAME ends_with ".in-addr.arpa"} { if {[scan $QNAME "%d.%d.%d.%d" d c b a] == 4 && [IP::addr "$a.$b.$c.$d" equals [IP::local_addr]] } { set data "" foreach label [split [string tolower [info hostname]] "."] { binary scan [binary format cA* [string length $label] $label] H* tmp append data $tmp } append data "00" log local0. $data binary scan [binary format H*SSISH* $QNAME_HEX ${TYPE} ${CLASS} ${static::DNS_TTL} [expr {[string length $data] / 2}] ${data}] H* HEX_RESOURCE_RECORD ################################################### # Add the resource record to the Answer RR list lappend ANSWER_LIST $HEX_RESOURCE_RECORD log local0. "[IP::client_addr] / $QNAME : [info hostname] added to list" } } elseif {[catch { set pool_members [active_members -list "p_gtm_lite_$QNAME"] }]} { log local0. "error $QNAME record not exists" # change RCODE to value 3 (0011) : NXDomain set RESPONSE_FLAGS [string replace $RESPONSE_FLAGS 12 15 "0011"] } else { #retreive prefered network from Topology datagroup set PREFERED_NETWORK [class match -value [IP::client_addr] equals gtm_lite_topology] set member_addr_list [list] # sort pool member list to put preferred member first foreach pmember $pool_members { if {$PREFERED_NETWORK equals "" || [IP::addr [set pmember_addr [lindex $pmember 0]] equals $PREFERED_NETWORK]} { set member_addr_list [linsert $member_addr_list 0 $pmember_addr] } else { lappend member_addr_list $pmember_addr } } ################################################### # Create answer(s) based on the requested record type # # DNS Resource record format as defined in RFC 1035 # - NAME : 255 octets or less containing a sequence of labels (63 octets or less) or offset pointer. pointer C00C means 12 bytes from ID --> start of Question label # - TYPE: two octets containing one of the RR TYPE codes. # - CLASS: two octets containing one of the RR CLASS codes. # - TTL: 32 bit signed integer # - RDLENGTH: unsigned 16 bit integer that specifies the length in octets of the RDATA field # - RDATA: a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. switch $TYPE { 1 { # If query type is A foreach item $member_addr_list { if {[llength $ANSWER_LIST] < ${static::dns_max_response}} { #convert IPv4 to hexadecimal if {[scan $item "%d.%d.%d.%d" a b c d] == 4} { set data [format %02x%02x%02x%02x $a $b $c $d] binary scan [binary format H*SSISH* $QNAME_HEX ${TYPE} ${CLASS} ${static::DNS_TTL} [expr {[string length $data] / 2}] ${data}] H* HEX_RESOURCE_RECORD ################################################### # Add the resource record to the Answer RR list lappend ANSWER_LIST $HEX_RESOURCE_RECORD log local0. "[IP::client_addr] / $QNAME : $item added to list" } } else {break} } } 28 { # If query type is AAAA foreach item $member_addr_list { if {[llength $ANSWER_LIST] < ${static::dns_max_response}} { #convert IPv6 to hexadecimal (add missing 0, remove colons) if {$item contains ":"} { if {$item contains "::"} { set ipv6_begin "" foreach val [split [getfield $item "::" 1] ":"] {append ipv6_begin [format %04x 0x$val]} set ipv6_end "" foreach val [split [getfield $item "::" 2] ":"] { append ipv6_end [format %04x 0x$val]} set data "$ipv6_begin[format %0[expr {32 - [string length $ipv6_begin$ipv6_end]}]x 0]$ipv6_end" } else { set data "" foreach val [split $item ":"] {append data [format %04x 0x$val]} } binary scan [binary format H*SSISH* $QNAME_HEX ${TYPE} ${CLASS} ${static::DNS_TTL} [expr {[string length $data] / 2}] ${data}] H* HEX_RESOURCE_RECORD ################################################### # Add the resource record to the Answer RR list lappend ANSWER_LIST $HEX_RESOURCE_RECORD log local0. "[IP::client_addr] / $QNAME : $item added to list" } } else {break} } } } } } ################################################### # DNS Message format as defined in RFC 1035 # - Header : Header section # - ID: A 16 bit identifier assigned by the program that generates any kind of query. # - Flags: Flags containing: #- QR: 1 bit : A one bit field that specifies whether this message is a query (0), or a response (1). #- Opcode: 4 bits : A four bit field that specifies kind of query in this message #- AA: 1 bit : Authoritative Answer #- TC: 1 bit : TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. #- RD: 1 bit : Recursion Desired #- RA: 1 bit : Recursion Available #- Z: 3 bits : Reserved for future use. Must be zero in all queries and responses. #- RCODE : 4 bits : Response code - this 4 bit field is set as part of responses. 0 for NOERROR # - QDCOUNT: unsigned 16 bit integer specifying the number of entries in the question section. # - ANCOUNT: unsigned 16 bit integer specifying the number of entries in the answer section. # - NSCOUNT: unsigned 16 bit integer specifying the number of entries in the authority records section. # - ARCOUNT: unsigned 16 bit integer specifying the number of entries in the additional records section. # - Question: a possibly empty list of concatenated resource records (RRs) # - Answer: a possibly empty list of concatenated resource records (RRs) # - Authority: a possibly empty list of concatenated resource records (RRs) # - Additional: a possibly empty list of concatenated resource records (RRs) drop UDP::respond [binary format SB16SSSSH* ${ID} $RESPONSE_FLAGS [llength $QUESTION_LIST] [llength $ANSWER_LIST] [llength $AUTHORITY_LIST] [llength $ADDITIONAL_LIST] [join ${QUESTION_LIST} ""][join ${ANSWER_LIST} ""][join ${AUTHORITY_LIST} ""][join ${ADDITIONAL_LIST} ""]] } Tested this on version: 11.6
Export GTM/DNS Configuration in CSV - tmsh cli script
Problem this snippet solves: This is a simple cli script used to collect all the WideIP, LB Method, Status, State, Pool Name, Pool LB, Pool Members, Pool Fall back, Last Resort pool info in CSV format. A sample output would be like below, One can customize the code to extract other fields available too. Check out my other codeshare of LTM report. Note: The codeshare may get multiple version, use the latest version alone. The reason to keep the other versions is for end users to understand & compare, thus helping them to modify to their own requirements. Hope it helps. How to use this snippet: Login to the GTM/DNS, create your script by running the below commands and paste the code provided in snippet, tmsh create cli script gtm-config-parser Delete the proc blocks, so it looks something like below, create script gtm-config-parser { ## PASTE THE CODE HERE ## } and paste the code provided in the snippet. Note: When you paste it, the indentation may be realigned, it shouldn't cause any errors, but the list output would show improperly aligned. Feel free to delete the tab spaces in the code snippet & paste it while creating, so indentation is aligned properly. And you can run the script like below, tmsh run cli script gtm-config-parser > /var/tmp/gtm-config-parser-output.csv And get the output from the saved file, open it on excel. Format it & use it for audit & reporting. cat /var/tmp/gtm-config-parser-output.csv Feel free to add more elements as per your requirements. For version 13.x & higher, there requires a small change in the code. Refer the comments section. Thanks to @azblaster Code : proc script::run {} { puts "WIP,LB-MODE,WIP-STATUS,WIP-STATE,POOL-NAME,POOL-LB,POOL-MEMBERS,POOL-FB,LASTRESORT-POOL" foreach { obj } [tmsh::get_config gtm wideip all-properties] { set wipname [tmsh::get_name $obj] set wippools [tmsh::get_field_value $obj pools] set lbmode [tmsh::get_field_value $obj "pool-lb-mode"] set lastresort [tmsh::get_field_value $obj "last-resort-pool"] foreach { status } [tmsh::get_status gtm wideip $wipname] { set wipstatus [tmsh::get_field_value $status "status.availability-state"] set wipstate [tmsh::get_field_value $status "status.enabled-state"] } foreach wippool $wippools { set pool_name [tmsh::get_name $wippool] set pool_configs [tmsh::get_config /gtm pool $pool_name all-properties] foreach pool_config $pool_configs { set pool_lb [tmsh::get_field_value $pool_config "load-balancing-mode"] set pool_fb [tmsh::get_field_value $pool_config "fallback-mode"] if { [catch { set member_name [tmsh::get_field_value $pool_config "members" ]} err] } { set pool_member $err } else { set pool_member "" set member_name [tmsh::get_field_value $pool_config "members"] foreach member $member_name { append pool_member "[lindex $member 1] " } } puts "$wipname,$lbmode,$wipstatus,$wipstate,$pool_name,$pool_lb,$pool_member,$pool_fb,$lastresort" } } } } Tested this on version: 11.6Export GTM/DNS Virtual Servers Configuration in CSV - tmsh cli script
Problem this snippet solves: This is a simple cli script used to collect all the virtual-servers name, its destination created in a server or ltm server. A sample output would be like below, How to use this snippet: This is similar to my other share - https://devcentral.f5.com/s/articles/Export-GTM-DNS-Configuration-in-CSV-tmsh-cli-script Login to the GTM/DNS, create your script by running the below commands and paste the code provided in snippet, tmsh create cli script gtm-vs Delete the proc blocks, so it looks something like below, create script gtm-vs { ## PASTE THE CODE HERE ## } and paste the code provided in the snippet. Note: When you paste it, the indentation may be realigned, it shouldn't cause any errors, but the list output would show improperly aligned. Feel free to delete the tab spaces in the code snippet & paste it while creating, so indentation is aligned properly. And you can run the script like below, tmsh run cli script gtm-vs > /var/tmp/gtm-vs-output.csv And get the output from the saved file, open it on excel. Format it & use it for audit & reporting. cat /var/tmp/gtm-vs-output.csv Feel free to add more elements as per your requirements. Code : proc script::run {} { puts "Server,Virtual-Server,Destination" foreach { obj } [tmsh::get_config gtm server] { set server [tmsh::get_name $obj] foreach { vss } [tmsh::get_config gtm server $server virtual-servers] { set vs_set [tmsh::get_field_value $vss virtual-servers] foreach vs $vs_set { set vs_name [tmsh::get_name $vs] puts $server,$vs_name,[tmsh::get_field_value $vs destination] } } } } Tested this on version: 13.1
BIG-IP DNS Express - Private Zone Blocker
Problem this snippet solves: With BIG-IP DNS; you cannot enable/disable configured DNS Express Zones on a per-listener basis. This makes scenarios where a single BIG-IP DNS system has listeners exposed to internal networks with RFC1918 addresses and public Internet networks. DNS Express doesn't support DNS Views, in short. This iRule allows you to configure a datagroup containing "disabled_zones" and the iRule will validate if the query matches a zone listed in disabled_zones. If it gets a match, it simply returns nothing. Additionally, the iRule examines all responses and checks that resource records in the response do not contain RFC1918 addresses and if it finds them, it removes those Resource Records. All code in the "DNS_RESPONSE" event can be commented or deleted if this behavior isn't desired. How to use this snippet: enable iRule on DNS listener (most likely a listener available only to private network clients) and configure "disabled_zones" data group as shown in example. Log lines can be deleted or commented out once proper operation of the rule is confirmed and understood or retained for purposes of auditing queries that are dropped/blocked. Code : when DNS_REQUEST { log "Got request from: [IP::remote_addr] for [DNS::question name]" if {[class match [DNS::question name] ends_with disabled_zones]}{ log "Query for [DNS::question name] is for a disabled zone - Dropping" DNS::return } } when DNS_RESPONSE { log "Got Response = [DNS::answer]" set rrs [DNS::answer] set privateresponse 0 foreach rr $rrs { log "DNS Response rr: $rr" if {[DNS::type $rr] == "A"}{ if {[class match [DNS::rdata $rr] equals private_net]}{ set privateresponse 1 DNS::answer remove $rr } log "DNS RR data: [DNS::rdata $rr]" } } if {$privateresponse}{ log "DNS response contains private addresses" } } Tested this on version: 13.0
DNS Blackhole
Problem this snippet solves: The blackhole requirement is to intercept DNS requests for prohibited FQDNs, not sent those to BIND for recursive look-up, return a DNS response with an A record to an LTM virtual server, and have a LTM virtual server with a second iRule that will log the request and serve a static page. The solution uses an iRule to the listener virtual server. This virtual server processes all GTM/BIND traffic. Incoming requests are matched against an external data group that contains a list of prohibited FQDNs. This data group file can be edited directly in the GUI at System - File Management - Data Group File List (line terminator should be LF only, not CR-LF). Alternately, the file can be edited manually and re-loaded by doing a "tmsh load sys config verify" then "tmsh load sys config". The blackhole iRule will log all requests for prohibited FQDNs and return a DNS response that matches an LTM virtual server. The blackhole iRule only provides valid responses for A records, however all blackhole DNS requests are logged. How to use this snippet: Create the list of FQDNs for the BIG-IP external data group. Example format is below. File can be stored in /config/Blackhole_Class, although v11.1 provides a method to upload via GUI which is recommended. The second field is the reason why the site was added to the Blackhole class. ".3322.org" := "virus", ".3322.com" := "malware", ".3322.net" := "phishing", Make the external file accessible On Internal-GTM's GUI, go to System - File Management - Data Group File List - Import. File Name: upload Blackhole_Class file Name: Blackhole_Class File Contents: String Key / Value Pair Separator: := Create data group as external file: On Internal-GTM's GUI, go to Local Traffic - iRules - Data Group List - Create Name: Blackhole_Class Type: (External File) Path/Filename: Blackhole_Class File Contents: string Access Mode: Read Only Create the Blackhole iRule On Internal-GTM's GUI, go to Local Traffic - iRules - Create. Name: DNS_blackhole (can be renamed) iRule Source is attached below. Apply the Blackhole iRule to the GTM listener virtual server. Go to Local Traffic - Virtual Servers. Click on the Virtual Server created automatically for the GTM listener. Name will be of form: vs_10_1_1_152_53_gtm, where the first 4 numbers are the IP address of the Listener. Go to the resources tab and assign the DNS_Blackhole iRule created above. Create iFile for the Organization's Logo that will be used with the block page. Download a copy of the image to be used Rename file to corp-logo.gif (optional) Go to System - File Management - iFile List - Import Name: corp-logo.gif Go to Local Traffic - iRules - iFile List - Create Name: corp-logo.gif File name: Create iRule to log client requests and send an HTML page to notify customers they have violated the Blackhole. This iRule should be copied from the attached file. Go to Local Traffic - iRules - Create Name: DNS_blackhole_block_page iRule Source attached below. Create virtual server for client requests. The IP address should match the DNS response defined in ::blackhole_reply in the DNS_Blackhole iRule. Go to Local Traffic - Virtual Servers - Create Name: DNS_blackhole_block_page Destination: 10.1.1.80 (update per local requirements) Port: 80 HTTP profile: http iRules: DNS_blackhole_block_page Code : # DNS Blackhole # This iRule interrogates all queries that arrive on the GTM listener. If the query matches # a list of prohibited FQDNs, a standardized response is given and the request is logged. # This response IP address could be a honeypot server or an LTM virtual server. # Blackhole functionality can be used to prevent malware, virus C2 servers, adware, or other sites. # # Author: Hugh O'Donnell, F5 Consulting # # Usage: # 1) apply to GTM listener virtual server that is defined at Local Traffic - Virtual Servers # 2) create a string data group called "Blackhole_Class". The FQDNs must start with a period. # 3) update the answer static variable with the IP address to return # # Known Issues: # 1) Only A and AAAA records are returned for blackhole requests. The response for other request # types will be logged and returned with no answer. # # Revision history: # 12-11-2011: Initial Revision when RULE_INIT { # Set IPV4 address that is returned for Blackhole matches for A records set static::blackhole_reply_IPV4 "10.1.1.26" # Set IPV6 address that is returned for Blackhole matches for AAAA records set static::blackhole_reply_IPV6 "2001:19b8:101:2::f5f5:1d" # Set TTL used for all Blackhole replies set static::blackhole_ttl "300" } when DNS_REQUEST { # debugging statement see all questions and request details # log -noname local0. "Client: [IP::client_addr] Question:[DNS::question name] Type:[DNS::question type] Class:[DNS::question class] Origin:[DNS::origin]" # Blackhole_Match is used to track when a Query matches the blackhole list # Ensure it is always set to 0 or false at beginning of the DNS request set Blackhole_Match 0 # Blackhole_Type is used to track why this FQDN was added to the Blackhole_Class set Blackhole_Type "" # When the FQDN from the DNS Query is checked against the Blackhole class, the FQDN must start with a # period. This ensures we match a FQDN and all names to the left of it. This prevents against # malware that dynamically prepends characters to the domain name in order to bypass exact matches if {!([DNS::question name] == ".")} { set fqdn_name .[DNS::question name] } if { [class match $fqdn_name ends_with Blackhole_Class] } { # Client made a DNS request for a Blackhole site. set Blackhole_Match 1 set Blackhole_Type [class match -value $fqdn_name ends_with Blackhole_Class ] # Prevent processing by GTM, DNS Express, BIND and GTM Listener's pool. # Want to ensure we don't request a prohibited site and allow their server to identify or track the GTM source IP. DNS::return } } when DNS_RESPONSE { # debugging statement to see all questions and request details # log -noname local0. "Request: $fqdn_name Answer: [DNS::answer] Origin:[DNS::origin] Status: [DNS::header rcode] Flags: RD [DNS::header rd] RA [DNS::header ra]" if { $Blackhole_Match } { # This DNS request was for a Blackhole FQDN. Take different actions based on the request type. switch [DNS::question type] { "A" { # Clear out any DNS responses and insert the custom response. RA header = recursive answer DNS::answer clear DNS::answer insert "[DNS::question name]. $static::blackhole_ttl [DNS::question class] [DNS::question type] $static::blackhole_reply_IPV4" DNS::header ra "1" # log example: Apr 3 14:54:23 local/tmm info tmm[4694]: # Blackhole: 10.1.1.148#4902 requested foo.com query type: A class IN A-response: 10.1.1.60 log -noname local0. "Blackhole: [IP::client_addr]#[UDP::client_port] requested [DNS::question name] query type: [DNS::question type] class [DNS::question class] A-response: $static::blackhole_reply_IPV4 BH type: $Blackhole_Type" } "AAAA" { # Clear out any DNS responses and insert the custom response. RA header = recursive answer DNS::answer clear DNS::answer insert "[DNS::question name]. $static::blackhole_ttl [DNS::question class] [DNS::question type] $static::blackhole_reply_IPV6" DNS::header ra "1" # log example: Apr 3 14:54:23 local/tmm info tmm[4694]: # Blackhole: 10.1.1.148#4902 requested foo.com query type: A class IN AAAA-response: 2001:19b8:101:2::f5f5:1d log -noname local0. "Blackhole: [IP::client_addr]#[UDP::client_port] requested [DNS::question name] query type: [DNS::question type] class [DNS::question class] AAAA-response: $static::blackhole_reply_IPV6 BH type: $Blackhole_Type" } default { # For other record types, e.g. MX, NS, TXT, etc, provide a blank NOERROR response DNS::last_act reject # log example: Apr 3 14:54:23 local/tmm info tmm[4694]: # Blackhole: 10.1.1.148#4902 requested foo.com query type: A class IN unable to respond log -noname local0. "Blackhole: [IP::client_addr]#[UDP::client_port] requested [DNS::question name] query type: [DNS::question type] class [DNS::question class] unable to respond BH type: $Blackhole_Type" } } } } # DNS Blackhole Block Page # # This iRule presents an HTML page to the user and logs details of the HTML request. # It is used in conjuction with the DNS Blackhole iRule to ensure users are aware that # their request was blocked by the Blackhole and actions to take if this block was in error. # # Author: Hugh O'Donnell, F5 Consulting # # Usage: # 1) Add the corporate logo that will be displayed to System - File Management - iFile List # 2) Make the iFile accessible to be used in this iRule by giving associating the iFile name corp_logo_gif # with the iFile at: Local Traffic - iRules - iFile List. # 3) Ensure list of FQDNs in the DNS Blackhole is in a data group called "Blackhole_Class". This can be # verified at Local Traffic - iRules - Data Group List. # 4) Apply this iRule to the port 80 virtual server that the Blackhole iRule sends out, which is specified in variables # static::blackhole_reply_IPV4 and static::blackhole_reply_IPV6 in v11.1+ version of Blackhole iRule when HTTP_REQUEST { # the static HTML pages include the logo that is referenced in HTML as corp-logo.gif # intercept requests for this and reply with the image that is stored in an iFile defined in RULE_INIT below if {[HTTP::uri] ends_with "/_maintenance-page/corp-logo.gif" } { # Present HTTP::respond 200 content $static::corp_logo_gif } else { # Request for Blackhole webpage. Identify what type of block was in place switch -glob [class match -value ".[HTTP::host]" ends_with Blackhole_Class ] { "virus" { set block_reason "Virus site" } "phishing" { set block_reason "Phishing site" } "generic" { set block_reason "Unacceptable Usage" } default { set block_reason "Denied Per Policy - Other Sites" } } # Log details about the blackhole request to the remote syslog server log -noname local0. "Blackhole: From [IP::client_addr]:[TCP::client_port] \ to [IP::local_addr]:[TCP::local_port], [HTTP::request_num], \ [HTTP::method],[HTTP::uri],[HTTP::version], [HTTP::host], [HTTP::header value Referer], \ [HTTP::header User-Agent], [HTTP::header names],[HTTP::cookie names], BH category: $block_reason," # Send an HTML page to the user. The page is defined in the RULE_INIT event below HTTP::respond 200 content "$static::block_page [HTTP::host][HTTP::uri] $static::after_url $block_reason $static::after_block_reason " } } when RULE_INIT { # load the logo that was stored as an iFile set static::corp_logo_gif [ifile get "/Common/corp-logo.gif"] # Beginning of the block page set static::block_page " Web Access Denied - Enterprise Network Operations Center <!-- .mainbody { background-color: #C0C0C0; color: #000000; font-family: Verdana, Geneva, sans-serif; font-size: 12px; margin: 0px; padding: 20px 0px 20px 0px; position: relative; text-align: center; width: 100%; } .bdywrpr { width:996px; height:auto; text-align:left; margin:0 auto; z-index:1; position: relative; } #banner-wrapper { width: 950px; padding: 0px; margin: 0px; overflow:hidden; background-color: #000033; background-repeat: no-repeat; } #banner-image { float: left; margin-left: auto; margin-right: auto; padding: 3px 0px 2px 7px; width: 950px; } #textbody { background-color: #FFFFFF; color: #000000; font-family: Verdana, Geneva, sans-serif; font-size: 13px; width: 950px; padding:0px; text-align:justify; margin: 0px; } --> Access has been denied. URL: " set static::after_url " Your request was denied because it is blacklisted in DNS. Blacklist category: " set static::after_block_reason " The Internet Gateways are for official use only. Misuse violates policy. If you believe that this site is categorized incorrectly, and that you have a valid business reason for access to this site please contact your manager for approval and the Enterprise Network Operations Center via E-mail: [email protected] Please use the Web Access Request Form and include a business justification. Only e-mail that originates from valid internal e-mail addresses will be processed. If you do not have a valid e-mail address, your manager will need to submit a request on your behalf. Generated by bigip1.f5.com. " }GTM Translation
Problem this snippet solves: When GTM responds with the IP address of the virtual server, there are different NAT translations that must be performed depending on where the request is coming from. This iRule looks at 4 classes (DataGroups) to determine which (If any) of the NAT translations it must perform on the response. This iRule differs from the pinhole example by only examining the response and the 'client' IP address. The hostname requested is ignored so there is only 1 event that needs to fire. Note that although developed for GTM, this is an LTM iRule and is attached to the LTM VS that is created by the GTM when you configure a listener address How to use this snippet: These data-groups are required but MAY be empty if no translations are necessary. local_address_class (type: address) - Holds a list of networks and their type (string internal or 3dp) gte_translate_3dp (type: address) - Translations for 3dp networks gte_translate_internet (type: address) - Translations for the internet gte_translate_internal (type: address) - Translations for internal addresses Code : timing on # gte_translate_external # # Hamish Marson ([email protected]) 2011 # # When GTM responds with the IP address of the virtual server, there are different NAT translations that # must be performed depending on where the request is coming from. This iRule looks at 4 classes (DataGroups) # to determine which (If any) of the NAT translations it must perform on the response. # # CLASS Type Description # local_address_class Address - Holds a list of networks and their type. Type is a string internal or 3dp # gte_translate_3dp Address - Translations for 3dp networks # gte_translate_internet Address - Translations for The Internet # gte_translate_internal Address - Translations for Internal addresses # # The translation dataGroups MUST exist. But MAY be empty if no translations are requirted (e.g. For Internal) # # Extensions... Current.y hardcoded for 3 types of address (internal, 3dp or (default) internet. This could be # extended by building the translation class name from the value returned from local_address_class. However extra # error checking would also be required to take into account mis-configuration of the local_address_class dataGroup # to make non-existant dataGroup names. # when DNS_RESPONSE { set GTE_CLASS_INTERNET "gte_translate_internet" set GTE_CLASS_INTERNAL "gte_translate_internal" set GTE_CLASS_3DP "gte_translate_3dp" set LOCAL_CLASS_ADDRESS "local_address_class" set gteHSL [HSL::open -proto UDP -pool hsl-log-01] set gteLogPrefix "<190>[virtual]:gte_translate_external:[IP::client_addr]:0:" # Grab the answer from GTM set rrs [DNS::answer] #HSL::send $gteHSL "$gteLogPrefix: checking DNS::answers" foreach rr $rrs { #HSL::send $gteHSL "$gteLogPrefix: checking RR type ==> [DNS::type $rr]" # Lookup the IP address returned in the GTE_CLASS if { [DNS::type $rr] == "A" } { set dstip [DNS::rdata $rr] #HSL::send $gteHSL "$gteLogPrefix: checking A data ==> [DNS::rdata $rr] ($dstip)" set gteAddClass [class match -value [IP::client_addr] equals $LOCAL_CLASS_ADDRESS ] switch -exact $gteAddClass { internal { set transIP [class match -value $dstip equals $GTE_CLASS_INTERNAL] } 3dp { set transIP [class match -value $dstip equals $GTE_CLASS_3DP] } default { set transIP [class match -value $dstip equals $GTE_CLASS_INTERNET] } } if { $transIP ne "" } { HSL::send $gteHSL "$gteLogPrefix: translate ($gteAddClass) $dstip => $transIP" DNS::rdata $rr $transIP return } else { HSL::send $gteHSL "$gteLogPrefix: no match for ($gteAddClass) $dstip" return } } } }
