Subject: delegation-only ineffective

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Sep 2003 12:13:54 +0859 ()

It is rather an oprational than a protocol issue, I'm posting
to DNSOP.

At

	http://www.isc.org/products/BIND/delegation-only.html

it is stated that:

	In response to high demand from our users, ISC is releasing
	a patch for BIND to support the declaration of "delegation-only"
	zones in caching/recursive name servers. Briefly, a zone which
	has been declared "delegation-only" will be effectively limited
	to containing NS RRs for subdomains, but no actual data outside
	its apex (for example, its SOA RR and apex NS RRset). This can
	be used to filter out "wildcard" or "synthesized" data from NAT
	boxes or from authoritative name servers whose undelegated
	(in-zone) data is of no interest. 

However, it is ineffective as a protection against synthesized NS
and synthesized child zone contents from NAT boxes or from authoritative
name servers whose undelegated (in-zone) data is of no interest. 

As for wildcarding, you can argue that synthesis is more evil than
wildcarding. However those who put undesired wildcard do not mind
and will perform equivalently effective undesired systhesis.

							Masataka Ohta
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 18 Sep 2003 09:38:57 +0200

On Thu, Sep 18, 2003 at 12:13:54PM +0859,
 Masataka Ohta <[email-masked]> wrote 

> However, it is ineffective as a protection against synthesized NS

IMHO, it simply means that there is no proper technical solution
against a political problem. We must fix ICANN, not the nameservers
(PowerDNS and djbdns have also "fixes" to this issue.)

Otherwise, we just started an arms race.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Sep 2003 09:34:18 +0200

> and will perform equivalently effective undesired systhesis.

Aren't synthesis and wildcards indistinguishable unless zone transfers
are involved?
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Sep 2003 16:54:53 +0859 ()

Florian Weimer;

> Aren't synthesis and wildcards indistinguishable unless zone transfers

Except for a presense of wildcard record is required for the latter
case, which can be used to guess that the answer is from the
wildcard, right.

However, it should be noted that behaviour of secondary servers not
controlled by an operator of the primary is different.

							Masataka Ohta

---

From: bert hubert <[email-masked]>
Date: Thu, 18 Sep 2003 10:42:49 +0200

> Otherwise, we just started an arms race.

If Verisign wants to follow us in this arms race they are forced to break
existing behaviour in more and more blatant ways, which is something they
won't help them if legal action ensues, which it most likely will.

There is a marked asymmetry here - there is no 'mutual assured destruction'
ahead. 

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 18 Sep 2003 11:05:37 +0200

> (PowerDNS and djbdns have also "fixes" to this issue.)

I fully agree. 

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

Now I am depressed ...

---

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

Bert;

> won't help them if legal action ensues, which it most likely will.

At least in this case, no.

All they need to do is to put wildcard NSes pointing to their
SLD synthesis servers.

For wildcarded NSes, secondary servers are, according both to
RFC1035 and recent clarificaiton draft, expected to behave just
as wildcarded A and MX.

And SLD servers for mostly-UDP transactions will be a lot less
loaded than TCP-based SMTP or HTTP servers.

Of course, applications just receive MX and A that nothing is
visible from applications.

						Masataka Ohta

---

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

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

    Masataka> However, it should be noted that behaviour of secondary
    Masataka> servers not controlled by an operator of the primary is
    Masataka> different.

Which is a moot point in the case of .com and .net. The registry
operator also runs all the authoritative name servers for this zone.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Sep 2003 21:15:55 +0859 ()

M_ns Nilsson;

> > (PowerDNS and djbdns have also "fixes" to this issue.)

Fix?

The problem is that ICANN is an organization established to destroy
IAHC activity.

ICANN is functioning just as intended to be.

							Masataka Ohta

---

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

Jim Reid;

> operator also runs all the authoritative name servers for this zone.

Really? I should revise my draft ID, then. Thanks.

						Masataka Ohta

---

From: Zefram <[email-masked]>
Date: Thu, 18 Sep 2003 14:25:47 +0100

>operator also runs all the authoritative name servers for this zone.

Perhaps this is something to discourage in any future update of RFC2870.
I'd go so far as to suggest that no single organisation should have
operational control of 50% or more of the authoritative name servers
for the root or any gTLD or similarly critical zone.

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: bert hubert <[email-masked]>
Date: Thu, 18 Sep 2003 15:56:03 +0200

> for the root or any gTLD or similarly critical zone.

I suggest mandating world peace while we are at it.

---

From: Robert Martin-Legene <[email-masked]>
Date: Thu, 18 Sep 2003 16:33:20 +0200 (MET DST)

> for the root or any gTLD or similarly critical zone.

Depending on where you are, one might argue that certain ccTLD zones
really are more critical than any of the gTLD's. I don't think you'll be
able to phrase it very well.

Also, some TLD registries doesn't want anyone to have copies of the entire
zone, so they choose to run all servers themselves.

Even if you were to get it into an RFC with reasonable wording, and, let's
say .dk was critical for Danish people, what means could be used to force
a ccTLD to have secondaries not run by themselves?

I think there's a long way to go before that were to happen, since the
agreements between many ccTLD registries and ICANN is kind of foggy.

-- Robert Martin-Legène

---

From: Zefram <[email-masked]>
Date: Thu, 18 Sep 2003 16:02:20 +0100

>able to phrase it very well.

RFC 2870 already speaks of being useful to "[o]ther major zone server
operators (gTLDs, ccTLDs, major zones)", and RFC 3172 explicitly
applies the full force of RFC 2870 to ARPA.  I had these in mind when
speaking of "similarly critical" zones.  Whether there should be a formal
requirement to apply RFC 2870 (or some weakened subset of it) to gTLDs is
an interesting matter; the trend certainly seems to be in that direction.

>zone, so they choose to run all servers themselves.

That's something it would be nice to stop.  DNS data is supposed to
be public.  (Yes, I know, I'm an idealist.)  If a formal requirement for
independent entities to be able to serve the zone prevents this kind of
secrecy, that'd be a nice bonus.

-zefram

---

From: Robert Martin-Legene <[email-masked]>
Date: Thu, 18 Sep 2003 17:47:38 +0200 (MET DST)

> secrecy, that'd be a nice bonus.

I think the major reason that registries are blocking AXFR, is because it
has become too common that people abuse the information that obtain from
it.

I'm thinking if that isn't also a little bit of the reason why DNSSEC
hasn't been deployed (in any TLDs?).

-- Robert Martin-Legène

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Sep 2003 18:28:34 +0100

>>>>> "Robert" == Robert Martin-Legene <[email-masked]> writes:

    Robert> I'm thinking if that isn't also a little bit of the reason
    Robert> why DNSSEC hasn't been deployed (in any TLDs?).

Nope. The main reason why DNSSEC hasn't been deployed for real is the
protocol specs haven't been finished.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Miek Gieben <[email-masked]>
Date: Fri, 19 Sep 2003 10:16:09 +0200

[On 18 Sep, @17:47, Robert wrote in "Re: delegation-only ineffectiv ..."]
> hasn't been deployed (in any TLDs?).

well, that is not entirely true... you can do a nxt-walk very easily. You can
also block such walks very easily. Just rate limit the amount of nxt-queries
per IP. 

This is the same as the privicy issues concerning whois queries. Some registries
are also rate limiting that. Which is not 100% secure, but it adds another barrier,

    grtz  Miek

--
NLnet Labs