Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

At 15:48 19.08.99 -0700, hardie@equinix.com wrote:

> >
> >       How do you know which "[a-m].root-servers.net" there are?
> >
> > My proposal is:
> >
> >     1)        Don't. Use today's unicast routing as is. Simplicity. Good.
> >
> >     2)        Let ISPs run RSs and let their customers be aware of reality.
> >       Tell customers that NS(.) =
> >           rs1.their.provider [1.2.3.45]
> >           rs2.their.provider [1.2.4.56]
> >           rs3.their.provider [1.2.5.67]
>
>The problem here is that they are not really roots.  They derive their
>data from what you call "Real Root Servers" and they act as a new
>level in the hierarchy which is not reflected in the notation.  If I
>understand your proposal correctly, rs1.their.provider would have to
>respond to an SOA request by claiming to be authoritative for . to
>avoid having internal servers just query up the chain to the Real Root
>Servers. That seems to imply that they would have to re-write the data
>they get from the Real Root Servers to claim that authority.  That
>pretty much makes them an active man in the middle attack and open to
>all sorts of problems, including a pretty easy form of splintering.

I don't get this - is any software anywhere actually routing queries
to the nameserver named in the SOA record?

I know for a fact that some zones have a nameserver in their SOA that
isn't in their NS list (the case where I know why, it's because the
Real Master is behind a dialup link, but still with a fixed IP addr)

If not, I'd say that this distinction is part of the solution, not
part of the problem; where the info comes from is SOA, where you get it
from is NS.

The problem of who signs the NS set is a nasty one anyway.

                          Harald

--
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no