Re: draft-ietf-dnsop-ipv6-dns-issues-04.txt [Re: [dnsop] WG Last Call: draft-ietf-dnsop-misbehavior-against-aaaa-00.txt]

[Pekka Savola <[e-mail]>]

On Fri, 26 Mar 2004, J-F C. (Jefsey)  Morfin wrote:
> Oh! I try to get the text more specific!
> 
> What I mean is that if you introduce a new concept in the DNS
> affecting the availability/existance of the RRs you should make
> ita very precise feature. From what I gather the TTO would be the
> delay before non called entry should be discarded. I think the
> concept is great as it may really help managers tracing their
> own mismanagement.
>
> 1. I do not know where it is to be introduced because I do not
>      see easily how it may survive a reload (we are talking of the
>      master file management). This means an associated base
>      keeping the date of the last use and called at loading time.
> 
> 2. this would pemit a feature I want for a long in the DNS, which
>      is temporary names for security/ebusiness purposes. If I set
>      a TTO of 15 minutes and a TTL of 5 minutes on a Dynamic
>      entry : the name will be valid for 20 minutes maximum on the
>      network.


I think there has been a misunderstanding about the context where such 
a janitorial process would operate.  I was not proposing changes to 
DNS records, but rather how the zones are operated.

For the cases where the names would be statically assigned, they 
cannot be expired out without being checked for validity.  So, unless 
we assume that the nodes using DDNS would be updating the record just 
in case even though it is up-to-date (to signal that, yes, "I'm still 
here"), the process has to operate in a different context.

That is, for example, you could be running an arpwatch -like daemon in
your network, and storing the IP addresses used.  Or you could do 
syslogging from your border router based on IP addresses.  Or 
something else.  After you've collected a lot of data like this, you 
would run some process which would find the old information from the 
pile, and remove their records from the DNS files.

Yes, this is complicated, but ideas for something better are welcome.

And if we figure out something better (e.g., recommend that DDNS is 
run regularly), all the better -- but that probably doesn't need to go 
into this document, especially if it takes a lot of time to "get 
right".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html