Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-06.txt

From: [email-masked]
Date: Tue, 22 Jan 2008 12:15:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: DNS Zone Transfer Protocol (AXFR)
	Author(s)	: A. Gustafsson
	Filename	: draft-ietf-dnsext-axfr-clarify-06.txt
	Pages		: 0
	Date		: 2008-1-22
	
The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements.  The Authoritative
Transfer (AXFR) is defined in RFC 1034 and RFC 1035.  The Incremental
Zone Transfer (IXFR) is defined in RFC 1995.  A mechanism for prompt
notification of zone changes (NOTIFY) is defined in RFC 1996.  The base
definition of these facilities, that of the AXFR, has proven
insufficient in detail, resulting in no implementation complying with
it. Yet today we have a satisfactory set of implementations that do
interoperate. This document is a new definition of the AXFR, new in the
sense that is it recording an accurate definition of an interoperable
AXFR mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsext-axfr-clarify-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 08:36:49 +1100

There is no mention of TSIG.

2.1.5 Additional Section

The client MAY include an EDNS0 section.  If the server has indicated
that it does not support EDNS0, the client MUST send this section empty
if there is a retry.

If the client is aware that the server does not support EDNS0,
RECOMMENDED that this section be sent empty.  A client MAY become aware
of a server's abilities via a configuration setting.

An implementation of a general purpose client and server is RECOMMENDED
to support EDNS0.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 08:44:50 +1100

Note 2.1.1.b The value in this field has no meaning in the
context of AXFR.  For the client, RECOMMENDED that the value be zero. 
For the server, RECOMMENDED ignoring this value.

	I know we are talking about the query in section 2 but it
	needs reinforcement as AA has meaning in the response.

Note 2.1.1.b The value in this field has no meaning in the context
of a AXFR QUERY.  For the client, RECOMMENDED that the value be
zero.  For the server, RECOMMENDED ignoring this value.

	I suspect this is a matter of a oversite by IANA.

Note 2.1.1.c The Z bit is no longer registered with IANA (no document
cited for change).  RECOMMENDED client set to 0, server MUST ignore.

	To the best of my knowlegde it is still zero on send.  There
	is debate over ignore / return FORMERR on receive.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 08:54:23 +1100

Where does REFUSED and NOAUTH fit into this?

	There is no mention of a negative response to the query
	other than dropping the TCP connection.  The later is against
	the advise of RFC 1035 which says that multiple queries
	should be supported and the SOA + AXFR must be supported.
	Dropping the TCP session prevents multiple AXFR using the
	same TCP session, be it serially or by multiplexing the
	results.

2.2 AXFR Response

The AXFR Response will consist of 0 or more messages.  A server MAY
elect to ignore the request altogether.  The first response MUST begin
with the SOA resource record of the zone, the last response MUST
conclude with the same SOA resource record.  Intermediate responses MUST
not contain the SOA resource record.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jan 2008 17:56:57 -0500

Mark,

It would be easier to answer if you segregated your remarks from 
quoted text with some sort of delimiting character.  Or maybe address 
comments to sections of the document.

>	There is no mention of TSIG.

It is in the document.  RFC 2845 is referenced three times.  The 
penultimate paragraph of section 5, second paragraph of section 6. 
(And earlier in section 2.)

In section 2.1.5, there is a mistake, "EDNS0 section" was meant to be 
"EDNS0 OPT Resource Record".  Perhaps "EDNS0 OPT" is redundant but I 
wanted to emphasize the point.

Looking at RFC 2845, I had mistakenly thought that TSIG rode in an 
OPT RR.  So, the restrictions on ADCOUNT should be 0, 1, or 2, based 
on the use of EDNS0 and/or TSIG/SIG(0), is that right?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 10:08:27 +1100

> on the use of EDNS0 and/or TSIG/SIG(0), is that right?

	Yes.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Jan 2008 23:13:43 +0000

> Looking at RFC 2845, I had mistakenly thought that TSIG rode in an OPT RR.
> So, the restrictions on ADCOUNT should be 0, 1, or 2, based on the use of
> EDNS0 and/or TSIG/SIG(0), is that right?

yes.  and if both OPT and TSIG are present, then TSIG must be last.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jan 2008 18:10:09 -0500

Again, a little trouble understanding the points.

>zero.  For the server, RECOMMENDED ignoring this value.

I suppose you are suggesting to replace the first 2.1.1.b with the 
first.  I don't see a second 2.1.1.b in my doc (I am prone to such 
numbering errors).

>	I suspect this is a matter of a oversite by IANA.

What is "this" referring to?

>	is debate over ignore / return FORMERR on receive.

When it comes to protocol design, my guidance on this is, if the bit 
being 1 is not expected but otherwise is not confusing, ignore it. 
There's little sense in trying expand the number of error states.

Future-proofing benefits too, ignoring the MUST be set to zero's 
allows a future implemention to try to make use of the extensions 
without wasting probe messages.

The issue about whether it MUST be 0 or is something else is 
comlicated by the fact that it has changed in the registry ([IANA]) 
and we don't know why.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jan 2008 18:24:16 -0500

>yes.  and if both OPT and TSIG are present, then TSIG must be last.

Thanks for the clarification.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jan 2008 18:23:49 -0500

>	same TCP session, be it serially or by multiplexing the

See Note 2.2.1.f.  If you want the list of explicit errors expanded I 
can do that.  REFUSED and NOAUTH are two types I assume have broader 
meanings and are covered by referring to the IANA registry for error 
types.

