Subject: Re: [dnsop] lame delegation DOS (was ccTLD delegation analysis)

From: Mark Foster <[email-masked]>
Date: Thu, 22 Jan 2004 11:34:33 -0800

On Mon, Dec 15, 2003 at 12:19:19PM -0800, Doug Barton wrote:
> Mark Foster wrote:
> 
> >OK. However this approach ignores the real-world observations that lame 
> >delegations produce an inordinate load on the parent name servers,
> >apparently due to broken resolver implementation(s).
> > 
> >I have seen this happen a number of times. The resulting query loop
> >has comprised up to 80% of the parent server query traffic.
> 
> There is a serious problem with one very popular vendor's resolving name 
> server implementation wherein if _all_ the name servers in the parent's 
> delegation are lame, it will enter a loop. If even one of the name 
> servers in the delegation respond, the loop is broken.
> 
> Doug
> 

Sorry for the long delay in getting back about this. Can you elaborate
on this apparent deficiency in the DNS infrastructure? Is the vendor
Microsoft?

It seems that if a ccTLD chooses to accept registrations from the
general public, but chooses to not enforce authoritative name servers before
publishing the delegation, they are opening themselves up for a denial of 
service attack. If the ccTLD name servers are taken out, the ccTLD goes 
dark. So if these ccTLDs are not built to scale to the attack, they
are at risk.

Could this happen, and if so how can the risk be mitigated?
-- 
Some days it's just not worth chewing through the restraints...
Mark Foster <[email-masked]>  http://mark.foster.cc/

---

From: Jim Reid <[email-masked]>
Date: Thu, 22 Jan 2004 21:34:32 +0000

>>>>> "Mark" == Mark Foster <[email-masked]> writes:

    Mark> It seems that if a ccTLD chooses to accept registrations
    Mark> from the general public, but chooses to not enforce
    Mark> authoritative name servers before publishing the delegation,
    Mark> they are opening themselves up for a denial of service
    Mark> attack. If the ccTLD name servers are taken out, the ccTLD
    Mark> goes dark. So if these ccTLDs are not built to scale to
    Mark> the attack, they are at risk.

Enforcing a check for authoritative servers at delegation time isn't
much help, though it's a start. What happens if the delegation goes
lame later? I recall a survey Patrik Faltstrom did of the .se TLD a
couple of years ago. The registry has/had a bunch of checks before a
delegation was made. If the zone wasn't set up right, no delegation
was done. Even in that environment, entropy eventually wins. Around
25% of the delegations in .se were broken in one way or another.
Though this figure included more errors than just lame delegations.

Even without any lame delegations -- and that's too much to even
fantasise about -- few zones have infrastructure that's robust enough
to withstand DDoS attack. Come to think of it, there's probably
nothing that can cope with a serious and sustained DDoS attack. As
anyone who's tried to buy the year's favourite toy in the run-up to
xmas could tell you.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Daniel Senie <[email-masked]>
Date: Thu, 22 Jan 2004 17:18:28 -0500

At 04:34 PM 1/22/2004, Jim Reid wrote:
>lame later?

It's worse than that, actually. If I go onto the reseller system my company 
uses to sell domain names and register a name, I don't yet know for sure 
that I will get the name. Do I inject the proposed name into my name 
servers, then check to see if it's available? Do I check that it's 
available, add to my name servers, then go back and reserve it and see if 
someone else got it in between? I'm not convinced there's value to our 
messing with our name servers until such time as the name is successfully 
registered.

The name servers we specify in records DO exist. A check to see that the 
servers are legit would be reasonable. But checking to see that the servers 
provide authoritative answers for a domain that has not yet been delegated 
seems like a very BAD idea. There's got to be a bit of slack in the sequencing.

It'd actually be quite welcome if TLD managers had some way to run 
automated reports that'd email out reports to technical contacts about any 
domains that were returning lame delegations. 

.

---

From: Jim Reid <[email-masked]>
Date: Thu, 22 Jan 2004 23:59:18 +0000

>>>>> "Daniel" == Daniel Senie <[email-masked]> writes:

    Daniel> It'd actually be quite welcome if TLD managers had some
    Daniel> way to run automated reports that'd email out reports to
    Daniel> technical contacts about any domains that were returning
    Daniel> lame delegations.

In theory, yes. In practice, no. How do you send email to somewhere
that lives behind a lame delegation? Some of the problems Patrik's
survey of .se identified included broken or non-existent MX records,
email addresses that were not known to the target SMTP server, bogus
contact data in the registry database and SOA RNAME, MX records which
pointed at hosts with no SMTP listener, etc.

There are other problems with your suggestion too. For example,
registries might get into trouble with their national competition
authorities if they start offering services that are outwith their
monopoly position and could be provided by others. Some registries
won't have the infrastructure or revenue to do these sorts of
pro-active checks. And there's a whole world of difference between
reporting a lame delegation and getting the zone owner to fix the
problem. Or force them to fix it.

