Re: against broken tld content

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Jim Reid;

> I have a number of problems with this draft.

Granted that they are your problems, not mine.

> [1] It appears to be a response to the current problems caused by
> Verisign's introduction of wildcards into the .com and .net TLDs.
> If so, it's the wrong response. That effort should be spent getting
> Verisign to undo their self-imposed damage. In other words, let's fix
> the underlying problem and not kludge around it.

But, it is not a problem, not even yours.

Your problem, instead, is that you have spent no effort to make a
concret proposal to solve the problem in your own way.

Only after you solve the problem, we can discuss pros and cons of
proposed solutions and choose to deploy some of them.

In addition, keep in mind that multiple solutions are not
necessarily exclusive and can be compatible.

In this case, my proposal is to maximize the self-imposed damage.

> [2] There's no definition of "broken" or "broken content". Therefore
> any criteria -- valid or not -- could be applied. This gives great
> scope for confusion and inconsistent behaviour. One "broken" server
> could be withdrawn while another equally broken one remains in use.

Your question is incosistent to your previous post.

You wrote:

> you mean by broken. [Not that I speak for Bill.] Brokenness could
> cover many things: lame servers, inconsistent zone contents, wrong
> DNSSEC keys or elapsed SIGs (ha!), "too slow" propagation of new zone
> data, unresolvable NS records, servers with polluted caches, zones
> with idiot wildcarding, all name servers behind one router or AS,
> buggy DNS software, name servers operated by someone called Jim, etc,
> etc.

And, you now have noticed that my draft says "broken content", which
means "broken" has been defined well.

> [3] It's not at all clear what the roles and responsibilities are and
> who develops and applies the procedures to implement them.

Are you saying roles and responsibilities of gtld server operators
and ISPs are clearly defined?

It is not.

> Who decides
> when something is "broken" and what action should be taken?

It is clearly defined in the draft.

> [4] The boundaries between each actor are blurred. A registry's job is
> to maintain the registry database and provide a timely, accurate copy
> of the zone. It should arrange contracts and SLAs with its DNS
> providers.

> [5] In many cases, the TLD registry is also the DNS provider.

Before expecting my comments, can you define the meaing of "DNS
providers"?

> [6] Some TLD name servers use anycasting. Should the entire anycast
> cloud be deleted because one server in that cloud is "broken"?

That is pointless. I said nothing about broken servers.

If you want to insists on this issue, can you explain your definition
of "broken"?

> [7] An uncomfortably low number of name servers provide slave service
> for an uncomfortably large number of TLDs: ns-ext.vix.com and
> ns.ripe.net for instance. It would not be sensible to cut off one of
> those name servers from the internet because one of the TLDs they
> served happened to be "broken".

I'm not sure what you mean "broken" here. But, if you are saying
"broken TLD content", as is defined in my draft which you recognized
at [2], it is sensible to cut off a server with such a content, of
course.

> [8] The draft gives a lot of scope for indirect DoS attacks. Suppose
> I'm an evil TLD registry operator. One of the TLD's name servers gets
> installed at an important network, say google.com. I make that server
> break in some way. An ISP follows your draft and stops traffic to that
> network because of the bad TLD server. Now Google is unreachable until
> someone fixes that TLD server. How about if I'm a slave DNS provider
> for some TLD who decides to "fix" its "brokenness" by adding say a
> wildcard to my copy of the TLD?

ISPs can disable a route to a host by putting bogus host route
without disableing the route to a network of the host.

Filtering a host, not a network, is even more easier.

But, it is a good idea that google runs gtld servers instead of
verisign, though, of course, at locations and networks separated
from google servers.

							Masataka Ohta
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.