As far as the drop the connection response, well, that is de jure 
legal these days and it has merit as a response.  I once believed in 
the sanctity of the query-response pair but have been convinced that 
we shouldn't require a response to all queries.  Particularly when 
the query is thought to be sent maliciously (like a DoS attempt).

Can you explain what you mean by the SOA + AXFR must be supported?

I understand the implications of dropping the TCP transport because 
you want to end an AXFR session when there are other concurrent 
sessions riding the same transport.  They all fall down.  The 
question is, how frequently is a connection you feel the need to drop 
going to have multiple, legitimate, concurrent sessions?

---

From: David Conrad <[email-masked]>
Date: Tue, 22 Jan 2008 16:04:01 -0800

Waking up from my nap...

> comlicated by the fact that it has changed in the registry ([IANA])

Eh?  What registry?

Thanks,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 11:28:45 +1100

> the query is thought to be sent maliciously (like a DoS attempt).

	If you are *being* DoS'd then this a legitimate response.
	One request does not a DoS make.  Programing this as *default*
	behaviour is just anti-social.  Seeing REFUSED/NOAUTH in a
	log is much more informative than the connection went away.
	Think of the poor ISP that is offing DNS hosting services.

	Connection went away means "retry".  REFUSED means "go
	away".

	If you can't afford to send a single packet response which
	is no bigger than the query then there is something very
	wrong.

	RFC's are about promoting interoperabilty.  This is both
	at the machine and human levels.  Closing the connection
	does neither.   A machine getting REFUSED/NOTAUTH could use
	refresh rather than retry as the interval for next connection.
	A machine getting REFUSED could just mark the zone as
	inoperable until a human told it to re-probe.  Neither
	strategy applies to connection closed.
 
>Can you explain what you mean by the SOA + AXFR must be supported?

	RFC 1035 4.2.2. TCP usage
 
> going to have multiple, legitimate, concurrent sessions?

	I want a useful diagnostic to be sent.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jan 2008 19:43:57 -0500

>>  comlicated by the fact that it has changed in the registry ([IANA])

Referring to "bit 9" http://www.iana.org/assignments/dns-header-flags,

#DNS Header Flags per [RFC1035]
#------------------------------
#In DNS query header there is a flag field in the
#second 16 bit word in query from bit 5 through
#bit 11 (RFC1035 section 4.1.1)
#
#
#bit 5     AA   Authorative Answer	[RFC1035]
#bit 6     TC   Truncated Response	[RFC1035]
#bit 7     RD   Recursion Desired	[RFC1035]
#bit 8     RA   Recursion Allowed	[RFC1035]
#bit 9          Reserved
#bit 10    AD   Authentic Data  	[RFC4035]
#bit 11    CD   Checking Disabled	[RFC4035]

I admit that it doesn't say [IANA] there, but I can say this is where 
the false memory got in my head:

From: http://www.iana.org/assignments/dns-parameters

#Domain System Operation Code:
#
#OpCode   Name                                          References
#------   ----                                          ----------
#     0   Query                                          [RFC1035]
#     1   OpCode Retired (previously IQUERY - No further [RFC3425]
#         assignment of this code available)
#     2   Status                                         [RFC1035]
#     3   reserved                                       [IANA]
...

With a reread, maybe the only "mistake" in the IANA registry is that 
the "bit 9" should still read:

bit 9      Z   Reserved			[RFC1035]

And I need to reword out the "Z bit" because Z referred to 3 bits 
"reserved for future use" in RFC 1035.

---

From: David Conrad <[email-masked]>
Date: Tue, 22 Jan 2008 17:55:33 -0800

Ed,

...
...
> With a reread, maybe the only "mistake" in the IANA registry is that the "bit
> 9" should still read:
> 
...

If you would like to make this change (and no one thinks Ed is sniffing more
glue than usual), let me know and I'll get a ticket created.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 13:17:45 +1100

> glue than usual), let me know and I'll get a ticket created.

	Looks reasonable to me.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jan 2008 02:44:18 +0000

> glue than usual), let me know and I'll get a ticket created.

Z and [RFC1035] looks right to me.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 23 Jan 2008 08:29:37 +0100

Edward Lewis wrote:
| At 23:13 +0000 1/22/08, Paul Vixie wrote:
|>>  Looking at RFC 2845, I had mistakenly thought that TSIG rode in an
|>> OPT RR.
|>>  So, the restrictions on ADCOUNT should be 0, 1, or 2, based on the
|>> use of
|>>  EDNS0 and/or TSIG/SIG(0), is that right?
|>
|> yes.  and if both OPT and TSIG are present, then TSIG must be last.
|
| Thanks for the clarification.

This is not documented anywhere (AFAIK).

NSD accepts the order leniently, sends TSIG last.

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 18:37:34 +1100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Edward Lewis wrote:

   3.2. TSIG processing on incoming messages

   If an incoming message contains a TSIG record, it MUST be the last
   record in the additional section.  Multiple TSIG records are not
   allowed.  If a TSIG record is present in any other position, the
   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
   returned.  Upon receipt of a message with a correctly placed TSIG RR,
   the TSIG RR is copied to a safe location, removed from the DNS

> Best regards,
> ~   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFHluzhkDLqNwOhpPgRAruNAKCLi52CcfKUQ5lLl+lmA99ZmiXouACfQG3U
> S7dmI0wSsvbdSsLOh7qOa0k=
> =7YMk
> -----END PGP SIGNATURE-----

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 23 Jan 2008 08:40:10 +0100

