Saltar a contenido

DNS

El Domain Name System (DNS) es una parte integral de Internet. Por ejemplo, a través de nombres de dominio, como academy.hackthebox.com o www.hackthebox.com, podemos acceder a los servidores web a los que el proveedor de hosting ha asignado una o más direcciones IP específicas. El DNS es un sistema para resolver nombres de computadoras en direcciones IP, y no tiene una base de datos central. Simplificado, podemos imaginarlo como una biblioteca con muchos directorios telefónicos diferentes. La información está distribuida en muchos miles de servidores de nombres. Los servidores DNS distribuidos globalmente traducen los nombres de dominio en direcciones IP y, por lo tanto, controlan a qué servidor puede llegar un usuario a través de un dominio en particular. Hay varios tipos de servidores DNS que se utilizan en todo el mundo:

  • DNS root server
  • Authoritative name server
  • Non-authoritative name server
  • Caching server
  • Forwarding server
  • Resolver
Tipo de Servidor Descripción
DNS Root Server Los servidores raíz del DNS son responsables de los dominios de nivel superior (TLD). Como última instancia, solo se solicitan si el servidor de nombres no responde. Así, un servidor raíz es una interfaz central entre los usuarios y el contenido en Internet, ya que vincula el dominio y la dirección IP. La Internet Corporation for Assigned Names and Numbers (ICANN) coordina el trabajo de los servidores de nombres raíz. Hay 13 de estos servidores raíz en todo el mundo.
Authoritative Nameserver Los servidores de nombres autoritativos tienen autoridad sobre una zona particular. Solo responden consultas de su área de responsabilidad, y su información es vinculante. Si un servidor de nombres autoritativo no puede responder a la consulta de un cliente, el servidor de nombres raíz se hace cargo en ese momento.
Non-authoritative Nameserver Los servidores de nombres no autoritativos no son responsables de una zona DNS en particular. En su lugar, recopilan información sobre zonas DNS específicas, lo que se hace mediante consultas DNS recursivas o iterativas.
Caching DNS Server Los servidores DNS de caché almacenan información de otros servidores de nombres durante un período de tiempo especificado. El servidor de nombres autoritativo determina la duración de este almacenamiento.
Forwarding Server Los servidores de reenvío solo realizan una función: reenvían consultas DNS a otro servidor DNS.
Resolver Los resolvers no son servidores DNS autoritativos, sino que realizan la resolución de nombres localmente en la computadora o el router.

El DNS está principalmente sin cifrar. Por lo tanto, los dispositivos en la red local y los proveedores de Internet pueden interceptar y espiar las consultas DNS. Dado que esto representa un riesgo para la privacidad, ahora existen algunas soluciones para el cifrado de DNS. Por defecto, los profesionales de la seguridad informática aplican DNS over TLS (DoT) o DNS over HTTPS (DoH). Además, el protocolo de red DNSCrypt también cifra el tráfico entre la computadora y el servidor de nombres.

Sin embargo, el DNS no solo vincula nombres de computadoras y direcciones IP. También almacena y proporciona información adicional sobre los servicios asociados con un dominio. Por lo tanto, una consulta DNS también se puede utilizar, por ejemplo, para determinar qué computadora sirve como servidor de correo electrónico para el dominio en cuestión o cómo se llaman los servidores de nombres del dominio.

Diferentes DNS records se utilizan para las consultas DNS, cada uno con varias tareas. Además, existen entradas separadas para diferentes funciones, ya que podemos configurar servidores de correo y otros servidores para un dominio.

DNS Record Descripción
A Devuelve una dirección IPv4 del dominio solicitado como resultado.
AAAA Devuelve una dirección IPv6 del dominio solicitado.
MX Devuelve los servidores de correo responsables como resultado.
NS Devuelve los servidores DNS (nameservers) del dominio.
TXT Este registro puede contener varias informaciones. El todoterreno se puede utilizar, por ejemplo, para validar la Google Search Console o validar certificados SSL. Además, se configuran entradas SPF y DMARC para validar el tráfico de correo y protegerlo del spam.
CNAME Este registro sirve como un alias. Si el dominio www.hackthebox.eu debe apuntar a la misma IP, creamos un registro A para uno y un registro CNAME para el otro.
PTR El registro PTR funciona a la inversa (búsqueda inversa). Convierte direcciones IP en nombres de dominio válidos.
SOA Proporciona información sobre la zona DNS correspondiente y la dirección de correo electrónico del contacto administrativo.

