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: Fri, 15 Oct 2004 12:38:14 -0700

The claims made in section 3.2 (below) do not accurately reflect 
the situation with wildcards.

The conclusion of MARID was that wildcards are actually irrelevant
as specified since they do not in fact work for any of the use cases.

The DNS really needs at least two wildcard types,

*   The current wildcard, if www.example.com exists the
    wildcard *.example.com will NOT match for ANY record.

*?  The wildcard people think they have and mostly want,
    TXT/*.example.com will match iff www.example.com exists
    but has no other TXT record.

As a matter of history quite a few DNS servers have actually
implemented the nonstandard *? wildcard which is one reason
for the confusion.

The use cases given in the MARID case did not work, in particular
is was not possible to construct a wildcard to say 'this machine
does not send mail' since *.example.com will not match
phill.example.com if there is ANY record for the node. The
use case is real but it cannot be met without *? style wildcards.

A wildcard properly understood is merely a notational convention
that is used in the configuration of the server. In the absence
of DNSSEC there is no real interoperability issue.

Even _WITH_ DNSSEC a server can implement *? wildcards 
synthetically, it just means enumerating the additional 
records for the nodes.

To make the prefix scheme work completely all that is needed
is to allow for midpoint wildcards, i.e. match on
_prefix.*.example.com and _prefix.*?.example.com

Fixing the NSEC/NXT record to meet these needs is not at all
difficult. 

If these changes are deployed then the RR type becomes merely
a syntax container and an infinite (OK 2^124) number of semantics
may be bound thereto by defining new prefixes. It is now
possible to deploy new RR semantics without the need to
upgrade ANY infrastructure whatsoever, everything flows
through the existing infrastructure. The only parties that
need to change are those who choose to use wildcards and even
for them the software change is a one time affair.

The difference in implementation cost is vast. Even with 
DNSEXT new RRs will require new software for any party deploying 
them. In the real world 'stick hex values in the config file'
is just not a viable solution. 

The RR architecture conflates syntax and semantics. The view
of RR as being a syntax container whose semantics are defined
by means of a prefix has already been established by SRV and 
NAPTR.

Section 3.5 Fails to tell the reader that a majority of deployed
DNS servers do not in fact provide support for new DNS records.
The claims that Windows platform DNS servers provide support
neglect to mention the lack of support for creitical features
such as the ability to remember settings after a restart and
the ability to do zone transfers.

The draft admits in section 4 that the purpose of the controls
is political and not technical. As such the draft is naive,
in order to maintain control it places a ridiculous and 
unnecessary burden on proposals. This only encourages parties
with an alternative view of how the DNS should work to seek
other venues and receive endorsement and approval in those 
venues. The W3C has already defined SRV entry points for 
protocols on an ad hoc basis.

The statement made in section 5 that recent surveys show that
deplyoment of a new RR are practical is factually incorrect.
The survey if it is the one I beleive is refered to (no citations
are given) actually states the reverse

As a matter of organization there are two sections purporting 
to be conclusions, both of which introduce new claims to
support the argument in an ad hoc fashion, mostly without
references.

The only disadvantage of prefixed TXT records is the loss of
wildcarding. The disadvantage of a new RR is serious, the
majority of the deployed DNS base does not support that 
application and this will not change for at least a product 
cycle, which means three years.

Application developers should be allowed to decide if the 
deployment advantage of prefixed DNS records outweighs the
loss of wildcards. It is an entirely reasonable engineering
decision.

If wildcarding is so spectacularly important then the group
will of course be anxious to fix it.

----Excerpt---
Add a prefix to the owner name

   By adding an application-specific prefix to a domain name, we will
   get different name/class/type triples, and therefore different
   RRsets.  The problem with adding prefixes has to do with wildcards,

   especially if one has records like

   *.example.com. IN MX 1 mail.example.com.

   and one wants records tied to those names.  Suppose one creates the
   prefix "_mail".  One would then have to say something like

   _mail.*.example.com. IN X-FOO A B C D

   but DNS wildcards only work with the "*" as the leftmost token in the
   domain name.

   Even when a specific prefix is chosen, the data will still have to be
   stored in some RR type.  This RR type can either be a "kitchen-sink
   record" or a new RR type.  This implies that some other mechanism has
   to be applied as well, with implications detailed in other parts of
   this note (see also draft-ietf-dnsext-wcard-clarify [wcardclarify]

---

From: Alex Bligh <[email-masked]>
Date: Fri, 15 Oct 2004 21:06:36 +0100

> use case is real but it cannot be met without *? style wildcards.

Does the latter (*?) actually need any protocol-level specification?

By which I mean is it not possible to
a) On a strictly conformant server, emulate *? with a macro (or similar),
   so
    *? IN TXT foo
    a IN TXT bar
    b IN MX baz
   becomes
    * IN TXT foo
    a IN TXT bar
    b IN MX baz
    b IN MX bar
b) If one wants to implement a server where * means "the other thing",
   i.e. *? (and you note some servers have done this), say "* in a zone
   file means *?" (and preferably provide a way to get *).

Alex

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 17 Oct 2004 09:33:06 -0700

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

Having a document like that is very useful, and the arguments are well
put, but I find three weaknesses in this version: unsubstantiated claims
about TCP, too much emphasis on wild cards in the analysis of the "name
prefix" solution, and a failure to acknowledge the potential desire of
implementers to avoid the IETF process.

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. In the draft,
the main argument against TCP for DNS is one of server performance. The
draft says that a TCP based operation causes 3 times more traffic, but
this is merely three types as many packets, not bytes. It also says that
the server load will be much increased, since processing UDP packets is
"much simpler". However, the TCP code paths are much optimized in modern
servers, and there is little performance penalty of serving a request
over TCP versus UDP. 

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.

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. In most
cases, applications know exactly which domain name should be extended,
and do not need the wild card facility. The wild card problem may exist
in theory, but it is seldom encountered in practice, and there are
obvious workarounds.

The document does not discuss the role of the IETF in the record type
creation process. This is an important issue for implementers. Although
the RR type field has the same size as the TCP port numbers, they are
not allocated in the same way. RFC 2929 lists record type numbers
4096-65535 as "available for assignment", but the IANA has no "Online
Application for a User (Registered) DNS Record Type Number". In
practice, record types can only be created by "IETF Consensus", which
takes a long time. This contributes to the public perception that
creating a record type is hard. This working group should either open
the current IANA procedures, or keep them while acknowledging that
record type creation is hard.

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Oct 2004 00:09:44 +0000

> ... find three weaknesses in this version: unsubstantiated claims about TCP
> ...

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.

i'm not saying it can't be done.  our headroom would allow this to happen
overnight... but then we'd have to start provisioning more headroom.  the
claims in this document are accurate.  tcp is more expensive than udp for
dns.  making a decision that would require all high volume nameservers in
the internet to jump curves wrt headroom and provisioning is what's "dubious".

> probably reconsider its stance versus TCP.

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.)

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Oct 2004 00:05:18 +0700

Date:        Mon, 18 Oct 2004 00:09:44 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | if we had to build a protocol control
  | block for each of the 5000 to 10000 queries that came in every second,

It is worse than that.   TIME_WAIT state (in addition to be required
somewhere, consuming resources - but that's probably at the client)
limits the number of TCP transactions/second between a client+server
pair (where the server port is fixed, as it is here) very severely,
it turns into just 100's a second (depending upon the packet TTLs,
and so what the MSL is).

That's insufficient for many DNS applications - which means that they'd
need to re-use connections - which means leaving connections alive on the
off chance they'll be needed again soon after.    That means that all that
state either hangs around much longer than you'd really want it to, or
the server needs to close down the connections, which means that it is the
system that ends up in TIME_WAIT, and that means a minumum of a couple of 
minutes per connection in idle state.

TCP just isn't an option for transaction services, like the DNS.

We could switch to using T/TCP, but we'd have to find something in
widespread use that actually has that available first... (and that
still means lots of connection setup).

On one of Christian's other points ...

  | The main argument against the name prefix solution is its
  | incompatibility with wild cards.

The main argument against it should be that domain names don't belong
to the IETF, they belong to whoever registered the domain, and the IETF
has no business whatever stealing names from organisations' domains.

kre

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 10:07:47 -0700

> -----Original Message-----
> From: Alex Bligh [mailto:[email-masked]]
On 15 October 2004 12:38 -0700 "Hallam-Baker, Phillip" 
> a) On a strictly conformant server, emulate *? with a macro 

All that is required is to document the wildcard usage and to define
an interchange format for it so that it can be used in zone transfers
and an appropriate NXT/NSEC usage.

The same applies for mid-level wildcards, _marid.*.example.com. It is not
rocket science.

I find it objectionable that we have people saying that the only
alternatives that can be considered here are prefixes without
wildcards or waiting for DNSEXT to deploy. There has been a real
alternative on the table that makes prefixes work as well as
new RRs but with a significantly lower impact on the deployed
infrastructure. Only parties that need wildcards need to upgrade
their servers.

I propose that the draft authors be asked to address these issues.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 10:20:59 -0700

> those we can provision easily.  it's the state-memory 

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.

> > 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.

> SMB/CIFS, or SQL?  (note to the humour-challenged, this is Sarcasm on

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 10:35:09 -0700

> has no business whatever stealing names from organisations' domains.

Names such as _MARID.example.com are unusable for DNS as machine 
names. It is already agreed that names of some form --xxx will be assigned
for internationalization use. So whats this with calling it
'stealling'?

Christian is making an important point. The reason SPF is written
to the bare TXT record without a prefix is that the people behind
it had no way to get themselves a RR without waiting for two years
before they could start deployment.

Sure they have asked for a RR, but they have absolutely no intention 
of ever using it or participating in a migration to it. We are
back with the X-Header problem of RFC 822, only worse because 
the unprefixed TXT record is going to become useless for other
purposes.

As Alex points out most applications do not require wildcards 
at all, merely server side macros that expand to the appropriate
entries.

The wildcard issue is thus irrelevant wrt prefixes, it can be
solved by a single site deployment that has no impact on the
rest of the infrastructure.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 18 Oct 2004 18:39:30 +0100

--On 17 October 2004 09:33 -0700 Christian Huitema 
<[email-masked]> wrote:

> server farms are designed for TCP, not UDP.

Aside from all the other arguments per Paul and Co, this is a real false
syllogism I can't let rest.

It is true that (most) commercial load balancing solutions in large server
farms are designed for TCP not UDP; however, this is because:
(a) the most frequently used (by requirement for load sharing) protocols
    use TCP (e.g. HTTP); and
(b) Anycast is so easy it doesn't require a "commercial load balancing
    solution" the same way TCP does, because it does not need to record
    state.

Indeed your premise could more validly be used as a counter-argument:
load sharing over TCP is sufficiently difficult that large server farms
require deployment of commercial load balancing solutions to do it,
whereas effective load balancing on UDP can be deployed using far more
lightweight technology such as anycast. Thus by switching to TCP you
are increasing the cost of load-balanced DNS (by your own thesis and
apart from Paul's and Phill's observations).

Alex

---

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

> From: Ted Hardie [mailto:[email-masked]]
> Using a code from the "private use" range for SPF might have been
> a bit of stretch, but "specification required" would have 
> been possible
> with far less of a barrier than a two-year consensus process.

If we are talking about anything less than a two year consensus 
process then the text should not be talking about protecting the 
DNS from maluse or baddly thought out proposals since that is
not going to be addressed by the process.

If that claim is going to be raised at all it should be 
substantiated with empirical evidence rather than introduced
for the first time in one of the conclusions sections. We
already have an example of a record that has deliberately set
to evade the review process.

I beleive that if the data is fairly interpreted then the only
significant difference between prefixes and new RRs is the 
extent of the review process. It is a logically consistent,
albeit naive, point of view that the review process might save
the DNS from a destructive record definition. But this point of
view is not consistent with RRs being readily available.

If the 'specification only' RRs are in fact issued then there
will be a new problem, nobody will ever want to use a standards
process RR again unless there is an inescapable loss of backwards
compatibililty anyway. Since the proposals will start with a
specification only number and have no incentive ever to change.

Rather than fixating on the MARID and MASS proposals as a means 
of deploying DNSEXT there are far more effective means available.

For example, lets try to address the problem of DNS spoofing 
without insisting on resort to crypto. All that is really needed
is a somewhat longer response cookie. So we create a DNS query
that is defined to result in the query data being returned.
Everyone who deploys MASS and MARID is going to want that capability
to talk to accreditation services.

The value of DNSSEC is going to come in authenticating policy 
publication, in particular security policy such as MASS, MARID
and others to come in the future. 

		Phill

---

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: [email-masked]
Date: Mon, 18 Oct 2004 20:22:49 +0000

> and others to come in the future. 

	clearly you and i do not share a common perception of
	value wrt DNSSEC.  one may reasonably ask if we are two
	of the blind men  trying to describe an elephant.

--bill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 15:05:01 -0700

> 	What happens when you have a thousand such records for
> 	different protocols.  You then have to find each and every
> 	potential LHS and try to match those against the query.
> 
> 	THIS DOES NOT SCALE.

Of course it does, same way it works for any other DNS zone
with a thousand entries.

WRITING IN CAPITALS DOES NOT CONSTITUTE AN ARGUMENT.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Oct 2004 15:13:34 -0700

> 	of the blind men  trying to describe an elephant.

Not necessarily, I was referring to the killer application for
DNSSEC which is not necessarily the same as the main use it
eventually finds.

A killer application is the one that creates the demand to build
infrastructure. Word processing was NOT the killer app for the PC,
the spreadsheet was. No manager would touch a keyboard in the 80s,
certainly not to type their own correspondence. The first PCs
were bought to do engineering spreadsheets.

The opportunity to establish a killer app is a narrow one. Having
blown opportunity after opportunity securing policy is the next
killer app opportunity that will be open for the next 18 months
or so.

If you try to sell DNSSEC as spoof protection at this point you
are not addressing a currently visible pain point and will not
get on network managers radar screens.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Oct 2004 22:31:55 +0000

> My understanding is that the SPF folks chose TXT because of problems
> with some widely-deployed DNS servers and proxy firewalls that don't
> support unknown record types, and also to allow records to be
> published by people using ISP-hosted DNS with a web-based management
> interface (which typically will not provide any way to create unknown
> record types).

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.

plz don't make this sound more complicated, or more considered, than it was.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Oct 2004 09:25:43 +1000

> WRITING IN CAPITALS DOES NOT CONSTITUTE AN ARGUMENT.

	Well the firsting you have to get agreement on is how many
	labels does * match in
	
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.1
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.2
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.3
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.4
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.5
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.6
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.7
	a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.8
	a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.10
	a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.11
	a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.12
	a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.13
	a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.14
	a.a.a.a.a.a.a.a.*.example.net A 127.0.0.15
	a.a.a.a.a.a.a.*.example.net A 127.0.0.16
	a.a.a.a.a.a.*.example.net A 127.0.0.17
	a.a.a.a.a.*.example.net A 127.0.0.19
	a.a.a.a.*.example.net A 127.0.0.20
	a.a.a.*.example.net A 127.0.0.21
	a.a.*.example.net A 127.0.0.22
	a.*.example.net A 127.0.0.24
	*.example.net A 127.0.0.25

	with a query of

	a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.example.net

	is it *.example.net A 127.0.0.25
	or a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.1
	or a random one from above or all of them ....

	Allowing * to expand in the middle creates large search spaces.

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

---

From: [email-masked]
Date: Mon, 18 Oct 2004 23:30:49 +0000

> Hallam-Baker, Phillip wrote:
> >  Bill writes:
> > > Hallam-Baker, Phillip wrote:

	again, you see this elephant differently.  i'm 
	not persuaded that the DNS is the right place to 
	encode policy...(Hey.. lets reuse TXT for that!!!)
	 although it is a where it might be done (and $DEITY 
	knows I've tried, ref: RIDE, IRRd, RPSL in the DNS, et.al.  
	from the previous decade) - 
	pretending that DNSSEC would be able to authenticate 
	such a publication method or to "secure policy"  requires 
	that you share more information about your presumptions 
	on DNSSEC capabilities.

	to paraphrase an old saying; "I hope you brought enough
	drugs for the whole class".   Or maybe I'm just too slow
	to keep up?  Perhaps you might take this offline and 
	help me understand what you are trying to acheive here?

> get on network managers radar screens.

	thats not the selling point i'd make, even if i thought
	dnssec was operationally feasable.

---

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

> or format-change, and they (microsoft) blew their chance due 

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 16:53:06 -0700

Mark writes

> a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.
> a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.
> a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.
> example.net
> 
> 	or 

Not at all, since we are talking about macros not wildcards
there is no reason why this has to be standardized and there is 
no reason why servers need to provide unbounded matches.

Even on the entirely artificial example you give there is a simple rule that
can be applied, take the most specific match, starting with the RHS, then
take the LHS. So that gives you 127.0.0.1. 

The matching rule is no worse for the LHS than the RHS. Its a straight FSM
with a very tightly bounded complexity.

You only start creating problems if you allow multi-level macro wildcards
which nobody has asked for. And even that is not really a major problem,
even 1970s technology like UNIX could handle matches on a*b*c. Its undergrad
intro to parser theory 101. All the algorithms are nice and regular.

Please take a look at your examples and spend some time thinking about them
in future before telling us in all caps that there is a problem.

		Phill

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Oct 2004 20:26:58 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    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 do we have to run the same software everywhere?
  I like diversity.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

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

>   So, you don't mind if your secondary servers answer differently than

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 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:
...
>that using TCP would be a catastrophe, which is dubious...

>complaints about incompatibility between SRV and wild cards...

>creation process...

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

"Now under neu management"

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Oct 2004 09:32:37 -0400

At 3:59 -0400 10/20/04, Alex Bligh wrote:

>I think the point is that you only try one if the other fails. Therefore
>it can only be faster and MORE resilient to network congestion (etc.),
>EXCEPT in the case of non-existent records, which I would suggest are
>the minority.

Speaking from the experience of talking with the MARID group and also 
from observing the behavior of one popular DNS implementation, 
relying on a strategy of "try one, if it fails, try the other" is not 
going to be well received.

The problem is that this causes a latency hit for the application. 
Packets and bandwidth are cheap, a user's time isn't.  Application 
designers want to avoid long activity-dependency chains.

When searching for glue records, one DNS implementation asks for AAAA 
and asks for A simultaneously at all steps.  There's no real 
alternative - it's not like you can ask for just the A and then get 
the AAAA when you get an authoritative answer (positive or negative) 
- or vice versa.  That's because it's a waste of sending the last 
query, especially when the domain name sought has just one or the 
other address type.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Oct 2004 11:17:59 -0400

At 9:51 -0400 10/20/04, Paul Vixie wrote:

>what do you all think NOW?

Since you've asked. ;)

I think that it's not all bad.  The current practice does achieve the 
goals of minimizing latency, allowing the migration from v4 to v6 
(and vice versa) to occur at the edges, is backward compatible with 
older software, and is resilient.  That's a lot of good.  There is 
that nasty cost of double the traffic though, that's a waste.

Hindsight isn't always 20-20.

Had we pursued multiple queries in a message, we'd have had to deal 
with the issue of partial results - like, if one query was for 
(foo.example. IN A) and the other was for (bar.example. IN A) and 
foo.example. existed and bar.example. did not, how is a half name 
error returned?  Who knows - had we travelled down that road would 
the WG be wrapped around the axle over AAAAbis by now?

Had we thrown the AAAA in the additional section, we may have had 
problems with the older pass-through servers that might not have 
known to add the AAAA's when it was needed (answering from a 
non-authoritative source).  We'd have been creating a new type with 
"special considerations."

Summarizing the above - we now have empirical evidence of a pitfall 
of the option chosen (which I prefer over anticipated concerns) and 
we have two other options that haven't faced a test.

One untried option is a new RR type (e.g., NSADDR) which may have all 
the glue in one RDATA (one large RDATA section).  EDNS0 solves size 
problems and we could do this as a "try this one, then fallback" for 
backwards compat.  Oops - there's that phrase "then fallback".  Maybe 
not wise course either.

I'd say that I'm happy with the bird in hand, even if it leaves me 
with guano, than the two birds in the tree.  I would be happier with 
the two birds in the tree, but I have to keep asking if the effort to 
obtain them is worth it considering what I already have.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 21 Oct 2004 11:21:15 -0700

Ed Lewis writes:
> My motivation is not to do this for the sake of academic 
> protocol/architectural purity.  My motivation is to move the DNS into 
> position for future efforts (via having a pure protocol/architecture).

This is my motivation as well. But I believe I am starting from a 
considerably wider view of what that oppportunity is and how we
can best get there.

I am viewing the problem in terms of critical paths. If the DNSEXT
group insists on placing deployment on my critical path then I
am going to do everything I can to prevent their advice being
taken. I would hope that most people would understand why I am 
not going to allow IPv6 to be placed in my critical path. New
RRs fall in the same category. However much you like them they
do nothing for me and it is my community that has the pain points
and the industry consensus that are the ingredients of a killer 
app.

The document is a rather transparent attempt to try recourse to
authority. To play that game you should really understand what
your hand is. I don't claim to be the best engineer here. But
I am a whole lot more experienced at communicating with the 
people who have the decision power which is not the IESG or 
the IAB.

>going to be well received.

Ed tried his best, but the agreement in the room for Ted's proposal
was on the understanding on the part of the implementors that it
would change nothing in practice. Nobody expected a significant
number of sites to use the new RR for at least ten years. And 
regardless of what the spec said nobody seriously intended to 
implement a serial scheme where the RR is tried first with 
fallback to TXT. At best the systems would do it in parallel.

If you think it terrible that people would ignore authority in
this way then ask yourself what was ever done to justify that
authority.

Dan Bernstein writes:
>We already have encouragement. I already quoted the relevant sections of
>RFC 1034 and RFC 1123. I wouldn't object to yet another document making
>crystal clear that BIND and NSD and Microsoft screwed up and that we
>really want to get rid of this problem before 2010.

Is that what people would consider a reasonable data for requiring 
servers to deploy new RR types?

I am not opposed to the use of new RR types, in fact there are some
proposals in that regard that I do want to make - XML resource records
for example.

Pekka writes:
>Unless we use it, nothing is going to change in the next 10 years.

So, that does not give you the right to tie your ornaments to my
Christmass tree. And that is the precise analogy I have been 
raising in the policy area.

>By the way, as it appears a lot of people are breaking DNS
>specifications pretty badly, I wonder if it would make sense to try to
>come up with some kind DNS implementation requirements document,
>similar to "host requirements" a long time ago, but updated with
>respect to new specs.. this would be a lot of work, but it might be
>worth it if we want to decrease the amount of completely broken DNS
>implementations out there.

I do not believe yet another document will do anything. What we
need is compliance testing. The failure of the IETF to address this
area is understandable, hey testing is what real engineers do, it
does not get you tenure. But that is what is needed in the real
world.

Paul writes:
> if new rr's take too long on deployment to be useful for new globally
> deployed services and service models to be practical, somebody had
> better tell microsoft that using SRV was a mistake.

Microsofts use is a bad example. Microsoft use SRV to configure windows
in an environment where Windows is the infrastructure. To take
advantage of the SRV all your infrastructure has to have been 
upgraded already.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Oct 2004 08:56:56 +1000

> advantage of the SRV all your infrastructure has to have been 

	Well lets look at another example AAAA.  The ends that
	wanted to use AAAA upgraded their servers and apart from a
	few load balancers, which also usually didn't handle SOA/NS/MX
	records, there were no major problems.  AAAA as we know
	required much more than just adding a new rdata type.

	AAAA deployment has also weeded out most of the bad servers
	so later deployment of new types should go smoother.

	I don't know about the other developers but BIND 9 is
	designed to allow for the easy addition of new RR types.
	Write a pair of files (.c,.h) that describe the wire and
	text formats, additional processing rules etc.  Recompile
	and you are done.

	IPSECKEY did just that to test out the new RR type.

	Mark

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 22 Oct 2004 05:59:35 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Andrews

> 	required much more than just adding a new rdata type.

If it is that easy then why don't you go get everyone to
deploy and let me know when you are finished. Just get off
my critical path until you are done.

If Ipv6 is the best example you can propose then I guess
we don't need to argue this any more.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 22 Oct 2004 09:15:21 -0700

> From: [email-masked]
> > 	I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA
> > 	transition.  It is taking a long time because people left
> > 	the IP6.INT crutch in place.  We really should not be
> > 	shipping resolvers that use IP6.INT.  Stop making the old
> > 	lookups and the new records will appear.
> > 
> > Mark Andrews, ISC
> 
> 	actually, when the queries stop (e.g. the old resolvers
> 	are upgraded) the servers will be turned off. the new 
> 	delegations (and by extention RR types) need to be visable
> 	first.  

The community that is doing deployment of IPv6 is somewhat more
technically astute than the average ISP netop.

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.

The timescale that a solution has to be deployed in is very
tight, we have a large number of criminal gangs that are stealing
the life savings of seniors, many of whom do not exactly have the
best mental faculties at this point.

The reason that we have to redo PGP and S/MIME in the first place
is that people were desiging systems to amuse themselves not protect
real people from real risks. I am dealling with security for real 
people, not for geeks.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Oct 2004 07:34:22 +1000

> 	delegations (and by extention RR types) need to be visable

	The problem is that new resolvers try IP6.ARPA then if they
	don't get a answer they try IP6.INT.  You will never see
	the IP6.INT queries drop off as there will always be a
	significant number of addresses that have neither a IP6.ARPA
	or IP6.INT PTR record.  The only way out of this is for OS
	vendors to be brave enough to stop using IP6.INT as a crutch
	or for someone to be brave enough to put in "IP6.INT DNAME
	IP6.ARPA".  Once that is done you can say to the OS vendors
	that it is now pointless to try IP6.INT if you don't get a
	IP6.ARPA response and the later can't exist.

	Look like KAME has bitten the bullet.  Hopefully the rest will
	follow.  The following is from FreeBSD.
	Note: I havn't checked any of the others.

	MFC: now e.f.f.3.ip6.arpa is delegated, we no longer need to
	query ip6.int

	Mark

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 22 Oct 2004 16:32:43 -0700

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Andrews
> 	The longer you debate whether it can be done or not just
> 	increases the amount of work that has to be redone.  You 
> 	seem to be your own worse enemy here.

No, the debate is not delaying my plans in the slightest which
are unchanged and will continue to use prefixed TXT records.

This debate is most useful in helping clarify the situation
with respect to venue. The more intransigent this group is
in demanding that deployment of a new RR be in the critical
path without giving any valid technical justification then 
the easier it will be to persuade other parties to consider
non-IETF venues.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Oct 2004 10:22:10 +1000

> the easier it will be to persuade other parties to consider

	The valid technical arguement is that there is no way
	to safely sub-type TXT.

	As a proof of concept TXT works.  It's time to take it
	from the proof of concept stage to production.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 22 Oct 2004 17:29:47 -0700

> 	The valid technical arguement is that there is no way

That claim is utterly untrue. Prefixed TXT records are
perfectly safe, nobody has tried to make the claim that
there is any risk involved.

The only claim made is that certain wildcard features
don't work in the optimal way in the legacy servers.

That is certainly not a safety argument and trying FUD
will not help.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Oct 2004 12:36:19 +1000

> That is certainly not a safety argument and trying FUD

	You are confused about what I mean by sub-type.  SIG and
	RRSIG are example of sub-typing.  The rdata contains sub-type
	information.

	The proof of concept tried to sub-type TXT by having a
	prefix string in the record.

	Mark

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 23 Oct 2004 07:46:44 -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.

> Sent: Friday, October 22, 2004 10:36 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt 
> 
> 
> 
> >

---

From: Mark Andrews <[email-masked]>
Date: Sun, 24 Oct 2004 08:20:03 +1000

> 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.  You have the problem that
	it doesn't work with wildcards (your own admission).  These
	prefix problems will not go away with time.  Nor will
	the fact that none of use owns the namespace once it has
	been delegated.  We made a mistake with SRV, we are trying
	not to compound that mistake.

	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.  It can be also demonstated that
	a new type is a technically superior solution to sub-type /
	prefix.

	Mark

---

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

> 	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.

> 	premise was based on FUD.  

No, you did nothing of the sort.

>  It can be also demonstated that

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]]

> 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.