Mark Andrews wrote:
| Edward Lewis wrote:
| | At 23:13 +0000 1/22/08, Paul Vixie wrote:
| |>>  Looking at RFC 2845, I had mistakenly thought that TSIG rode in an
| |>> OPT RR.
| |>>  So, the restrictions on ADCOUNT should be 0, 1, or 2, based on the
| |>> use of
| |>>  EDNS0 and/or TSIG/SIG(0), is that right?
| |>
| |> yes.  and if both OPT and TSIG are present, then TSIG must be last.
| |
| | Thanks for the clarification.
|
| This is not documented anywhere (AFAIK).
|
| NSD accepts the order leniently, sends TSIG last.
|
|>    3.2. TSIG processing on incoming messages
|
|>    If an incoming message contains a TSIG record, it MUST be the last
|>    record in the additional section.  Multiple TSIG records are not
|>    allowed.  If a TSIG record is present in any other position, the
|>    packet is dropped and a response with RCODE 1 (FORMERR) MUST be
|>    returned.  Upon receipt of a message with a correctly placed TSIG RR,
|>    the TSIG RR is copied to a safe location, removed from the DNS

Mark, this is only about TSIG. Not TSIG together with EDNS OPT. EDNS OPT
must be last too.

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 18:46:47 +1100

> Mark, this is only about TSIG. Not TSIG together with EDNS OPT. EDNS OPT

	No.  OPT is just required to be in the additional section.

4.1. One OPT pseudo-RR can be added to the additional data section of
     either a request or a response.  An OPT is called a pseudo-RR
     because it pertains to a particular transport level message and not
     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
     or stored in or loaded from master files.  The quantity of OPT
     pseudo-RRs per message shall be either zero or one, but not
     greater.

> iD8DBQFHlu9akDLqNwOhpPgRAvFJAKCYLn4fAAR4ZQlDgNq4gInXfjoA2QCcCZQh
> pQGgJgk1t1a3Zn15rj6DGCU=
> =yO2G

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 23 Jan 2008 09:02:17 +0100

Mark Andrews wrote:
| 	I want a useful diagnostic to be sent.

For a new protocol, I would definitely agree. For AXFR, the deployed
base needs to be considered. I'm fine with some optional thingie to send
these diagnostics that leaves existing AXFR software compliant. But I
cannot think of a way to do that. Some way to cause the other side to
drop the connection (if it is older software) ?

NSD as an AXFR client (both NSD 2 and NSD 3) checks QR=1, RCODE=0 and
ID=ok values in response messages, this seems to work well, there have
been no complaints about interoperability.

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 19:29:32 +1100

> drop the connection (if it is older software) ?

	BIND 4 sent REFUSED when it didn't serve the zone, NOTAUTH
	hadn't been invented.  This was before there was any acl's
	at all.  REFUSED was documented in RFC 1034.  This is not
	asking for something new.  All clients handle having a error
	RCODE returned.  I'm asking for all servers to generate a
	error RCODE when they don't want to send the zone.

"When the poll shows that the zone has changed, then the secondary server
must request a zone transfer via an AXFR request for the zone.  The AXFR
may cause an error, such as refused, but normally is answered by a
sequence of response messages."

	Is there anything unclear about a error being supposed to
	be sent?

> been no complaints about interoperability.

	We are not talking about a successful zone transfer.  We
	are talking about the initial response to a AXFR query.

	Header + the question section which identifies the zone
	when TSIG and EDNS are not involved.  A couple more bytes
	when TSIG and/or EDNS are in use.

	Mark

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 23 Jan 2008 09:42:59 +0100

Mark Andrews wrote:
|> Mark Andrews wrote:
|> | 	I want a useful diagnostic to be sent.
| 	BIND 4 sent REFUSED when it didn't serve the zone, NOTAUTH
| 	hadn't been invented.  This was before there was any acl's
| 	at all.  REFUSED was documented in RFC 1034.  This is not
| 	asking for something new.  All clients handle having a error
| 	RCODE returned.  I'm asking for all servers to generate a
| 	error RCODE when they don't want to send the zone.

NSD also sends REFUSED if it doesn't have the zone.

| 	Is there anything unclear about a error being supposed to
| 	be sent?

We could print it in a bigger font size :-)
Are you implying that deployed implementations of AXFR do not send such
an error? Mandating such an error to be sent; although it makes a lot of
sense, does invalidate those existing implementations.

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Jan 2008 19:55:08 +1100

> an error?

	Yes.

> Mandating such an error to be sent; although it makes a lot of

> iD8DBQFHlv4TkDLqNwOhpPgRAq7LAJ0b3Bj3uVvO01F0EL6yWjwkjfNLIwCgmpIf
> VWqXu427XkVK3qB9pueXqFY=
> =HtsS

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 23 Jan 2008 12:57:14 -0500

David please do the magic to have this change made.

         Olafur (returning from vacation and finding 500 messages in
moderation queue, for once there where more messages returned due to bad
addresses than spam due to high volume of messages on the list)

---

From: Dean Anderson <[email-masked]>
Date: Wed, 23 Jan 2008 13:26:25 -0500 (EST)

Important questions are:

   How did these IANA documents get changed?

   Why wasn't anyone notified of these changes when the happened?

   What other questionable changes have happened to IANA documents?

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Jan 2008 11:35:19 -0800

Dean,

>    How did these IANA documents get changed?

It isn't clear to me that they did, at least since I've been at IANA -- the
last change to the dns-header-flags registry was done on 9 June 2005 (as a
result of RFC 4035).

