Re: against broken tld content

[Jim Reid <jim@rfc1035.com>]

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 <dnsop-request@cafax.se>.