[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RAM] DNS usage in NERD



On 2007-06-18 15:30, Robin Whittle wrote:

Brian wrote:

> Indeed, but how can you impose a constraint that DNS zone transfers
> etc do not in any way depend on NERD/LISP? That is where I am
> puzzled.

Wouldn't it be good enough that LISP/Ivip or whatever states in its architectural RFC that addresses which depend on this mapping scheme should not be used for certain purposes, including?:

1 - BGP routers, including ITRs and ETRs - obviously.

2 - Root and TLD nameservers.  Probably many second level
    nameservers such as .com.au. too.  Probably including
    any nameserver which does something under in-addr.arpa
    on which anyone else's but the operator's addresses
    depend upon for reverse mapping.

3 - Any nameserver on which the mapping scheme depends.

4 - Whatever central database servers control the mapping
    system, including interfaces for user control of mapping
    of their IP addresses, servers for all push and pull update
    activities and any independent systems which monitor
    where a mobile host is connecting, and automatically
    initiate changes to the mapping database if the mobile
    host's current link fails.

Then all the critical nameservers have ordinary BGP-accessible
addresses, so their zone transfers go via ordinary BGP,
irrespective of what the mapping system does.

I think I would prefer Eliot to comment on getting the circularity out of NERD, but my reaction is that this list of constraints may well be necessary and sufficient, but it's operationally error-prone. So I want to remove all possible dependencies for something so basic as bootstrapping the mapping database.

I'm sticking to my own suggestion: use well-known IP addresses
to bootstrap NERD, thereby avoiding any possible circular dependency
involving DNS by construction.

I certainly agree that enumerating the addresses that must never
be mapped, to avoid circularity, is a good thing.

    Brian


_______________________________________________ RAM mailing list RAM at iab.org https://www1.ietf.org/mailman/listinfo/ram