El registro SOA se encuentra en el archivo de zona de un dominio y especifica quién es responsable del funcionamiento del dominio y cómo se gestiona la información DNS para el dominio.

dig soa www.inlanefreight.com

; <<>> DiG 9.16.27-Debian <<>> soa www.inlanefreight.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15876
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.inlanefreight.com.         IN      SOA

;; AUTHORITY SECTION:
inlanefreight.com.      900     IN      SOA     ns-161.awsdns-20.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 05 12:56:10 GMT 2023
;; MSG SIZE  rcvd: 128

El punto (.) se reemplaza por un signo de arroba (@) en la dirección de correo electrónico. En este ejemplo, la dirección de correo electrónico del administrador es awsdns-hostmaster@amazon.com.

Default Configuration

Existen muchos tipos diferentes de configuraciones para DNS. Por lo tanto, solo discutiremos las más importantes para ilustrar mejor el principio funcional desde un punto de vista administrativo. Todos los servidores DNS funcionan con tres tipos diferentes de archivos de configuración:

  1. local DNS configuration files
  2. zone files
  3. reverse name resolution files

El servidor DNS Bind9 se utiliza muy a menudo en distribuciones basadas en Linux. Su archivo de configuración local (named.conf) se divide en dos secciones: en primer lugar, la sección de opciones para configuraciones generales y, en segundo lugar, las entradas de zona para los dominios individuales. Los archivos de configuración local suelen ser:

  • named.conf.local
  • named.conf.options
  • named.conf.log

Contiene el RFC asociado donde podemos personalizar el servidor según nuestras necesidades y nuestra estructura de dominio con las zonas individuales para diferentes dominios. El archivo de configuración named.conf se divide en varias opciones que controlan el comportamiento del servidor de nombres. Se distingue entre opciones globales y opciones de zona.

Las opciones globales son generales y afectan a todas las zonas. Una opción de zona solo afecta a la zona a la que se asigna. Las opciones que no están enumeradas en named.conf tienen valores predeterminados. Si una opción es tanto global como específica de la zona, entonces la opción de la zona tiene prioridad.

Local DNS Configuration

root@bind9:~# cat /etc/bind/named.conf.local

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "domain.com" {
    type master;
    file "/etc/bind/db.domain.com";
    allow-update { key rndc-key; };
};

En este archivo, podemos definir las diferentes zonas. Estas zonas se dividen en archivos individuales, que en la mayoría de los casos están destinados principalmente a un solo dominio. Las excepciones son los ISP y los servidores DNS públicos. Además, muchas opciones diferentes amplían o reducen la funcionalidad. Podemos consultar estas opciones en la documentación de Bind9.

Un archivo de zona es un archivo de texto que describe una zona DNS con el formato de archivo BIND. En otras palabras, es un punto de delegación en el árbol DNS. El formato de archivo BIND es el formato de archivo de zona preferido por la industria y ahora está bien establecido en el software de servidores DNS. Un archivo de zona describe una zona completamente. Debe haber precisamente un SOA registro y al menos un NS registro. El registro de recursos SOA generalmente se encuentra al comienzo de un archivo de zona. El objetivo principal de estas reglas globales es mejorar la legibilidad de los

archivos de zona. Un error de sintaxis generalmente resulta en que todo el archivo de zona se considere inutilizable. El servidor de nombres se comporta de manera similar a si esta zona no existiera. Responde a las consultas DNS con un mensaje de error SERVFAIL.

En resumen, aquí se ingresan todos los registros directos según el formato BIND. Esto permite que el servidor DNS identifique a qué dominio, nombre de host y función pertenecen las direcciones IP. En términos simples, este es el directorio telefónico donde el servidor DNS busca las direcciones de los dominios que está buscando.

Zone Files

root@bind9:~# cat /etc/bind/db.domain.com

;
; BIND reverse data file for local loopback interface
;
$ORIGIN domain.com
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     ns1.domain.com.
      IN     NS     ns2.domain.com.

      IN     MX     10     mx.domain.com.
      IN     MX     20     mx2.domain.com.

             IN     A       10.129.14.5