>    Why wasn't anyone notified of these changes when the happened?

If a change did occur, IANA normally only notifies the requester of the
change.

>    What other questionable changes have happened to IANA documents?

If I told you, it would expose IANA's nefarious plans for global domination
through subtle changes in the IANA registries and then I'd have to kill you.

More seriously, if there are 'questionable' changes, we are unaware of them.
Changes to registries are generally defined within IANA consideration
sections of RFCs (to be) and current procedure is to ask the requesters to
verify the changes to the registries are correct both before and after the
change. However, stuff (as they say) happens, and occasionally typos (etc.)
are made in registries that aren't caught before they're published.  When
we're notified of such issues, or if a registry needs to be clarified for
whatever reason, we'll go and make the changes without much drama.

Regards,
-drc

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 23 Jan 2008 15:27:26 -0500

According to the Internet Way-Back Machine (web.archive.org), there was
no IANA registry of DNS header flags as of 12/1/1998 (only
"dns-parameters", allocating class, type, opcode and rcode values):

http://web.archive.org/web/19981201080713/http://www.isi.edu/in-notes/iana/assignments/dns-parameters

On May 1, 2001, the registry moved from ISI to IANA.org.

The dns-header-flags registry first appears, as a separate document, in
11/2001 with a mod date of 10/16/2001, lagging by a few years the new
allocation of header flags since RFC 1035, when 2 bits from the former
3-bit Z field were allocated by RFC 2535 (3/1999).  Bit 9 looked in
10/2001 exactly as it does today.  So, this wasn't a change.  It just was.

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Dean Anderson <[email-masked]>
Date: Wed, 23 Jan 2008 18:48:58 -0500 (EST)

