Subject: Fw: I-D ACTION:draft-iab-dns-choices-00.txt

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 13 Oct 2004 09:26:44 +0200

This is relevant to this group.

	Title		: Design Choices When Expanding DNS
	Author(s)	: P. Faltstrom, R. Austein
	Filename	: draft-iab-dns-choices-00.txt
	Pages		: 12
	Date		: 2004-10-22
	
This note discusses how to extend the DNS with new data for a new
   application.  DNS extension discussion too often circulate around
   reuse of the TXT record.  This document lists different mechanisms to
   accomplish the extension to DNS, and comes to the conclusion use of a
   new RR Type is the best solution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iab-dns-choices-00.txt

--Olaf

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 10:20:59 -0700

> you are wrong.  speaking for f-root, if we had to build a 
> protocol control
> block for each of the 5000 to 10000 queries that came in 
> every second, and
> exchange packets between our state machine and remote state 
> machine, before
> finally sending the response and reclaiming the state-memory, 
> we'd need a
> lot more hardware than we have today.  it's not the bytes, or 
> the packets--
> those we can provision easily.  it's the state-memory 
> occupancy time that
> would dominate.

The problem is not so much building a protocol control block
as routing. As soon as you have to maintain state you have to
make sure that all the requests that require access to that
state occur in the same memory partition.

This is where you start to see somewhat subtle performance 
issues on multi-way CPU boxes. Memory shared for read is easy,
the state control blocks have to be R/W shared and you cache 
goes sour.

> > TCP has other advantages. Commercial load balancing 
> solutions in large
> > server farms are designed for TCP, not UDP. The three way 
> handshake in
> > TCP enables a potent defense against denial of service attacks, and
> > makes some spoofing attacks much harder. In fact, this group should
> > probably reconsider its stance versus TCP.

There is a reason that commercial loadbalancing is designed for TCP, that is
where you need it! If you do not have to deal with state then you
can deal with routing in a much simpler and more brutal fashion.

> why stop there?  xml has a lot of advantages -- maybe dns should stop
> using binary packet formats and just use html.  this would make
> internationalization easier, for one thing.  for that matter, 
> why use a
> dedicated protocol for dns when we could use sunrpc, or ldap, or
> SMB/CIFS, or SQL?  (note to the humour-challenged, this is Sarcasm on
> my part.)

Binary coded XML is a very good idea, it can be at least as efficient as the
DNS encoding.

Web Services require a policy layer. There are two routes forward from here.
One is to try to use UDDI and watch that become the naming infrastructure.
The second is to extend the existing DNS since the policy layer is no more
complex than existing SRV and NAPTR schemes.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 12:42:37 -0700

> The point is that there's no need for that - if we know what 
> names exist
> (which seems to be the case "people" actually want) then it's trivial
> to pre-process the zone file and include whatever records 
> that are wanted.

Robert,

We are in violent agreement here.

I believe that there is not, nor ever has been a requirement for wildcards
to support the prefix modes. The only requirement in this regard that has
been raised is satisfied by MACROS which do not require any change to the
infrastructure.

If we keep in mind the wildcard/macros distinction everything starts to work
out fine.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 16:41:28 -0700

> nothing so grand.  he originally chose TXT because he didn't 
> know any better,
> and by the time he got any help, there was already both code 
> and data deployed
> that made TXT hard to change.  only microsoft could have 
> forced a mind-change
> or format-change, and they (microsoft) blew their chance due 
> to IPR policies.

This is factually inaccurate, SPF acknowledged the RMX draft
from Hadmut, the use of TXT was an entirely deliberate design
decision.

Do not confuse your advice being rejected and the advice
being unheard. In this case the deployment issues with new
records were understood and discussed at length.

Microsoft was planning to put XML records in the DNS and they
were planning to use a prefixed TXT record to do so.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 17:43:11 -0700