server1      IN     A       10.129.14.5
server2      IN     A       10.129.14.7
ns1          IN     A       10.129.14.2
ns2          IN     A       10.129.14.3

ftp          IN     CNAME   server1
mx           IN     CNAME   server1
mx2          IN     CNAME   server2
www          IN     CNAME   server2

Para que la dirección IP se resuelva a partir del Fully Qualified Domain Name (FQDN), el servidor DNS debe tener un archivo de búsqueda inversa. En este archivo, el nombre de la computadora (FQDN) se asigna al último octeto de una dirección IP, que corresponde al host respectivo, utilizando un registro PTR. Los registros PTR son responsables de la traducción inversa de direcciones IP en nombres, como ya hemos visto en la tabla anterior.

Reverse Name Resolution Zone Files

root@bind9:~# cat /etc/bind/db.10.129.14

;
; BIND reverse data file for local loopback interface
;
$ORIGIN 14.129.10.in-addr.arpa
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     ns1.domain.com.
      IN     NS     ns2.domain.com.

5    IN     PTR    server1.domain.com.
7    IN     MX     mx.domain.com.
...SNIP...

Dangerous Settings

Hay muchas formas en las que un servidor DNS puede ser atacado. Por ejemplo, se puede encontrar una lista de vulnerabilidades dirigidas al servidor BIND9 en CVEdetails. Además, SecurityTrails proporciona una breve lista de los ataques más populares a los servidores DNS.

Algunas de las configuraciones que podemos ver a continuación conducen a estas vulnerabilidades, entre otras. Debido a que DNS puede volverse muy complicado y es muy fácil que se produzcan errores en este servicio, obligando a un administrador a trabajar alrededor del problema hasta encontrar una solución exacta. Esto a menudo conduce a la liberación de elementos para que partes de la infraestructura funcionen como se planeó y deseaba. En tales casos, la funcionalidad tiene una prioridad más alta que la seguridad, lo que lleva a configuraciones incorrectas y vulnerabilidades.

Opción Descripción
allow-query Define qué hosts están permitidos para enviar solicitudes al servidor DNS.
allow-recursion Define qué hosts están permitidos para enviar solicitudes recursivas al servidor DNS.
allow-transfer Define qué hosts están permitidos para recibir transferencias de zona desde el servidor DNS.
zone-statistics Recopila datos estadísticos de las zonas.

Footprinting the Service

El reconocimiento en servidores DNS se realiza como resultado de las solicitudes que enviamos. Entonces, en primer lugar, el servidor DNS puede ser consultado sobre qué otros servidores de nombres son conocidos. Hacemos esto utilizando el registro NS y la especificación del servidor DNS que queremos consultar utilizando el carácter @. Esto se debe a que si hay otros servidores DNS, también podemos usarlos y consultar los registros. Sin embargo, otros servidores DNS pueden estar configurados de manera diferente y, además, pueden ser permanentes para otras zonas.

DIG - NS Query

dig ns inlanefreight.htb @10.129.14.128

; <<>> DiG 9.16.1-Ubuntu <<>> ns inlanefreight.htb @10.129.14.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45010
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce4d8681b32abaea0100000061475f73842c401c391690c7 (good)
;; QUESTION SECTION:
;inlanefreight.htb.             IN      NS

;; ANSWER SECTION:
inlanefreight.htb.      604800  IN      NS      ns.inlanefreight.htb.

;; ADDITIONAL SECTION:
ns.inlanefreight.htb.   604800  IN      A       10.129.34.136

;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:04:03 CEST 2021
;; MSG SIZE  rcvd: 107

A veces también es posible consultar la versión de un servidor DNS utilizando una consulta de clase CHAOS y tipo TXT. Sin embargo, esta entrada debe existir en el servidor DNS. Para esto, podríamos usar el siguiente comando:

DIG - Version Query

dig CH TXT version.bind 10.129.120.85

; <<>> DiG 9.10.6 <<>> CH TXT version.bind
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47786
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
version.bind.       0       CH      TXT     "9.10.6-P1"

;; ADDITIONAL SECTION:
version.bind.       0       CH      TXT     "9.10.6-P1-Debian"

;; Query time: 2 msec
;; SERVER: 10.129.120.85#53(10.129.120.85)
;; WHEN: Wed Jan 05 20:23:14 UTC 2023
;; MSG SIZE  rcvd: 101

