Dynamic Updation of DNS with temporary addresses (RFC-3041 case)

Publication Summary

Disclosed is the scheme for registration of temporary addresses (TA) with DNS using dynimic update method. TA's are introduced in RFC 3041. This invention tries to address conflicts posed due to ACL list and TA being used as source address on dns update packet

Country
Language	English (United States)

---

Continue to Text Preview →

Page 1 of 4

Dynamic Updation of DNS with temporary addresses (RFC-3041 case)

References:
1. RFC 3041: Privacy Extensions for Stateless Address Auto configuration in IPv6:
2. RFC 3484 - Default Address Selection for Internet Protocol version 6 (IPv6)

Let's see the present implementation of dynamic update and associated usage of ACL (Access Control Lists)

Dynamic update: This permits the simple addition and deletion of records by using command similar to nsupdate in AIX.

Update Access Control Lists

The addresses matching with the ACL list are the only addresses allowed to update the zone. It's

prudent to make this access control list as restrictive as possible:

zone "in.ibm.com" {

type master;

file "db.in.ibm.com";

allow-update { 192.253.253.100; 192.253.253.17;}; };

Problem in current implementation:

Pre-condition:
A) Assume that DNS name server has ACL allowing host-A to do updates using its global IP address as below -
zone "in.ibm.com" {

type master;

file "db.in.ibm.com";

allow-update { gIP;}; // gIP - host-A's global IP address };

B) Refer RFC 3041 for rules governing temporary address generation and meaning of preferred life (

plife) and deprecated life (dlife).

1. Interface has global address gIP with DNS entry as below. This is a public well known address
g-domain-name IN A gIP

2. The ndpd-host daemon program would generate temporary address tIP1 (

Now this needs to be registered with DNS as per RFC 3041.

T1-domain-name IN A tIP1
3. The ndpd-host daemon program would generate temporary address tIP2 (

preferred lifetime of tIP1 is elapsed. At this time, we need to remove tIP1 entry from

DNS and add tIP2 to DNS.

T1-domain-name IN A tIP1 // Delete this from dns database

p

life, dlife)

according to RFC 3041.

p

life, dlife) after

1

Page 2 of 4

T2-domain-name IN A tIP2 // Add this to dns database
4. Steps 2, 3 above will continue forever.

C) Once the RFC 3041 is implemented, interface is configured to use RFC 3041 generated temporary addresses over the global (synonymously called public) addresses. (See RFC 3484 for source address selection rules)

D)

packets going from interface on host-A would use

address (and not the global address gIP registered in ACL of DNS database)

This will result in dns server rejecting the nsupdate coming from host-

the IP in ACL. This is a the problem.

The work around is to have nsupdate application using the global address as source address (calling bind() to bind specifically to global address overriding the source address selection rule (rfc 3484). But this opens hole that rfc3041 tries to fill in - eavesdropper being able to track nodes with global address derived from IEEE interface identifier. (section 2.3 of rfc3041)

So in nutshell, to honor the rfc3041 in full spirit, there must have mechanism so that nsupdate works with using temporary addresses as source address and succeeds in add/delete of updates with dns server.

The Idea:

According to the RFC 3041, whenever there...

Download This Document →

Back to Overview