> last change to the dns-header-flags registry was done on 9 June 2005 (as a

Hmm. A line became wrong, as Ed noted. Was it always wrong? Are there 
archives? Is there version control? 

> If a change did occur, IANA normally only notifies the requester of the

Perhaps IANA should notify more contacts of changes to IANA documents.  
I'd like to be on that notification list.

> More seriously, if there are 'questionable' changes, we are unaware of them.

I suppose the question should be restated: 

  What controls does IANA have in place to prevent unauthorized changes?

Most institutions have audit trails to discover and prevent unauthorized
changes to important "stuff".

> whatever reason, we'll go and make the changes without much drama.

Lets try not to have "stuff happen" to important "stuff"

		--Dean

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Jan 2008 16:44:28 -0800

[It has been suggested that I ³not feed the trolls² and that this isn't
really relevant to the EVIL 'BIND COMPANY' (which appears to be growing to
encompass the remaining free world) PLOT known as "AXFR Clarify", so this
will be my last response on this thread.  I¹ve been responding to give
people an idea of how things work at IANA. Feel free to delete this message
if this isn¹t of interest]

Dean,

> archives? Is there version control?

It just may be Ed made a bit of a booboo.  As Josh pointed out, the registry
appears to always have been the way it is.  Whether it is wrong is likely a
value judgment.  Yes, there are internal archives and version control.

> I'd like to be on that notification list.

We don't currently have a mechanism in place for this. If others think it
useful, I'll ask to have this discussed with the IESG to see if they feel it
appropriate (and if so, what priority they'd place on it).

> changes to important "stuff".

Audit trails, of course, do not prevent unauthorized changes.  All changes
(and proposed changes) are tracked via a ticketing system.  Modification of
the IANA registries is limited to authorized personnel (IANA staff) and are
version controlled.  We're looking into PGP/GPG signing the registries, but
other priorities have consumed our limited resources.

> Lets try not to have "stuff happen" to important "stuff"

So kind of you to make the suggestion. We'll try to keep it in mind.

Regards,
-drc

---

From: Dean Anderson <[email-masked]>
Date: Wed, 23 Jan 2008 23:04:33 -0500 (EST)

> if this isn¹t of interest]

First, IANA is a US government function. Its records are government
records. Altering government records without authorization is felony.  
As a custodian of government records, ICANN has some serious
responsibilities for their care.  I think Mr. Conrad should take those
responsibilities much more seriously than it seems he does.  It seems
highly improper for Mr. Conrad, under official ICANN and IANA
(government) colors, to engage in exaggerations such as the above which
ridicule and defame and are inappropriate to the IETF.

Second, the misconduct alleged on the AXFR-clarify draft from 2000 to
2003 happened while David Conrad was the CEO of Nomimum, and shared an
office with Paul Vixie. The original AXFR-clarify draft was submitted by
a Nominum employee. The false assurances that no wire changes were made
by a Nomimum employee. People relied on these false assurances.

During this period (1996-2002), Paul Vixie misled the internet community
that MAPS was a non-profit enterprise. Sharing an office with Vixie,
Conrad must have been aware of the true facts about MAPS status, but
kept silent.

As I already noted in my previous message, Vixie was a shareholder and
Board Member of a commercial bulk emailer known as Whitehat
(1998-2002+). But this wasn't widely known at the time. Sharing an
office with Vixie, it seems hard to believe that Conrad wasn't aware of
that. Conrad still kept silent.

Also during this period (2000-2001), Paul Vixie was a defendant in
Exactis v.  MAPS, which cited charges of Tortious Interference with
Contract, Tortious Interference with Prospective Business Relations,
violation of the Colorado Consumer Protection Act, Intentional and
Negligent Misrepresentation and Extortion, violation of the Colorado
Communications Privacy Act, violation of the Colorado Organized Crime
Control Act, violation of the Sherman Antitrust Act, violation of the
Colorado Antitrust act. A Temporary Restraining Order (TRO) was
obtained.  Vixie and MAPS attempts to have the case dismissed failed,
and MAPS settled out of Court. MAPS no longer blocks Exactis.

A TRO is a fact. A TRO is citable in subsequent litigation.  A previous
TRO helps establish that similar facts are sufficient to establish
similar claims.

A TRO is a decision that the facts cited, if true, are sufficient to
establish the claims made and that the plaintiff can prevail absent
false facts or some defense. MAPS and Vixie tried vigorously to have the
case dismissed, using defenses they also cited in their reply. Those
efforts to have the case dismiss failed. Those are facts, too.

Exactis V. MAPS is basically a RICO case.  The statute of limitations of
RICO is 10 years.  Anyone who is injured by the RICO enterprise can
bring a RICO case. Indeed, I think I have been injured by this
enterprise.  In 1998, I was threatened on NANOG with physical harm in
connection with this RICO enterprise. This threat is a violation of the
Hobbs Act (a RICO predicate act).  Mr. Conrad was a member of NANOG at
that time, but he kept silent.  More injury from this enterprise has
happened since 1998, some of it in connection with the AXFR-clarify
scheme, even. When a non-profit is involved, economic harm can be the
unlawful object of a RICO enterprise, in addition to economic profit.

So, during the same time as events of Exactis V. MAPS, during the period
of the AXFR-clarify events (2000-2003), Mr. Conrad was in the same
office as Paul Vixie, overseeing in the AXFR-clarify scheme involving
false statements (the fact that there were no wire changes in
AXFR-clarify) that people relied on (the members of the IETF WG).  
Nominum, ISC and UltraDNS were the benefactors of that scheme.

Without commenting on whether any laws were broken, there are clearly
ethical problems and serious misconduct of IETF officials and other IETF
members, including Mr. Conrad.

> value judgment.  Yes, there are internal archives and version control.

At least, there is version control. I suppose that's a start. But then
in that case, why weren't the dates of changes clear to you in your
first response? 

> appropriate (and if so, what priority they'd place on it).

Good. Though, it seems ICANN could do this without input from their IETF
technical consultant. It seems to be an administrative matter, more than
a technical matter. I think consultation with the Department of Commerce
would also be appropriate. But of course, speaking for myself, members
of the IETF will offer technical assistance as necessary.

> Audit trails, of course, do not prevent unauthorized changes.  

Audit trails deter unauthorized changes when employees understand there
is an audit trail, and the audit trail can't be altered by the
employees.

> All changes (and proposed changes) are tracked via a ticketing system.  
> Modification of the IANA registries is limited to authorized personnel
> (IANA staff) and are version controlled.  We're looking into PGP/GPG
> signing the registries, but other priorities have consumed our limited
> resources.

This all sounds good.

> So kind of you to make the suggestion. We'll try to keep it in mind.

I'm not very assured you will when you make the excuse that "stuff
happens".  I'm not at all convinced you are the right person for that 
job.

		--Dean

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Jan 2008 05:41:51 +0000

> > will be my last response on this thread.

ditto, and for similar reasons.

> >                                            I¹ve been responding to give

let me recommend in advance that everyone delete this message w/o reading it,
i'm sure you all have cats and that shampooing those would be a better use of
your time than reading any further in this thread.  all i'm about to do is
expand on what i meant when i said "this is all rubbish, and old rubbish at
that."  and i ought to know better.


> by a Nomimum employee. People relied on these false assurances.

the nominum employee you're referring to has such a strong personal ethic and
reputation that it is hard to imagine him parroting anybody else's ideas or
writing anything in an internet-draft that he didn't personally believe in.

> Conrad must have been aware of the true facts about MAPS status, but

maps was a nonprofit enterprise.  it was never a federally recognized 501c3,
due to various administrative errors i made when i ran it, but when david
shared an office with me (oh such halcyon days of yore) he never had any
reason to believe that maps wasn't just a nonprofit drowning in lawsuits.

> As I already noted in my previous message, Vixie was a shareholder and Board
> Member of a commercial bulk emailer known as Whitehat (1998-2002+).  But
> this wasn't widely known at the time. Sharing an office with Vixie, it seems
> hard to believe that Conrad wasn't aware of that. Conrad still kept silent.

to the extent that david knew anything about whitehat, he knew what was in
the press releases, which was that a bunch of staunch anti-spammers had got
together to prove that commercial bulk e-mail could be done responsibly and
without abuse and also profitably.  (which *was* widely known at the time.)

> Also during this period (2000-2001), Paul Vixie was a defendant in Exactis
> v.  MAPS, ... A Temporary Restraining Order (TRO) was obtained.  Vixie and
> MAPS attempts to have the case dismissed failed, and MAPS settled out of
> Court. MAPS no longer blocks Exactis.

anybody can sue anybody over anything.  tro's are often granted on the basis
of "let's restore the status quo since no harm would come to the restrained
party and the real facts can be established at trial."  everybody who is sued
attempts to get every case dismissed, always, every time, no exceptions.  most
cases that are settled out of court are settled due to skyrocketing legal
costs and lack of will/resource/incentive to continue.  MAPS no longer exists,
and noting that no settlement agreement by MAPS would be binding on its
successor, that successor could blackhole exactis if they had any reason to.
however, exactis isn't sending unsolicited bulk e-mail, so there's no reason
for them to be blackholed as far as i know.

> A TRO is a fact. A TRO is citable in subsequent litigation.  A previous TRO
> helps establish that similar facts are sufficient to establish similar
> claims.

the basis of a tro is not judged as fact, only the issuance, which is known
to be based on allegations that may or may not have been repeated at trial
and that may or may not have swayed a judgement if/when presented at trial.

i am not particularly worried about your repeated misstatements of the law
since "proof by vigorous reassertion" is a well known form of crackpottery.
anyone who hears your repeated misstatements about the law either knows from
having been sued that it doesn't really work like you say, or knows enough
to consult an attorney if they are sued, rather than trusting your opinions.

> establish the claims made and that the plaintiff can prevail absent false
> facts or some defense.

no.  a tro can also be granted for the weaker cause of "the defendant would
not be injured by restoring the status quo, and the cause of action brought
by the plaintiff appears to refer to some actual laws, so we'll sort it out
at trial."

> MAPS and Vixie tried vigorously to have the case dismissed, using defenses
> they also cited in their reply.  Those efforts to have the case dismiss
> failed.  Those are facts, too.

no.  i find several distortions in the above statements.  for example, every
defendant in every case always seeks to have the case dismissed.  they will
use some defenses that will also be used at trial, but not necessarily all
of them, and it's not a given that every response used when asking for
dismissal will also be used at trial.  you did say one true thing, the case
was not dismissed.  that is the only *fact* in the above-quoted text.

> RICO is 10 years.  Anyone who is injured by the RICO enterprise can bring a
> RICO case.  Indeed, I think I have been injured by this enterprise.  In
> 1998, I was threatened on NANOG with physical harm in connection with this
> RICO enterprise.  This threat is a violation of the Hobbs Act (a RICO
> predicate act).

if some childish person subscribed to the nanog mailing list made a childish
statement threatening you with bodily injury because they could no longer
tolerate the vigorous reassertion of your various proofs, then that reflects
poorly on the threatener, but not on nanog for running an open mailing list,
nor on others subscribed to that open mailing list.

> Mr. Conrad was a member of NANOG at that time, but he kept silent.

nanog does not issue membership cards, and there is no membership agreement.
to be a "member of nanog" is meaningless.  someone can be a member of the
nanog mailing list, and someone can pay an entrance fee to a nanog meeting,
and someone can be invited to speak at nanog meetings.  but it's not a
membership society, and david cannot be held responsible for the childish
threats you say were made against you by someone else on the nanog mailing
list.

> More injury from this enterprise has happened since 1998, some of it in
> connection with the AXFR-clarify scheme, even.  When a non-profit is
> involved, economic harm can be the unlawful object of a RICO enterprise, in
> addition to economic profit.

i'm curious.  i wonder if you might indulge me on a framing question.  when i
found out that BIND4 and some early BIND8 servers were unwilling to accept
perfectly valid AXFR's from the Microsoft NT 3.51 Resource Kit due to stupid
bugs in BIND, and i fixed those bugs so that BIND would do what the RFCs
said and so that Microsoft's customers would stop complaining to Microsoft,
what role do you think all this played in the "AXFR-clarify scheme"?  do you
think i was misdirecting folks, trying to gain trust and credibility, before
clamping down on the industry with my iron claw?  (i really do want to know.)

> So, during the same time as events of Exactis V. MAPS, during the period of
> the AXFR-clarify events (2000-2003), ...

you have not even tried to show any connection between the exactis/maps law-
suit and the axfr-clarify issue.  is that an oversight, or are you honestly
unable to imagine some way in which the AXFR-clarify scheme and the lawsuit
are connected?  (i think i remember you saying, years ago, that there was a
connection, so, i'm assuming that this is an oversight on your part.)

> ... Mr. Conrad was in the same office as Paul Vixie, overseeing in the
> AXFR-clarify scheme involving false statements (the fact that there were no
> wire changes in AXFR-clarify) that people relied on (the members of the IETF
> WG).  Nominum, ISC and UltraDNS were the benefactors of that scheme.

so, the connection between the AXFR-clarify scheme and the lawsuit is that
david benefitted from the one while observing me closely during the other?

> members, including Mr. Conrad.

you keep using that word: "clearly."  i do not think it means what you think
it means.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Jan 2008 10:28:24 +0100

On Wed, Jan 23, 2008 at 11:35:19AM -0800,
 David Conrad <[email-masked]> wrote 
 a message of 38 lines which said:

> If I told you, it would expose IANA's nefarious plans for global
> domination through subtle changes in the IANA registries and then
> I'd have to kill you.

:-)

To go back to practical matters, this is a good opportunity to remind
IANA that a way to easily track the changes on IANA registries would
be most welcome.

The very minimum would be a syndication feed of the registries (using
RFC 4287) plus one feed one for every registry.

Ideally, we would need a complete time-travelling machine (may be
something as simple as a VCS + ViewVC) to access the IANA registries
at any time in the past.

Do not tell me you are working on it, I know. This is just a reminder
that users want it. I can put it on paper with a word from our CEO if
it helps you to get budget from ICANN.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Jan 2008 09:09:39 -0500

>IANA that a way to easily track the changes on IANA registries would

This is akin to the discussion on some other list about delegation 
checking.  The connection is that at some basic level, all registries 
are the same.  They associate identifiers with meanings.  Whether it 
is domain names with information about the network, address ranges 
with responsible parties, license plates with automobile owners, or 
protocol parameter values with semantics, there is a common thread.

For that reason I think it is unrealistic to desire IANA track 
changes - interpreting this as IANA ought to make sure that the 
registrations are up to date, just as it has become unrealistic for 
large domain name registries to track lameness (there's a whole 
thread on that, if you disagree with my assertion here, realize I am 
stating this as justification for why I believe IANA checking is 
unrealistic not trying to flog the issue once more here).  As with 
other registries, it is up to the registrants (wrt to IANA's DNS 
ones, mostly the IETF) to keep the data up to date.  Which is what we 
are doing now.

Perhaps my saying there was a mistake at IANA was said in the wrong 
way.  Note I put the word in quotes.  It wasn't a mistake IANA 
performed but some there along the way it seems like some thing got 
dropped along the way.

>RFC 4287) plus one feed one for every registry.

Seriously, as an aggregate (I suppose) there are frequent changes to 
IANA registries but if you filter down to the registries you care 
about (as a DNS'er or as a SMTP'er, etc.) it isn't that often and for 
the most part your life wouldn't change if there was a change.

Do you really want a syndicated feed of all the changes?  I can't 
imagine anyone having enough time in the day to care to check it.

>something as simple as a VCS + ViewVC) to access the IANA registries