Having said that, I'd like delegations to be checked regularly. Even
better if it's done by an outside party. This is good housekeeping and
it's good for the health of the internet. Registrars are probably
better placed than anyone else to do those checks. One thing a
registry could do is remove lame delegations from the TLD zone file --
but not the zone's registration from the registry database -- and
restore them once the name servers are fixed.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Daniel Senie <[email-masked]>
Date: Thu, 22 Jan 2004 19:32:44 -0500

At 06:59 PM 1/22/2004, Jim Reid wrote:
>that lives behind a lame delegation?

There's a reason I specifically said "Technical Contact." With a large 
percentage of the registrations we see or initiate, the Technical Contact 
is NOT within the domain the registration covers.

>  Some of the problems Patrik's

Clearly there is an ongoing problem with bogus data.

>problem. Or force them to fix it.

I guess I didn't think about this as a service that'd cost the registrants 
money. At least with the gTLD's, the registry is already being paid for 
service. This would be a way they could provide an improvement on that 
service, though it's also something that registrars could do themselves in 
the case of the gTLDs.

>restore them once the name servers are fixed.

I think we're in basic agreement that something of this sort would be a 
help. The question of how to implement it is probably a business decision 
for those who might implement it, and beyond the scope of the WG.

.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Fri, 23 Jan 2004 01:31:40 +0100

>domains that were returning lame delegations.

It would be most welcome. I run a small TLD list (around 1800 domain names) 
so I still can run a dig on all the names, to get some experience of the 
name space. I find the number of non resolving names very high (however 
registrants paid a high price for their name and renew): around a quarter 
of them. Any existing tool which could help?
JFC Morfin

.

---

From: Jim Reid <[email-masked]>
Date: Fri, 23 Jan 2004 02:13:26 +0000

>>>>> "Daniel" == Daniel Senie <[email-masked]> writes:

    Daniel> There's a reason I specifically said "Technical Contact."
    Daniel> With a large percentage of the registrations we see or
    Daniel> initiate, the Technical Contact is NOT within the domain
    Daniel> the registration covers.

While that may be the case for your customers and their registrations,
I doubt if it holds for the rest of the world's registrants and
registrars. It would be good to get hard data on what percentage of
email addresses for technical contacts actually reach a valid, clueful
technical contact. We know this information is often broken. But how
many and how badly?

    Daniel> Clearly there is an ongoing problem with bogus data.

Indeed. But who's going to do anything about it? Should we care?

    Daniel> I think we're in basic agreement that something of this
    Daniel> sort would be a help. The question of how to implement it
    Daniel> is probably a business decision for those who might
    Daniel> implement it, and beyond the scope of the WG.

I agree that checking tools and enforcement procedures would help.
These need to be based on something like an agreed BCP. This falls
within the scope of this WG. How that BCP was then implemented would
be a combination of business and policy decisions. ie A registry or
registar decides to offer this as a value-added service. Or perhaps
ICANN tells registries/registrars they have to do this.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Jim Reid <[email-masked]>
Date: Fri, 23 Jan 2004 02:15:34 +0000

>>>>> "J-F" == J-F C (Jefsey) Morfin <[email-masked]> writes:

    >> It'd actually be quite welcome if TLD managers had some way to
    >> run automated reports that'd email out reports to technical
    >> contacts about any domains that were returning lame
    >> delegations.

    J-F> Any existing tool which could help?

There are zillions of them. As you'd see by feeding "DNS Delegation
Checking tools" into google.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Fri, 23 Jan 2004 03:18:36 +0100

At 01:32 23/01/04, Daniel Senie wrote:
>for those who might implement it, and beyond the scope of the WG

Before taking a business decision, there is a need to know what is 
technically possible and reasonably advisable. Could you help with a 
practial suggestion ?

Removing a lame server will not be noticed by the user, until he corrects 
the problem. Then he will harass us is asking why it does not work and when 
will it be back again. So a substantial effort from our side. I thought 
about giving a mailbox to every registrant and to use it to relte with 
them. So at least when they have a problem they can come and see all the 
pending infromation they did not read.

If you have a good suggestion, I am OK to see how to implement it and to 
report on its results.
jfc

.

---

From: Måns Nilsson, KTHNOC <[email-masked]>
Date: Sun, 25 Jan 2004 22:19:54 +0100

--On Thursday, January 22, 2004 21:34:32 +0000 Jim Reid <[email-masked]> 
wrote:

> I recall a survey Patrik Faltstrom did of the .se TLD a
> was done.

This only applied for redelegation, not for new domains. Now, as the 
registry has been more, if not enough, automated, the check applies to
newly registered domains whose delegation data can be auto-submitted. But,
DNS data for not yet approved domain registrations is not checked.

> Even in that environment, entropy eventually wins. Around

Do note "one way or another". Not all these 25% were totally lame.
Also, it has helped very much the common case of negligent dns operator at 
web hotel who waits for "ok" from registry before setting up dns for a new 
customer switching dns providers, thereby blackholing them for at least 
TTL.

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE