RE: I-D ACTION:draft-iab-dns-choices-00.txt
Hallam-Baker, Phillip
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]
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Christian Huitema
[ 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.=20
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
Paul Vixie
[ 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. ]
> ... find three weaknesses in this version: unsubstantiated claims about TCP
> ...
> 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.
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".
> 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.
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.)
Hallam-Baker, Phillip
> From: Alex Bligh [mailto:al...@alex.org.uk]
On 15 October 2004 12:38 -0700 "Hallam-Baker, Phillip"
>
> > * 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.
>
> By which I mean is it not possible to
> a) On a strictly conformant server, emulate *? with a macro
> (or similar),
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.
Robert Elz
From: Paul Vixie <pa...@vix.com>
Message-ID: <200410180009...@sa.vix.com>
| 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
Hallam-Baker, Phillip
> block for each of the 5000 to 10000 queries that came in
> 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.
Hallam-Baker, Phillip
>
> | 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.
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.
Hallam-Baker, Phillip
> From: Ted Hardie [mailto:har...@qualcomm.com]
> 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
Robert Elz
From: "Hallam-Baker, Phillip" <pba...@verisign.com>
Message-ID: <C6DDA43B91BFDA49AA2F...@mou1wnexm05.vcorp.ad.vrsn.com>
| > By which I mean is it not possible to
| > a) On a strictly conformant server, emulate *? with a macro
| > (or similar),
|
| 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 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.
That is, the only issue here is saving typing time in the zone file,
which is a fine goal, but needs exactly no changes to the DNS to
satisfy (doesn't even require changes to DNS server implementations,
all of this can be done with a preprocessor tool, perhaps something
similar to the dns zone signer application(s)).
| The same applies for mid-level wildcards, _marid.*.example.com. It is not
| rocket science.
When you start looking at the the corner cases that need to be dealt with
to really make that work (cases which perhaps don't matter much to most
practical uses, but which need to be defined if anything like this was
to be added) you'll find that it isn't nearly as simple as it seems (to
even just be explicit about what this is really intended to mean, let
alone how to specify that precisely).
kre
Robert Elz
From: "Hallam-Baker, Phillip" <pba...@verisign.com>
Message-ID: <C6DDA43B91BFDA49AA2F...@mou1wnexm05.vcorp.ad.vrsn.com>
| Names such as _MARID.example.com are unusable for DNS as machine
| names.
That's simply wrong to start with, there are a few protocols that
forbid such names, but for most just about anything goes. And quite
apart from that, who says what I am putting in my domain is machine
names - it is mine, I'll put there whatever I want to put there.
| 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.
Yes, that point of his I agree with, it is hard to get a new RR currently.
Part of that problem, of course, is that no-one has really been willing
to really trust that unknown RR types are really handled correctly by
all the existing servers out there.
Hallam-Baker, Phillip
> 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.
bman...@vacation.karoshi.com
> 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
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
D. J. Bernstein
> 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
Yes. A huge fraction of the DNS deployments on the Internet are BIND
versions that can't handle unknown record types. Every new record type
immediately encounters massive interoperability failures. Removing those
failures means updating BIND and waiting _years_ for BIND redeployment.
(BIND 9.1.0 finally fixed this bug---but a May 2004 survey of *.com,
*.net, *.org, *.info, and *.biz found 11 million second-level names
published by servers running BIND 8. Redeployment takes a long time.)
In contrast, TXT works. Yes, it requires coordination to avoid name
clashes; yes, it has space limits; but at least it succeeds in
distributing data to every interested client.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Ted Hardie
>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.
While Christian's point is important, I note that BCP 42 actually
distinguishes among various ranges:
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by IETF Consensus.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by IETF Consensus.
256 - 32767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
Consensus.
32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65280 - 65535
0xFF00 - 0xFFFF - Private Use.
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.
I believe the fundamental reason these folks chose TXT was that
existing libraries understood TXT records well enough. The
ease of parsing these records was the second factor, again,
in my opinion.
If folks thing BCP 42 needs an update, or that IANA needs new
processes to handle requests in the various ranges, I think
now might be a good time to send text. Since RFC 3597 is now a proposed
standard, we can hope for more complete libraries, and I suspect we will see
more requests for new RRs.
Just my opinion,
regards,
Ted
James Snell
> I believe the fundamental reason these folks chose TXT was that
> existing libraries understood TXT records well enough. The
> ease of parsing these records was the second factor, again,
> in my opinion.
I can collaborate this thought. In a couple of days a new I-D should
be published that describes a couple of new resource record types
we've been working on. In our initial passes at these records we had
intended to use TXT records precisely for the reasons given above. We
ultimately decided against their use because of the problems inherent
in their ambiguity. It simply made more sense to create specific
record types to handle the data we needed, despite the process
required to get those types officially allocated. For our private
work-in-progress prototype implementations of the I-D, we have chosen
two numbers from the private range.
--
- James Snell
IBM, Emerging Technologies
jas...@gmail.com
Alex Bligh
--On 17 October 2004 09:33 -0700 Christian Huitema
<hui...@windows.microsoft.com> wrote:
> TCP has other advantages. Commercial load balancing solutions in large
> 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
Roy Badami
Ted> I believe the fundamental reason these folks chose TXT was
Ted> that existing libraries understood TXT records well enough.
Ted> The ease of parsing these records was the second factor,
Ted> again, in my opinion.
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).
-roy
Mark Andrews
> > -----Original Message-----
> > From: Alex Bligh [mailto:al...@alex.org.uk]
> On 15 October 2004 12:38 -0700 "Hallam-Baker, Phillip"
> > <pba...@verisign.com> wrote:
> >
> > > * 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.
> > Does the latter (*?) actually need any protocol-level specification?
> >
> > a) On a strictly conformant server, emulate *? with a macro
> > (or similar),
>
> 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.
>
> 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.
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.
> I propose that the draft authors be asked to address these issues.
>
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Hallam-Baker, Phillip
> 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.
Hallam-Baker, Phillip
> > 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.
> >
>
> 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.
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.
Paul Vixie
> 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.
Mark Andrews
>
> > 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.
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
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: Mark_A...@isc.org
--
bman...@vacation.karoshi.com
> > Bill writes:
> > > Hallam-Baker, Phillip wrote:
> > > 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.
> >
> > 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.
>
> blown opportunity after opportunity securing policy is the next
> killer app opportunity that will be open for the next 18 months
> or so.
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?
> 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.
thats not the selling point i'd make, even if i thought
dnssec was operationally feasable.
Hallam-Baker, Phillip
> 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.
Hallam-Baker, Phillip
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
Michael Richardson
>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pba...@verisign.com> 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 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[
] m...@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQXRfUIqHRg3pndX9AQEiDgQA0mmz+Dqa2vgFFooV+VNyYmbcEg728/70
GmrCq86udDZIyWdOLWhQtcdEzlJqxky1k+zlAxqp3aGCohApd5ssSwXbN0zVbHe2
7CyhvuT8VxeBYhsmgHKMCtMJmxgg8hkgtZ0u3+G6BI78WwzRCYYfCCc6IdD4XGy4
wOvjHJkz2Yc=
=a6bF
-----END PGP SIGNATURE-----
Hallam-Baker, Phillip
> <pba...@verisign.com> 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.
D. J. Bernstein
As RFC 1034 says: ``Researchers are continuously proposing, implementing
and experimenting with new data types ... experimental behavior should
always be expected in extensions beyond the official protocol.'' As RFC
1123 says: ``DNS software ... SHOULD be written to minimize the trauma
associated with the introduction of new well-known types and local
experimentation with non-standard types.'' My DNS software has always
handled the complete 16-bit range of possible record types.
The reality, however, is that certain implementors have screwed this up
horribly. A large part of the Domain Name System, as it actually exists
on the Internet today, fails to deliver records whose types aren't on a
very short list. Fixing this will take years. We have to be honest about
this when we're talking to people writing software that uses DNS.
Alex Bligh writes:
> If you don't make it clear that the preferred way to incorporate new
> DNS features is new RR Types
For anyone who cares about interoperability, new RR types are _not_ the
preferred way to incorporate new DNS features. The preferred way is TXT
records. TXT records, unlike new RR types, succeed in delivering the
data to every interested client.
The problem here is not a failure to communicate the advice. The problem
is that the advice is wrong. Anyone who is suckered into following the
advice in draft-iab-dns-choices will suffer massive real-world
interoperability problems---and will then switch to TXT records,
throwing draft-iab-dns-choices away.
> the effect of guidance such as in draft-iab-dns-choices on the various
> DNS-speaking servers/appliances/UIs.
This draft isn't talking to the DNS implementors. It's talking to the
DNS users. It's giving amazingly bad advice to the DNS users.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
--
Edward Lewis
>For anyone who cares about interoperability, new RR types are _not_ the
>preferred way to incorporate new DNS features. The preferred way is TXT
>records. TXT records, unlike new RR types, succeed in delivering the
>data to every interested client.
On the one hand I agree with Dan. On the other hand I disagree with
Dan. (I am glad I do not have three hands.)
"In the moment" there are realities that cripple efforts to roll out
new RR types, resulting in the use of the TXT RR as a crutch. Dan is
right about that.
One could react to this with a resigned countenance and go along with
the crowd. One could also decide to take an activist posture and try
to fix the world, one application at a time.
I am making this suggestion (for the document) - which I have heard
from someone else. Encourage the use of new RR types as an extension
mechanism for the DNS while noting a (potential) need to develop a
transition mechanism that makes use of types that are in current
widespread use - e.g., TXT.
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).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"Now under neu management"
Alex Bligh
--On 19 October 2004 17:32 +0000 "D. J. Bernstein" <d...@cr.yp.to> wrote:
> For anyone who cares about interoperability, new RR types are _not_ the
> preferred way to incorporate new DNS features. The preferred way is TXT
> records. TXT records, unlike new RR types, succeed in delivering the
> data to every interested client.
>
> The problem here is not a failure to communicate the advice. The problem
> is that the advice is wrong. Anyone who is suckered into following the
> advice in draft-iab-dns-choices will suffer massive real-world
> interoperability problems---and will then switch to TXT records,
> throwing draft-iab-dns-choices away.
Last time I looked there was no defined format for TXT records either, also
leading to real world interoperability problems the first time two
implementations collide, or versioning problems.
It may be (de-facto) true that most DNS speaking devices do not support the
extensibility required by the protocol definitions. The answer to this (at
a protocol definition level) would not appear to be "throw away the
extensible protocol and go to freeform text records".
Clearly, at an implementation design level, it's going to be pragmatically
necessary to work around widescale deployment bugs. It's not the first time
that has happened. I don't really see why implementations should not for
instance try their new RR type and if it's absent (or they get an error)
fall back to TXT. But unless you are proposing defining (at a protocol
level) what goes into a TXT record, that would seem to be an implementation
issue, not a protocol issue.
Putting it right in the protocol means there will be encouragement to fix
all these buggy implementations.
Alex
Stephane Bortzmeyer
Paul Vixie <pa...@vix.com> wrote
> 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.
Not really true, I think. Roy Badami gave a better description
(http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01912.html).
Some elements:
* Every MS-Windows computer has a problem with unknown record types,
according to Microsoft itself. See
http://www.imc.org/ietf-mxcomp/mail-archive/msg01517.html and
http://www.imc.org/ietf-mxcomp/mail-archive/msg01511.html.
* Many "firewall appliances" have a problem when relaying DNS with
unknown record types.
* Many "registrars" or other DNS providers give you access to the zone
contents only through an "user-friendly" interface. Not everyone edits
the zone file with vi or emacs. The problem is so common that there is
a list of DNS providers that *do* allow you to create TXT records
(http://archives.listbox.com/spf-d...@v2.listbox.com/200407/0933.html),
not to mention unknown record types.
I do not ask you to adopt TXT records (you could say that Microsoft OS
is hopelessly broken and I would agree) but do not think the choice of
the SPF people was careless.
[Reminder: the issue of the new RR type for SPF -
draft-lentczner-spf-00.txt - will be discussed in Washington.]
Edward Lewis
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"
--
Alex Bligh
--On 19 October 2004 14:21 +0200 Stephane Bortzmeyer <bortz...@nic.fr>
wrote:
> I do not ask you to adopt TXT records (you could say that Microsoft OS
> is hopelessly broken and I would agree) but do not think the choice of
> the SPF people was careless.
Seems to me there is a bit of a chicken & egg argument going on here.
If you don't make it clear that the preferred way to incorporate new
DNS features is new RR Types, then people will continue to ship broken
operating systems / UIs etc. on the basis that new DNS features will
use TXT.
That does *not* mean (IMHO) that the early decision to use TXT for
SPF etc. was careless / dumb (whatever), it merely means it was taken
(a) in the absence of guidance as being proposed by draft-iab-dns-choices,
and (b) in the absence of the effect of guidance such as in
draft-iab-dns-choices on the various DNS-speaking servers/appliances/UIs.
IE if everyone (SPF folks included) were already following
draft-iab-dns-choices, there would be no need for it. So the fact that
people aren't following draft-iab-dns-choices (or producing compatible
OS's and appliances etc.) is a justification FOR having it, not against
having it; not should it serve to criticize people who've made other
decisions in the past (which is not I think what Paul meant, but...)
Alex
Mark Andrews
> The reality, however, is that certain implementors have screwed this up
> horribly. A large part of the Domain Name System, as it actually exists
> on the Internet today, fails to deliver records whose types aren't on a
> very short list. Fixing this will take years. We have to be honest about
> this when we're talking to people writing software that uses DNS.
FUD.
You have to be able to publish the record. You have to be
able retrieve the record. Depending upon which end(s) you
are on you have control to upgrade any servers which don't
support the new type, either directly or via finacial mean.
The same goes for any middleware interfering with the DNS
traffic. If you choose not to exercise that control don't
complain.
It's not like there isn't a existing solution space to the
problem. The solution space exists and is well populated
by mutiple vendors whether the problem is the nameserver,
middleware or ISP. In most cases your existing vendor
already has a fix or can implement a fix and if they don't
change vendor.
The main reason nameservers are not upgraded is because
they perform adequately enough for their users. All you
are seeing is sites that haven't yet seen the need to
upgrade.
A nameserver doesn't have to be able to publish a MX record
if it will never be asked to publish one. Lots of load
balancers arn't capable of publishing a MX record and no one
cares about that. A nameserver has to be able to return
a valid negative answer when asked about a MX record. Some
load balancers fail to do this correctly and people do care
about that.
The real litmus test is how many nameservers return a invalid
negative answer when asked about a new RR type not how many
are capable of serving the new RR type or even fetching the
new RR type. The later two will be addressed by direct
consumer presure. Only in the first case has a real negative
impact on deploying new RR types and in my experience there are
only handfuls of servers that fail to return valid negative
answers.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
D. J. Bernstein
> Last time I looked there was no defined format for TXT records either,
> also leading to real world interoperability problems the first time
> two implementations collide, or versioning problems.
Seems to me that we're doing just fine defining TXT-record formats and
avoiding TXT interoperability problems. Of course, this success comes
from open, honest communication among implementors---the sort of thing
that IETF used to promote and now actively interferes with.
The bottom line is that TXT succeeds in delivering the data to every
interested client, whereas new record types are a miserable failure.
> I don't really see why implementations should not for instance try
> their new RR type and if it's absent (or they get an error) fall back
> to TXT.
That's a much worse solution than pure TXT records, for several obvious
reasons: (1) for interoperability, everyone will have to provide TXT
records anyway, so the new RR type is extra work for the administrator;
(2) the new-then-TXT approach is more work for software authors than
pure TXT; (3) when networks are overloaded, the new-then-TXT approach
fails more often than pure TXT; (4) the new-then-TXT approach is often
slower, and never faster, than pure TXT.
> Putting it right in the protocol means there will be encouragement to fix
> all these buggy implementations.
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.
However, until the bug has actually been fixed on every machine we can
see, it's irresponsible to tell people to use new record types.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
--
Paul Vixie
services and service models to be practical, somebody had better tell microsoft
that using SRV was a mistake.
(and, note: we've cut the time down by a lot since then.)
Paul Vixie
> 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.
this is why, back in the days of rfc1886, i argued that the additional-data
processing for AAAA should be to "add any A RRs matching the same qname".
this is also why, back in the days of rfc2672, i argued that qdcount>1 should
be made meaningful, so as to allow several qtypes to be looked up for the
given qname/qclass.
in both cases the WG said "that's more complicated than the payback is worth."
what do you all think NOW?
bman...@vacation.karoshi.com
Mr D.J. Bernstein, Associate Professor, Dpt of Mathmatics,
Statistics, and Computer Science, University of Illinois at
on acceptance of email. My reply talks to local policy as
well as pointing out a possibly defective line of reasoning
in his assertions. For the record.
> Seems to me that we're doing just fine defining TXT-record formats and
> avoiding TXT interoperability problems. Of course, this success comes
> from open, honest communication among implementors---the sort of thing
> that IETF used to promote and now actively interferes with.
sub-typing inside the RDATA section... cool. move the
problem from unknown RRtypes to unknown RDATA types.. :)
who gets to keep track of the "open honest communication"
about the various sub-typing formats so that future
implementors can know what do do w/ the contents of
RDATA? Must be the IANA.
> The bottom line is that TXT succeeds in delivering the data to every
> interested client, whereas new record types are a miserable failure.
this line of thinking should raise the question - why keep
any of the other, now vestigal, RR types... anything we want
can be done in the TXT RR. right?
> That's a much worse solution than pure TXT records, for several obvious
> reasons: (1) for interoperability, everyone will have to provide TXT
> records anyway, so the new RR type is extra work for the administrator;
er... no. I -dont- have to provide or support TXT records. My zone,
my data...
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> --
--bill