The only registries that maintain a history of registrations are the 
ones that track owners of houses and land. My house address' previous 
owners are always known (that title search thing I paid for at 
closing).  But I don't know of an Internet registry that maintains a 
history - at least on-line - and DNS, WhoIs, EPP, etc., have never 
given a thought to journalling.

>it helps you to get budget from ICANN.

What I'm writing pertains more to IANA than DNS, but I have spent a 
considerable amount of time to see that the IANA registries for DNS 
are up to date.  For the most part they are.  I have been frustrated 
at times with getting some seemingly obvious fixes in at times, not 
always the fault of IANA's bureaucracy.  But progress is made at 
times.  This isn't a high priority personal crusade for me.

I'm acting as an actor of a DNS protocol registry registrant, the 
IETF, to get our corner up to date.  I'm not trying to criticize 
IANA, expand it's mission, or blame it for social ills.  I'd just 
like to clean up what is there so that the next generation of DNS 
implementers will have a set of accurate registries as a byproduct of 
trying to get the AXFR clarify draft done.

---

From: David Conrad <[email-masked]>
Date: Thu, 24 Jan 2008 07:58:28 -0800

Stephane,

> IANA that a way to easily track the changes on IANA registries would

Understood.

> it helps you to get budget from ICANN.

I appreciate the reminder.  Right now, IANA staff have been focusing on
getting the long delayed new web site pushed out (REAL soon now).  We've
also been moving forward on the XMLization effort with the help of Marc
Blanchet and Viagenie.  And publishing stats (click the IANA link on the
left of <http://forms.icann.org/idashboard/public/view.php>).  And meeting
the IETF SLAs.  And finishing up the root zone management automation. And
getting a demonstration/experimental root zone (along with the zones IANA is
responsible for) signed (zone transfer open at ns.iana.org and see
<https://ns.iana.org/dnssec/status.html>).  And, and, and (:-)).  Publishing
change tracking info via some mechanism is on IANA's (long) list of things
to do, the only question is what the priority should be.  With that said,
however, I never say no to offers of help explaining IANA's budgetary
needs... :-)

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 24 Jan 2008 08:12:31 -0800

Ed,

On 1/24/08 6:09 AM, "Edward Lewis" <[email-masked]> wrote:
> But I don't know of an Internet registry that maintains a

Since we have the registries in version control, we actually do have a
journal so that's not a big deal.  Back when I was IANA GM, I had put on our
'to do' list publishing the diffs, etc., but never got around to figuring
out the best way to do it.  I would agree in that I wouldn't imagine there
would be a lot people interested in watching all of the O(100)
changes/month, but my thought with a feed is folks could automate updating
their copies of the registries.  I figure a viewer would be useful, if only
to have an easy way to figure out who to blame for a mistake (:-)).

