primeras cuestiones

1)
los canonical name de webmail.edu.ar son es agatha.unr.edu.ar su ip es 200.3.120.65

2)
;;	Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr 29 16:16:47 2015
;; MSG SIZE  rcvd: 73

3)
8.8.8.8, este servidor es el dns publico de google

4)


5)

los servidores que contestaron la respuesta de dns fueron:

8.8.8.8			google-public-dns-a.google.com.
198.41.0.4		a.root-servers.net.
193.0.9.59		ar.cctld.authdns.ripe.net.
157.92.4.1		ns2.uba.ar.
200.3.120.77	valeria.unr.edu.ar.

Se puede constatar adicionalmente esta informacion utilizando dig -x direccion_ip la cual como respuesta te da el nombre del servidor.

6) A partir de dig +trace nombre_del_servidor podemos ademas avergiduar todos los tipos de consultas en todos los tipos

WIRESHARK
1) El protocolo utilizado por los mensajes del servidor de dns es UDP
2)
Source port: cst-port (3742)
Destination port: domain (53)
3)
la consulta es enviada a 128.238.29.22, que es la misma del servidor DNS por default
4)
	a)1
	b)El tipo de consulta es 0x0003 DNS_TYPE_MD
	c)No tiene answerd porque es una consulta

5)
Answers:
www.mit.edu: type A, class IN, addr 18.7.22.83

Authority:
mit.edu: type NS, class IN, ns BITSY.mit.edu
mit.edu: type NS, class IN, ns STRAWB.mit.edu
mit.edu: type NS, class IN, ns W20NS.mit.edu

Additional information:
BITSY.mit.edu: type A, class IN, addr 18.72.0.3
STRAWB.mit.edu: type A, class IN, addr 18.71.0.151
W20NS.mit.edu: type A, class IN, addr 18.70.0.160
6)
La consulta es envidad al ip 128.238.29.22, que es la misma del servidor DNS por default
7)
	a)1
	b)El tipo de consulta es 0x0003 DNS_TYPE_MD
	c)No tiene answerd porque es una consulta
8)
Answers:
mit.edu: type NS, class IN, ns bitsy.mit.edu
mit.edu: type NS, class IN, ns strawb.mit.edu
mit.edu: type NS, class IN, ns w20ns.mit.edu

Additional information:
bitsy.mit.edu: type A, class IN, addr 18.72.0.3
strawb.mit.edu: type A, class IN, addr 18.71.0.151
w20ns.mit.edu: type A, class IN, addr 18.70.0.160

DJBDNS
1) la importancia de separar el servicio de tinydns y de dnscache radica en su funcionamento, el cual tinydns se encargar de proveer un servicio de dns en el equipo mientras que dnscache se utiliza para no tener que resolver el domain name realizando una consulta. Por lo tanto no importa mucho si se utilizan junto ya que no se interfieren.
podemos usar la interface loopback porque el tinydns se encuentra en nuestro equipo y por lo tanto la peticion de la direccion de esa ip puede ser valida, mientras que si estuviese en otro equipo no se podria porque la peticion de ip no sera valida.
2)
home constituye el top-level-domain dentro de la configuracion realizada, es decir dentro de la estructura de resolucion de nombres dns este es el de mayor importancia.
3)
./add-ns home 127.0.0.28
./add-ns 5.168.192.in-addr.arpa 127.0.0.28
./add-ns net.home 127.0.0.28
./add-ns hosts.home 127.0.0.28
./add-host little.hosts.home 192.168.2.36
./add-host mipc.hosts.home 192.168.2.35
./add-alias pop3.net.home 192.168.2.35
./add-alias web.net.home 192.168.2.35
./add-alias smtp.net.home 192.168.2.35
./add-host router.hosts.home <mi ip>


4)
home ahora es el tld
no porque antes net.home era el tld y ahora home lo es.
mipc esta conigurado como una terminal del subdominio hosts.
no.
router es una terminal mas del subdominion hosts.
la reversa de little existe.
no.
no se.
5)