• Not very difficult to add support
• Only need to provide ability to give forward and reverse lookup support for IPv6 addresses
• However, we cannot use the existing IPv4 record "A" and "in-addr.arpa" method because we need to continue to support old IPv4 applications without confusing them.
• Attempting to cram full IPv6 addresses into IPv4 data records will likely fail and break a lot of existing code

• Add a new Resource Record, designated "AAAA" to allow association of an IPV6 address with a hostname.
• This has the benefit of allowing an IPv4 "A" record and an IPv6 "AAAA" record to coexist, allowing a host to be addressible in both address forms, if needed. IPv6-compliant applications will know to retrieve the IPv6 address if it is available, while old applications will still only see the old IPv4 address.
• An example record might be listed:

  turing    IN     A       134.173.42.99
            IN     AAAA    4321:0:1:2:3:4:567:89ab
            IN     HINFO   Ultra Enterprise 3000 Solaris
  

• For reverse lookups, just create a new "fake domain" for the IPv6 addresses to be listed. As with IPv4, the IP address will be broken into chunks and listed in reverse order so that the natural domain heirachy will match the heirachy of subnets. For example, the inverse lookup domain name corresponding to the address 4321:0:1:2:3:4:567:89ab would be listed under the address b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT
• The result is something that is very clean. The DNS server source had to be modified to support only one new RR type. IPv6 compliant applications simply need to be linked with a DNS socket library that knows to try for AAAA records first and then A records. Both of these issues are minor since servers/applications would have to be upgraded to support IPv6 anyways.

• If you periodically make changes to your DNS, but need to reduce propagation delays, you were typically required to either manually go around and HUP all or your name servers on a change, or have a really short TTL.
• Going around and HUP'ing all of your secondaries is time consuming and a pain, especially if you don't have access to all of them.
• Having a low TTL causes a lot of wasteful network polling by your secondaries and all other external servers that have done any lookups from you.

• A new "UPDATE" opcode was created and can be sent from the master to secondaries when a new zone file update is available. The UPDATE message can contain the zone, and an indicator of a possible subset in which an the change has occurred within
• Additionally, a prerequisite can be included in the UPDATE to allow the secondary to quickly verify whether it needs to go fetch a update or not without even making a communication back to the master.
• Implementations are recommended to perform authentication since a denial of service attack could potentially be done.
• UPDATE's should not be sent or acted upon beyond secondaries since this could potentially trigger a large number of DNS lookups to occur.
• This doesn't eliminate the need for updating serial numbers or designation of reasonable values for TTL, since servers and clients beyond the secondaries will not be able to expect UPDATE's to be sent.

• Defined search order for LOC records is to first query records for the host, and then if that fails on the IN-ADDR subnet that the ip address is in.
• This allows a rough geographic location to be specified for entire subnets and optionally privide more accurate coordinates for individual machines
• An example of this usage would be an entire computer lab with all machines located relatively closely, with a central file server in the same subnet but is physically detached from the lab.

• Example records:

  ;; network LOC RR derived from ZIP data.
  ;;  note use of precision defaults
  cambridge-net.kei.com.  LOC   42 21 54 N \
              71 06 18 W -24m 30m
  
  ;; higher-precision host LOC RR.  note 
  ;; use of vertical precision default
  loiosh.kei.com.         LOC   42 21 43.952 N \
            71 5 6.344 W   -24m 1m 200m
  

• Nifty demonstration

• We would like to be able to verify that DNS information is coming from the server it claims to be, and also that the data has not been tampered with or corrupted in transit. (aka: Data Origin Authentication and Integrity)
• Private and public keys used for verification (MD5/RSA)
• Public keys for DNS authentication can be put in a DNS record itself, and can be public keys can be signed by a higher authority for even more security.
• DNS administrators will sign their DNS zone files using their private key so that anyone with their public key can verify it.
• Keys and signatures have lifetimes, similar to TTL. The shorter of the TTL and the remaining lifetime are used for the caching of secured DNS records.

snore.foo.bar.  259200  A       10.17.3.20
snore.foo.bar.  259200  SIG     A (
                 1 3; alg labels
        259200  ; TTL
        19950506200636  ; Signature expiration
        19950406200659  ; time signed 
        47437   ; Key foot print
        foo.bar.        ; Signers name  
                FsqeW3hstM8Q6v8PMCGPsVMfO6dEpHjFgKm
2dJRaofFtCQ/CT9O6Vo7J5zgkV+5ciWQwuZwvzW071jnZ1i27
Ip/8vqdKGHC63tjWkCHSZV0=
        ) ; END Signature


foo.nil.    NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
foo.nil.    SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
            19970102030405 ;signature expiration
            19961211100908 ;time signed
            2143           ;key identifier
            foo.nil.       ;signer
AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhp
fHFElxbvKoWmvjDTCmfiYy2X+8XpFjwICHc398kzWsTMKlxov
pz2FnCTM= ;signature (640 bits)
                             )