> are up to date.

A separate issue and I (for one) would like to publicly thank you for the
efforts.  So thanks!

Regards,
-drc

---

From: Dean Anderson <[email-masked]>
Date: Thu, 24 Jan 2008 15:39:05 -0500 (EST)

I'll try to limit comments to AXFR-clarify and to the roles of Nomimum,
ISC, and Ultradns, and IETF staff.  There are some other acts by Conrad,
Vixie and others, but which were not related to AXFR-clarify. These are
acts will not be cited here.

On Thu, 24 Jan 2008, Paul Vixie wrote:

> the nominum employee you're referring to has such a strong personal
> ethic and reputation that it is hard to imagine him parroting anybody
> else's ideas or writing anything in an internet-draft that he didn't
> personally believe in.

A character reference of "Strong personal ethic" doesn't mean that one
hasn't engaged in wrongdoing. However, no one has accused Gustafsson of
"parroting anyone else's ideas". Gustafsson is accountable for the
AXFR-clarify statements; He's a participant and participation is
evidence of agreement to advance the enterprise.  And Conrad is
Gustafsson's boss at Nomimum.

> > During this period (1996-2002), Paul Vixie misled the internet
> > community that MAPS was a non-profit enterprise. Sharing an office
> > with Vixie, Conrad must have been aware of the true facts about MAPS
> > status, but kept silent.
> 
> maps was a nonprofit enterprise.  it was never a federally recognized
> 501c3, due to various administrative errors i made when i ran it, but
> when david shared an office with me (oh such halcyon days of yore) he
> never had any reason to believe that maps wasn't just a nonprofit
> drowning in lawsuits.