Podemos usar la opción ANY para ver todos los registros disponibles. Esto hará que el servidor nos muestre todas las entradas disponibles que esté dispuesto a divulgar. Es importante tener en cuenta que no se mostrarán todas las entradas de las zonas.

DIG - ANY Query

dig any inlanefreight.htb @10.129.14.128

; <<>> DiG 9.16.1-Ubuntu <<>> any inlanefreight.htb @10.129.14.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7649
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 064b7e1f091b95120100000061476865a6026d01f87d10ca (good)
;; QUESTION SECTION:
;inlanefreight.htb.             IN      ANY

;; ANSWER SECTION:
inlanefreight.htb.      604800  IN      TXT     "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129

.127.2 ip4:10.129.42.106 ~all"
inlanefreight.htb.      604800  IN      TXT     "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
inlanefreight.htb.      604800  IN      TXT     "MS=ms97310371"
inlanefreight.htb.      604800  IN      SOA     inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb.      604800  IN      NS      ns.inlanefreight.htb.

;; ADDITIONAL SECTION:
ns.inlanefreight.htb.   604800  IN      A       10.129.34.136

;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:42:13 CEST 2021
;; MSG SIZE  rcvd: 437

Zone transfer se refiere a la transferencia de zonas a otro servidor en DNS, lo que generalmente ocurre sobre el puerto TCP 53. Este procedimiento se abrevia Asynchronous Full Transfer Zone (AXFR). Dado que una falla de DNS generalmente tiene consecuencias graves para una empresa, el archivo de zona casi siempre se mantiene idéntico en varios servidores de nombres. Cuando se realizan cambios, se debe asegurar que todos los servidores tengan los mismos datos. La sincronización entre los servidores involucrados se realiza mediante la transferencia de zonas. Utilizando una clave secreta rndc-key, que hemos visto inicialmente en la configuración predeterminada, los servidores aseguran que se comuniquen con su propio maestro o esclavo. La transferencia de zona implica la mera transferencia de archivos o registros y la detección de discrepancias en los conjuntos de datos de los servidores involucrados.

Los datos originales de una zona se encuentran en un servidor DNS, que se llama servidor de nombres primario para esta zona. Sin embargo, para aumentar la confiabilidad, realizar una distribución simple de carga o proteger al primario de ataques, en la práctica se instalan uno o más servidores adicionales en casi todos los casos, que se llaman servidores de nombres secundarios para esta zona. Para algunos Top-Level Domains (TLDs), hacer que los archivos de zona para los Second Level Domains estén accesibles en al menos dos servidores es obligatorio.

Las entradas DNS generalmente solo se crean, modifican o eliminan en el primario. Esto se puede hacer editando manualmente el archivo de zona relevante o automáticamente mediante una actualización dinámica desde una base de datos. Un servidor DNS que sirve como fuente directa para la sincronización de un archivo de zona se llama maestro. Un servidor DNS que obtiene datos de zona de un maestro se llama esclavo. Un primario siempre es un maestro, mientras que un secundario puede ser tanto esclavo como maestro.

El esclavo obtiene el registro SOA de la zona relevante del maestro a intervalos determinados, el llamado tiempo de actualización, generalmente una hora, y compara los números de serie. Si el número de serie del registro SOA del maestro es mayor que el del esclavo, los conjuntos de datos ya no coinciden.

DIG - AXFR Zone Transfer

dig axfr inlanefreight.htb @10.129.14.128

; <<>> DiG 9.16.1-Ubuntu <<>> axfr inlanefreight.htb @10.129.14.128
;; global options: +cmd
inlanefreight.htb.      604800  IN      SOA     inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb.      604800  IN      TXT     "MS=ms97310371"
inlanefreight.htb.      604800  IN      TXT     "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
inlanefreight.htb.      604800  IN      TXT     "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all"
inlanefreight.htb.      604800  IN      NS      ns.inlanefreight.htb.
app.inlanefreight.htb.  604800  IN      A       10.129.18.15
internal.inlanefreight.htb. 604800 IN   A       10.129.1.6
mail1.inlanefreight.htb. 604800 IN      A       10.129.18.201
ns.inlanefreight.htb.   604800  IN      A       10.129.34.136
inlanefreight.htb.      604800  IN      SOA     inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
;; Query time: 4 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:51:19 CEST 2021
;; XFR size: 9 records (messages 1, bytes 520)