> >>>>> "Hallam-Baker," == Hallam-Baker, Phillip 
> <[email-masked]> writes:
>     >> Allowing * to expand in the middle creates large search spaces.
> 
>     Hallam-Baker> Not at all, since we are talking about macros not
>     Hallam-Baker> wildcards there is no reason why this has to be
>     Hallam-Baker> standardized and there is no reason why servers need
>     Hallam-Baker> to provide unbounded matches.
> 
>   So, you don't mind if your secondary servers answer differently than
> your primaries?

Or the primary can expand out the macros and generate the closures.
Logically the only match that is needed for midpoint matches is
for nodes that exist. 

Nodes that existeth not are not going to be needing services to
have policy published. About all that can be said for them is that
they existeth not.

>   Or do we have to run the same software everywhere?
>   I like diversity.

I am quite willing to sacrifice diversity in order to avoid the
need to persuade this group to take action.

If people beleive that diversity is desirable then its a simple
enough problem to specify what has to be done to support it.

Regardless of whether _MARID or _MASS comes into existence there
are already plenty of SRV entry points and these are going to 
proliferate further and macros would really be quite handy.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Oct 2004 09:00:42 -0400

In May I did a presentation based on an earlier version of this 
document to an audience that wasn't wholly receptive.  The topics of 
contention are nicely covered in Christian's message with one 
exception.

The audience did not raise the issues with the TCP arguments.  But 
the audience did also refuse to acknowledge the problems with name 
prefixes given the success of srv records and the poor track record 
in defining new RR types.

At 12:33 -0400 10/17/04, Christian Huitema wrote:
...
>Throughout the document, there are claims that having large records or
>large record sets increases the risk of using TCP, which is true, and
>that using TCP would be a catastrophe, which is dubious...

>The main argument against the name prefix solution is its
>incompatibility with wild cards. Without going in a deep analysis of
>wild card usage, I note that we have some experience with using name
>prefixes for SRV records, and that the mail logs are not full of
>complaints about incompatibility between SRV and wild cards...

>The document does not discuss the role of the IETF in the record type
>creation process...

>-- Christian Huitema

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

"Now under neu management"

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 23 Oct 2004 18:14:34 -0700

> > So you are referring to a proposal that isn't being made
> > rather than the proposal that has been made.
> > 
> > So now we have that sorted out we can take it that your
> > objections are withdrawn or can at any rate be ignored.
> 
> 	No.  Even with a prefix you still have the sub-type problem.
> 
> 	With a prefix you have the problem that you can't implement
> 	this with every possible mta name. 

What on earth do you mean here? If you mean that it uses 
underscores its irrelevant now, the underscore is unusable 
for A record names due to the infrastructure.

Grow up.

>    You have the problem that
> 	it doesn't work with wildcards (your own admission). 

No, I said that the wildcard support does not work according
to the requirements for any extension mechanism, including
new RRs. You have to fix the servers with a macro capability 
either way.

Compared to the fact that 50% of the DNS infrastructure does 
not support new RRs in any shape or form these problems are 
minor and irrelevant.

> 	You started with the premise that adding a new type would
> 	take a long time and looked for a solution that didn't
> 	involve a new type.  I think I have proved that your initial
> 	premise was based on FUD.  

No, you did nothing of the sort.

>  It can be also demonstated that
> 	a new type is a technically superior solution to sub-type /
> 	prefix.

Assertion and restatement of assertion does not constitute
an argument.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 25 Oct 2004 13:55:27 -0700

> From: Ben Laurie [mailto:[email-masked]]

> Hallam-Baker, Phillip wrote:
> 
> > If you are suggesting kicking away crutches from people who need
> > them then you really are not going to be much help. Outside MIT
> > LCS/AI and the IETF the idea of making a specification into
> > an intelligence test is not very popular.
> 
> Have you ever read the X.509 or ASN.1 specs?

My theory is that the party that wrote the ASN.1 spec wanted
to stop the use of civilian cryptography, thats why the name
is 1.NSA backwards.