Excuses of that sort are meaningless. MAPS was _never_ a nonprofit; And
instead doing the right thing of revealing the true status of MAPS, or
completing the non-profit status, or revealing that non-profit status
was denied, in 2002 MAPS announced that MAPS was for-profit, and
Vixie/Rand took the money raised as profit.  Assuming Vixie made errors
on getting the non-profit tax status setup, good faith in that instance
would have been to either 1) reveal that fact, 2) complete the tax
status or 3) to transfer MAPS assets to another non-profit. Bad faith is
to take the money raised as profit, which is exactly what Vixie and Rand
did.

[Snip--legalese and excuses for facts asserted regarding Exactis V.  
MAPS, though somewhat true in general, but not true of Exactis V. MAPS
specifically, will be ignored.]

> nanog does not issue membership cards, and there is no membership
> agreement.  to be a "member of nanog" is meaningless.  someone can be
> a member of the nanog mailing list, and someone can pay an entrance
> fee to a nanog meeting, and someone can be invited to speak at nanog
> meetings.  but it's not a membership society,

Conrad is a member of an identifiable group, called NANOG.  Membership
cards are never necessary. In every case (legal or illegal, incorporated
or unincorporated), participation demonstrates membership. Conrad
participated in NANOG.

> and david cannot be held responsible for the childish threats you say
> were made against you by someone else on the nanog mailing list.

I do not consider threats of physical violence of the sort "let's hope
Dean attends a meeting so we can get him in an alley" to be merely
"childish".  The threat was made by Jeremy Porter, a long time (by then)
participant in NANOG.  The threat was made because I asserted
(correctly) that the ECPA applied to ISPs.

Possibly Conrad cannot be held legally liable for Porter's act,
directly. However, silence in such a case is shameful and unethical.

The threats did further the RICO enterprise of which Conrad was a part.  
So indirectly, Conrad is responsible, through responsibility for the
RICO enterprise.

> > More injury from this enterprise has happened since 1998, some of
> > itin connection with the AXFR-clarify scheme, even.  When a
> > non-profit is involved, economic harm can be the unlawful object of
> > a RICO enterprise, in addition to economic profit.
> 
> i'm curious.  i wonder if you might indulge me on a framing question.  
> when i found out that BIND4 and some early BIND8 servers were
> unwilling to accept perfectly valid AXFR's from the Microsoft NT 3.51
> Resource Kit due to stupid bugs in BIND, and i fixed those bugs so
> that BIND would do what the RFCs said and so that Microsoft's
> customers would stop complaining to Microsoft, what role do you think
> all this played in the "AXFR-clarify scheme"?  do you think i was
> misdirecting folks, trying to gain trust and credibility, before

I have never used the phrase "clamping down on the industry with my iron
claw".  This incident with Microsoft is not part of the AXFR-clarify
scheme, and was not discussed on the namedroppers list. I'm not aware of
any false statements in that incident.  That you didn't do a bad thing
once is no proof you've never done a bad thing.

The facts I cite in the AXFR-clarify scheme are the false statements
that were made to the WG by Nomimum that others relied on. That is, that
there were no wire changes to the AXFR protocol in the AXFR-clarify
draft.  ISC and Vixie made changes to BIND which would profit from the
scheme. And, again, for the second time, Vixie and Conrad were in the
same room for something bad, this time the AXFR-clarify scheme. Conrad
and Vixie both stood to benefit from the scheme.

I also cite the abuses of IETF policy by then WG Chair Randy Bush in
deleting messages from Bernstein that revealed the false statements. I
also cite Bush's publication of Bernstein's subscription address,
enabling forged unsubscriptions. That's two acts;  Bush is also
"associated-in-fact with the RICO enterprise.

The blind eye that then IETF Chair Harald Alvestrand and the IESG turned
to the issue shows "Willfull blindness" to wrongdoing that furthers the
RICO enterprise.

> you have not even tried to show any connection between the
> exactis/maps law- suit and the axfr-clarify issue.  is that an
> oversight, or are you honestly unable to imagine some way in which the
> AXFR-clarify scheme and the lawsuit are connected?  (i think i
> remember you saying, years ago, that there was a connection, so, i'm
> assuming that this is an oversight on your part.)

No oversight on my part. You just didn't read closely. I said the RICO
enterprise consists of and benefits Nominum, ISC, UltraDNS, at least.
[there are definitely others, but no need for all that here] The RICO
enterprise can have multiple schemes and not each person needs to
participate in each scheme. A person (or any entity that can hold
property) only needs to participate in two or more acts furthering the
enterprise.

To violate just the conspiracy part of RICO, all that is needed is
agreement (for an unperformed act) or just one act which furthers a RICO
enterprise. An act implies agreement.  Two or more acts makes one a part
of the RICO enterprise in contrast with a conspirator who isn't part of
the RICO enterprise, but has only agreed to help it.

Conrad is in the same room with other schemes, and he participated in
scheme furthering the RICO enterprise.  

I have some more acts by Mr. Conrad, but I won't detail them here.

> david benefitted from the one while observing me closely during the other?

No, The connection is that there is only one RICO enterprise engaged in
multiple schemes.

> you keep using that word: "clearly."  i do not think it means what you think

And I thought we would disagree on what "ethical" means. But "clearly"  
is just a filler word.  It should always be deleted on edits.

Perhaps this is better:

Without commenting on whether any laws were broken, there are ethical
problems and serious misconduct of IETF officials and other IETF
members, including Mr. Conrad.

		--Dean