Subject: against broken tld content

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Sep 2003 06:50:57 +0859 ()

Any comment?

					Masataka Ohta
---

INTERNET DRAFT                                                   M. Ohta
draft-ohta-broken-tld--1.txt               Tokyo Institute of Technology
                                                          September 2003

                 Distributed Actions Against Broken TLD

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html The list of Internet-Draft
   Shadow Directories can be accessed at http://www.ietf.org/shadow.html

Abstract

   This memo describes actions against broken content of a primary
   server of a TLD.  Without waiting for an action of some, if any,
   central authority, distributed actions TLD server operators and ISPs
   can settle the issue, for a short term.

1. Introduction

   DNS is a fully distributed database of domain names and their
   associated values with loose integrity.

   However, the primary server of a zone is a single point of failure of
   the zone to hold the current most copy of the zone and such a failure
   at TLD can cause a lot of damage to the Internet.

   As it may take time for a central authority, if any, take care of the
   problem, this memo describes distriburted actions as a short term
   solution to protect the Internet against broken TLD zone content.

   The long term solution is to let the primary server operator fix the
   content or to change the primary server operator, which may involve a
   central authority.

M. Ohta                Expires on March 17, 2004                [Page 1]

INTERNET DRAFT                 Broken TLD                      June 2003

   Similar technique is applicable to root servers with broken contents.

2. Actions of TLD Server Operators

   A TLD server operator who have found that TLD zone content is broken
   should disable zone transfer and use a copy of old zone content known
   not to be broken.

   Or, if the fix for the zone content is obvious and easy, the operator
   may manually or automatically edit the content of the current most
   one without updating SOA serial number. In this case, zone transfer
   may not be disabled, though actions of ISPs described in section 3
   may make the transfer from servers of broken content impossible.

3. Actions of ISPs

   ISPs should disable routes to TLD servers with broken content and/or
   filter packets to/from the TLD servers.

   ISPs should periodically check the servers, whether they still
   contain broken content or not.

4. Security Considerations

   As for security, TLD servers should never have broken content.

5. Author's Address

   Masataka Ohta
   Graduate School of Information Science and Engineering
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299
   EMail: [email-masked]

M. Ohta                Expires on March 17, 2004                [Page 2]

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: [email-masked]
Date: Tue, 16 Sep 2003 17:07:03 -0700 (PDT)

please define the term "broken"

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Sep 2003 09:51:23 +0859 ()

Bill;

>  please define the term "broken" 

As the actions are distributed, whether a zone content is broken
or not is judged by those who make actions.

That is, we don't need any central authority to define "broken".

							Masataka Ohta

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Sep 2003 03:20:37 +0200

>  please define the term "broken" 

How about abusive?

   Domain Name: BOSS.COM
   Organization:
      Boss Game Studios
      Colin Gordon
      15400 NE 90th ST Suite 300
      Redmond, WA 98052
      US
      Phone: 425-556-0440
      Fax..: 425-556-0547
      Email: [email-masked]

   Registrar Name....: Register.com
   Registrar Whois...: whois.register.com
   Registrar Homepage: http://www.register.com

      Created on..............: Tue, Sep 14, 1993
      Expires on..............: Sat, Sep 13, 2008
      Record last updated on..: Tue, Mar 11, 2003

They were hit by W32/Sobig-A (envelope sender used was "[email-masked]")
so they decided to remove NS/MX/A records. The domain still belongs to
them according to whois.

Now do a A lookup on  boss.com
I'd clearly say this is abusive domain hijacking and it's on purpose.
And probably boss.com is not the only domains abused that way.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: [email-masked]
Date: Tue, 16 Sep 2003 20:14:43 -0700 (PDT)

Ota-san titled his draft "..Broken.." 
and did not define the term. I sense your outrage,
but abusive does not fit well within what I was reading
from Ota-san. If he so choses, he may change the text
of his draft.

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Sep 2003 08:37:54 +0100

>>>>> "Markus" == Markus Stumpf <[email-masked]> writes:

    Markus> They were hit by W32/Sobig-A (envelope sender used was
    Markus> "[email-masked]") so they decided to remove NS/MX/A
    Markus> records. The domain still belongs to them according to
    Markus> whois.

    Markus> Now do a A lookup on boss.com I'd clearly say this is
    Markus> abusive domain hijacking and it's on purpose.  And
    Markus> probably boss.com is not the only domains abused that way.

So all that spam and virus crap ends up at the door of Verisign's
wildcard entry? Cool!
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Sep 2003 10:11:19 +0859 ()

Bill;

As a non native user of English, I have no strong opinion on
terminologies but want to use plain English.

> from Ota-san. If he so choses, he may change the text

As you seem to know the definition of "abusive", can you please
explain it to me?

To me, "broken" is a plain English word with no further explanation
required, "abusive" is not and is rather pedantic.

> from Ota-san.

Are you saying you think "broken" fits well and you still need
a definition on it?

							Masataka Ohta

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Sep 2003 10:38:52 +0100

>>>>> "Masataka" == Masataka Ohta <[email-masked]> writes:

    Masataka> Are you saying you think "broken" fits well and you
    Masataka> still need a definition on it?

I think what Bill was saying was that your draft needs to define what
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. Which of these scenarios fall within your implicit category of
broken? If you want people to take certain action whenever they
encounter a broken name server, there should be a clear definition of
what broken means. If there isn't, anyone will be able to apply their
own arbitrary definition of brokenness. That would be even more broken
as it would lead to lots of confusion and inconsistency. For example,
most of this list will probably have an opposite opinion on the
current level of brokenness of .com and .net from the people at
Verisign who recently added that controversial wildcard.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Sep 2003 15:50:26 +0100

I have a number of problems with this draft.

[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.

[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.

[3] It's not at all clear what the roles and responsibilities are and
who develops and applies the procedures to implement them. Who decides
when something is "broken" and what action should be taken?

[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. Their job is to comply with that SLA and just publish the
zone data they're given. DNS providers must never, ever tamper with
that data, no matter how well-intentioned they might be. They don't
maintain or own the zone and therefore have no business interfering in
any way with its contents. That's the start of a very dangerous and
slippery slope. [And anyway. editing a slave's copy of some zone file
will really break things if/when that zone gets signed.] Likewise,
it's an ISP's job to supply bandwidth and route packets. They have no
business making value judgements about someone else's DNS zone content
or name server brokenness either. Even worse would be defining their
routing policies on those judgements. In some cases, it's unlikely an
ISP will have enough DNS clue to make those judgements.

[5] In many cases, the TLD registry is also the DNS provider. They
operate the zone's name servers. [That's the case with Verisign and
.coma and .net.] So it's hard to see what your draft could achieve,
assuming it was applied to these two TLDs, which presumably we're
considering to be broken because of the recently added wildcards.

[6] Some TLD name servers use anycasting. Should the entire anycast
cloud be deleted because one server in that cloud is "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".

[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?
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: [email-masked]
Date: Thu, 18 Sep 2003 10:02:28 -0700 (PDT)

> you mean by broken. [Not that I speak for Bill.] Brokenness could

	often you speak better than I.  thanks for clarifying 
	many of the points I implied.
	
> Verisign who recently added that controversial wildcard.

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Sep 2003 17:20:45 +0859 ()

Jim Reid;

> I have a number of problems with this draft.

Granted that they are your problems, not mine.

> 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.

> could be withdrawn while another equally broken one remains in use.

Your question is incosistent to your previous post.

You wrote:

> etc.

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

> 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

It is clearly defined in the draft.

> 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"?

> 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"?

> 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.

> 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