Subject: Confirming the Nominet position

From: "Jay Daley" <[email-masked]>
Date: Wed, 26 May 2004 16:24:03 +0100

Here is a proper explanation of the Nominet position.

1.  Showstopper
Zone file enumeration is a show-stopper for us that will prevent us from 
fully implementing DNSSEC. So if DNSSEC stays in its current form then we 
will have to make a local determination about how/what we implement, which 
is still to be decided.  Our reason for this is our view of what is the 
appropriate policy to act in the best interests of our local community, 
which for some time has been to deny access to our zone files. 

2.  Late new comers
The criticism levelled about "late new comers" is well founded and I'm 
sorry that is the case.  This is something we should have raised some time 
ago.  Recognising that we were late with this we did try to avoid just 
unproductive foot stamping by the development of the NSEC2 draft as a 
positive alternative.  We are now committed to the process and we will be 
here to stay.  As evidence of this I should make clear that our next steps 
will be to get NSEC2 patches written for BIND and if possible NSD to allow 
proper interoperability testing.

3.  Way ahead
Ideally we would like NSEC2 to go forward properly, but I understand very 
well that this causes significant problems for many in this WG.  So we 
would be quite happy with a mechanism that allowed NSEC2 to be introduced 
later in a backwards compatible fashion, such as the previously suggested 
version field for NSEC.

3. Legal mumbo jumbo
I'm sorry if we appear to have been hiding behind legal mumbo jumbo, this 
was not our intention.  So I need to be clear that our legal advice is 
ancillary to our view in (1) above, not the determining factor. 

However, for those of you that have asked, this is the gist of our legal 
advice...

As compilations, zone file databases are protected under EU law by 
?Database Right?. As a derivative work of the main register from which 
they are sourced, they are likely also to attract copyright protection in 
addition to or in place of database right.

Both database right and copyright are negative rights in that they 
prohibit certain acts (primarily, copying the whole or a substantial part 
of the materials) but do not grant positive rights (unlike, for example, a 
patent, which grants a monopoly on the material involved). Database right 
is unique to countries which implement European Community law, but 
copyright is more universal. 

If legal rights would be infringed with copying, then is it not better to 
allow the copying, and then rely on the law to assist against any 
infringers?  The short answer is ?no?, and here the analogy of locking 
one?s house or car despite laws against burglary and theft may be helpful. 
 Prevention is not always better than cure, if one is led to make an 
overly restrictive solution in order to prevent a minor risk.  However, if 
the risk of harm is major, and is highly likely to take place, and will be 
expensive and difficult to put right after the event, then in those 
circumstances, prevention is very definitely better than cure.

The problem with both copyright and database right arises with 
enforcement, particularly in respect of electronic data such as a zone 
file.  Firstly it can be hard to identify whether a data mining event has 
taken place, in the context of the high volume of traffic affecting the 
nameservers on a day to day basis. If a technical department cannot show 
this, there is nothing that a legal department can do. Even if it is clear 
that it is happening, the technical department may not be able to trace 
who has done it, because the use of multiple proxies can make it 
impossible (or prohibitively expensive) to find it. Even if this can be 
done, the person(s) involved may be abroad. If they are in a difficult 
jurisdiction (even including eastern Europe, which is part of the EU) the 
differences in language and legal systems add to the expense and 
complexity of pursuing legal proceedings. 

Jay Daley
Director of IT
Nomient UK

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 May 2004 08:52:08 -0700

Note the Off topic pointer.  There is no protocol or engineering
in this message.  Hit D now.  This is a personal opinion.  I
am not a lawyer.  If you are still listening, I can't imagine why.

>addition to or in place of database right.

There is a great deal of very detailed law on the subject of how
concordances relate to rights in the resources for which the
concordances were created.  Effectively, you have published the
entries which allow the creation of a concordance of the database/resource
all along; anyone with a recursive resolver could in turn use that concordance
data to  reconstruct as much of the original resource as they cared to it.
The change you are seeing now is that a new mechanism for iterating
through the published entries makes the construction of the concordance
easier.

Deployment of that mechanism or failure to deploy that mechanism has *no
effect* on the rights of the users to create or use concordances of the
data.  Write that down.

You have always published this data; that's the point of the DNS. 
Write that down.

The real threat in all of this is not in the DNS itself, but in the 
use of the concordance
data as a key into a different database of other resources.  That is being
addressed in a different working group (CRISP), and your engineering talent
and resources put there might be better spent. (Just an opinion).

In short, spending your time and effort to deploying a real solution (IRIS) to
the core problem (accessible user data in administrative databases), makes
sense.  Educating your government that whether or not you use DNSSEC
will make *no difference* to whether or not you publish the actual data
and will make *no difference* to the rights individuals have to make 
concordances
may also make sense.  You may not have the stomach for it, and I certainly
would understand that.

Did I mention that this was off topic, that I am not a lawyer, and that I
can't imagine why you are listening?  Good.
					regards,
						Ted Hardie

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 May 2004 10:59:59 -0400

>ancillary to our view in (1) above, not the determining factor.

In preparing this response I didn't see in #1 a reason that was 
*clearly* technically based.  I.e., I suspect that "appropriate 
policy...best interests" is based in issues that are not technical. 
So perhaps what I have to say here isn't the "right" answer.

I'm at sea the moment someone brings up anything relating to legal 
issues.  Given the conflicting statements about legal opinions on 
this list, I'd ask for the lawyers to get together and come to some 
common understanding first.  After that - it can become a technical 
problem again.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: [email-masked] (Geoffrey Sisson)
Date: Thu, 27 May 2004 16:24:32 +0100 (BST)

Edward Lewis <[email-masked]> writes:

>          Given the conflicting statements about legal opinions on 

A common legal understanding covering all potential DNSSEC users is
unlikely.  It seems almost certain that there will be operators that
will deploy DNSSECbis regardless of impact of NSEC RR traversal, and
operators that cannot deploy because of it.  These divergent
requirements deliniate the scope of the technical problem.

Regards

Geoff

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 May 2004 16:43:00 +0100

>>>>> "Geoffrey" == Geoffrey Sisson <[email-masked]> writes:

    Geoffrey> A common legal understanding covering all potential
    Geoffrey> DNSSEC users is unlikely.  It seems almost certain that
    Geoffrey> there will be operators that will deploy DNSSECbis
    Geoffrey> regardless of impact of NSEC RR traversal, and operators
    Geoffrey> that cannot deploy because of it.  These divergent
    Geoffrey> requirements deliniate the scope of the technical
    Geoffrey> problem.

If an operator's reasons for not deploying DNSSECbis are policy ones,
how can this be a technical problem?

---

From: "Jay Daley" <[email-masked]>
Date: Thu, 27 May 2004 17:00:28 +0100

Jim

> how can this be a technical problem?

How does it sit with you if a technical change forces an operator into 
changing their policy? Are you saying that by default the policy must have 
been wrong in the first place?

Jay

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 16:39:04 +0000

> been wrong in the first place?

"wrong" is such a strong word.  "not the way dns was intended to work" and
"placing new requirements on dns, without standardization" are more to the
point.

---

From: [email-masked]
Date: Thu, 27 May 2004 16:52:30 +0000

> been wrong in the first place?

	Jay, w/o getting into the merits of any given policy, it seems 
	that the crux of the debate seems to be a tussle between what it
	technically possible and politically desirable.

	This particular tussle has occured many times in the past. One
	of my favorites is:  http://www.straightdope.com/classics/a3_341.html
	
	That aside, I suspect that -IF- one were to waive some of the 
	fundamental design principles of the DNS and DNSSEC, it would be
	possible to design a technical solution to your particular policy
	drivers.  I would not expect that technical solution to be useful
	to many/most others. As such, it would seem to inhibit broad use
	in an Internet-wide context.  But I could be wrong.

--bill

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 May 2004 17:53:40 +0100

>>>>> "Jay" == Jay Daley <[email-masked]> writes:

    Jay> How does it sit with you if a technical change forces an
    Jay> operator into changing their policy?

It depends on the technical change and the policy. If we're talking
specifically about a policy which sets out to prevent or thwart zone
enumeration, yes, I do think that policy needs to be reviewed.