Si el administrador usó una subred para la opción allow-transfer con fines de prueba o como solución temporal o la configuró en any, cualquiera podría consultar todo el archivo de zona en el servidor DNS. Además, se pueden consultar otras zonas, que incluso pueden mostrar direcciones IP internas y nombres de host.

DIG - AXFR Zone Transfer - Internal

dig axfr internal.inlanefreight.htb @10.129.14.128

; <<>> DiG 9.16.1-Ubuntu <<>> axfr internal.inlanefreight.htb @10.129.14.128
;; global options: +cmd
internal.inlanefreight.htb. 604800 IN   SOA     inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
internal.inlanefreight.htb. 604800 IN   TXT     "MS=ms97310371"
internal.inlanefreight.htb. 604800 IN   TXT     "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
internal.inlanefreight.htb. 604800 IN   TXT     "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all"
internal.inlanefreight.htb. 604800 IN   NS      ns.inlanefreight.htb.
dc1.internal.inlanefreight.htb. 604800 IN A     10.129.34.16
dc2.internal.inlanefreight.htb. 604800 IN A     10.129.34.11
mail1.internal.inlanefreight.htb. 604800 IN A   10.129.18.200
ns.internal.inlanefreight.htb. 604800 IN A      10.129.34.136
vpn.internal.inlanefreight.htb. 604800 IN A     10.129.1.6
ws1.internal.inlanefreight.htb. 604800 IN A     10.129.1.34
ws2.internal.inlanefreight.htb. 604800 IN A     10.129.1.35
wsus.internal.inlanefreight.htb. 604800 IN A    10.129.18.2
internal.inlanefreight.htb. 604800 IN   SOA     inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128)
;; WHEN: So Sep 19 18:53:11 CEST 2021
;; XFR size: 15 records (messages 1, bytes 664)

Los registros A individuales con los nombres de host también se pueden descubrir mediante un ataque de fuerza bruta. Para hacer esto, necesitamos una lista de posibles nombres de host, que usamos para enviar las solicitudes en orden. Dichas listas son proporcionadas, por ejemplo, por SecLists.

Una opción sería ejecutar un for-loop en Bash que liste estas entradas y envíe la consulta correspondiente al servidor DNS deseado.

Subdomain Brute Forcing

for sub in $(cat /opt/useful/SecLists/Discovery/DNS/subdomains-top1million-110000.txt);do dig $sub.inlanefreight.htb @10.129.14.128 | grep -v ';\|SOA' | sed -r '/^\s*$/d' | grep $sub | tee -a subdomains.txt;done

ns.inlanefreight.htb.   604800  IN      A       10.129.34.136
mail1.inlanefreight.htb. 604800 IN      A       10.129.18.201
app.inlanefreight.htb.  604800  IN      A       10.129.18.15

Muchos diferentes herramientas pueden ser utilizadas para esto, y la mayoría de ellas funcionan de la misma manera. Una de estas herramientas es, por ejemplo, DNSenum.

dnsenum --dnsserver 10.129.14.128 --enum -p 0 -s 0 -o subdomains.txt -f /opt/useful/SecLists/Discovery/DNS/subdomains-top1million-110000.txt inlanefreight.htb

dnsenum VERSION:1.2.6

-----   inlanefreight.htb   -----


Host's addresses:
__________________



Name Servers:
______________

ns.inlanefreight.htb.                    604800   IN    A        10.129.34.136


Mail (MX) Servers:
___________________



Trying Zone Transfers and getting Bind Versions:
_________________________________________________

unresolvable name: ns.inlanefreight.htb at /usr/bin/dnsenum line 900 thread 1.

Trying Zone Transfer for inlanefreight.htb on ns.inlanefreight.htb ...
AXFR record query failed: no nameservers


Brute forcing with /home/cry0l1t3/Pentesting/SecLists/Discovery/DNS/subdomains-top1million-110000.txt:
_______________________________________________________________________________________________________

ns.inlanefreight.htb.                    604800   IN    A        10.129.34.136
mail1.inlanefreight.htb.                 604800   IN    A        10.129.18.201
app.inlanefreight.htb.                   604800   IN    A        10.129.18.15
ns.inlanefreight.htb.                    604800   IN    A        10.129.34.136

...SNIP...
done.