Lots of other technical changes to the DNS -- IDN, IPv6, ENUM, etc --
are likely to mean policy changes for operators. In some cases, these
changes will mean policies have to be created. The deployment of
DNSSEC will be no different in that respect. As the saying goes, you
can't make an omelette without breaking eggs. If anything DNSSEC is
going to demand new and/or changed operator policies because of stuff
like key handling and so on.

    Jay> Are you saying that by default the policy must have been
    Jay> wrong in the first place? 

Not necessarily. The policy may well have been right for its time.
But when circumstances change, policies might have to change too.
Even if those policies were right. Or wrong as the case may be.

This thread is getting somewhat off-topic for namedroppers.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 May 2004 19:15:34 +0200

> how can this be a technical problem?

The technical problem is to find a solution that fit with the policy.
If the WG is not here to change the policy, it should not attempt to.

Regards,
Simon

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 May 2004 18:44:10 +0100

> been wrong in the first place?

Hmm, don't policies continuously get rewritten in the light of the emergence
of new technologies (e.g. IPv6 or ENUM as Jim suggested) or changes or
evolutions to existing technologies (or their usage or abuse patterns)?

A policy is generally just best practice for the current technical environment
(within the confines of the law :).   Best practice changes, but that doesn't
mean what went before it was wrong.

Tim

---

From: "Jay Daley" <[email-masked]>
Date: Thu, 27 May 2004 21:15:22 +0100

Bill

[email-masked] wrote on 27/05/2004 17:52:30:

>    drivers. 

This is the crux of it.  With DNS no fundamental principles are waived. We 
enforce our policy by controlling AXFR.  With DNSSECbis that is no longer 
possible.

Jay

---

From: [email-masked]
Date: Thu, 27 May 2004 20:35:29 +0000

> enforce our policy by controlling AXFR.  With DNSSECbis that is no longer 

	Er... yes it is.  Leave your AXFR blocks in place.  You still 
	prevent zone transfers.  DNSSEC has nothing to do w/ AXFR support.
	AXFR gives an -exact- copy of the zone, at a point in time.
	
	If you wish to prevent entities from getting the data, block 
	queries as well.  If you enable queries, then entities may build
	a NEAR copy of your data - in fact this is exactly what happens
	with caching nameservers. If I wish to build a highly accuate
	copy, without DNSSEC, I must generate large numbers of queries
	in a fairly short period, guessing at lable contents.  DNSSEC 
	allows me to reduce the number of queries, but they are still
	queries for individual records.  No AXFR involved. :)  

--bill

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 21:21:59 +0000

> enforce our policy by controlling AXFR.  With DNSSECbis that is no longer 

i disagree.  when i put the first AXFR-blocking code into BIND 4 in ~1988,
i considered it a protocol violation and i made my apologies to the gods.

it appears that those gods have a long memory, and a grand scale of vengeance.

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 28 May 2004 09:18:15 +0100 (BST)

> it appears that those gods have a long memory, and a grand scale of vengeance.

RFC 821 specifies SMTP as a protocol which permits any host to connect
to an `SMTP-receiver' and deliver messages.  Unanticipated developments
in the use of SMTP have resulted in this any <-> any principle being
challanged, in particular in the work of the marid WG.  There have
certainly been comparable developments in the (ab)use of DNS; perhaps
behaviour that was introduced via implementation rather than
specification should now be `ratified' via a standards-track document?

Regards

Geoff

---

From: [email-masked]
Date: Sat, 29 May 2004 15:16:11 +1200

>i considered it a protocol violation and i made my apologies to the gods.

Unfortunately, protocols designed in a kinder, gentler age have had to
be modified or "broken" to accommodate policy and security requirements
brought on by the somewhat nastier world that the Internet has become.

Every firewall on the planet basically represents a set of protocol
violations.  Some of them better considered than others.

It seems to me somewhat ironic that in attempting to deal with some of
the nastiness, DNSSECbis deployment itself faces problems because of
another facet of that very same nastiness.

>it appears that those gods have a long memory, and a grand scale of

-- don