Subject: Re: wildcards vs. RR types, was Faux wildcards

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Jan 2005 13:42:11 -0800

At 9:11 PM +0000 1/18/05, John Levine wrote:
>  Part of the issue here seems to be that people have difficulty
>understanding what the goal is. It's to provide a nothing-here answer
>for unused names, in a way that lets clients distinguish a domain that
>returns deliberate nothing-here responses from one that has no data
>either way.
>

That isn't the only goal I've heard.  One goal I've heard is to have
some way of saying "This is the default for members of this set;
specific members in the set may have separate declarations
that define something different".  That is different from "nothing-here
answer for unused names", since it applies to names which do exist
but have no separate declaration.

			regards,
				Ted Hardie

--
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: Peter Koch <[email-masked]>
Date: Tue, 18 Jan 2005 22:45:01 +0100

John Levine <[email-masked]> wrote:

> > The MARID problem was different and that pointless debate should
> > better not be rehashed here again.

> routine in the client.  That needs software upgrades all around, and
> it's a major bar to deployment to tell people that they need to spend
> money and change their firewalls.

I'll follow my own advice.

> returns deliberate nothing-here responses from one that has no data

Take new RR type FOO. Attach information to existing names by adding
a FOO RR (or a FOO RRset, for that matter) to those names' RRs, either
"manually" by server based macro expansion (a la $GENERATE) or via a
preprocessor external to the name server.
Attach (maybe different) information to non-existing names by using wildcards,
if necessary. Now, if a FOO query doesn't return a FOO RRset, you'll
assume that the FOO scheme is not (yet) supported.

NB: I do not say publishing the information *and* maybe its complement is a
    good idea or a clever long term strategy. It just helps to
    distinguish between 'supported' and 'unsupported'.

-Peter

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2005 17:16:12 -0500

> but have no separate declaration.

Yes, that's the other goal.  I will agree that by adding enough extra
records to the DNS you can get the effect of a default by adding an
explicit RR to every name that already exists, so that's a more debatable
argument about how much glop domain owners are likely to be willing to
add.  Personally, since my DNS data file is generated by perl scripts, I'd
find it no big deal.

But the nothing-here issue is much tougher, since I don't see any way to
fake it other than by defining RRs and waiting a decade for every
Microsoft user to upgrade his firewall.

The same tree walk that handles the nothing-here case also handles the
default case, so if you can stand the first, the second is there if you
want it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 18 Jan 2005 20:23:03 -0500

On 1/18/2005 4:11 PM, John Levine wrote:

> The specfic issue is that widely used Microsoft firewalls proxy DNS
> requests using a separate RPC for each RR type.

And they could have easily fixed this bug during the period we've been
debating the subject, but they haven't.

Designing protocols around buggy software that the vendor has empirically
abandoned is wrong.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2005 20:57:37 -0500

> debating the subject, but they haven't.

Honestly, I don't know how to respond to silly arguments like this.  The
MARID fiasco started about a year ago.  A year is a fairly short release
cycle for a commercial software product of any size.  (Been there.)
There are still substantial numbers of Microsoft customers using software
that they shipped three, four, even six years ago.  This shouldn't
surprise anyone, since there are still plenty of people using versions of
every other kind of software that were shipped years ago.

There's no question that Microsoft made some poor design decisions in
their DNS software, but even if they were dying to get everyone to upgrade
(which they certainly are for some upgrades like XP SP2), it'll be years
until you can assume that most of the users have installed it.  They're
still issuing patches for Win98, because the large number of people still
using it grouse and they can't abondon it.

Regards,

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 18 Jan 2005 23:14:37 -0500

> until you can assume that most of the users have installed it.

This is quite the strawman circle-jerk. First of all, the complaint as
stated is that they haven't even patched the code yet, and that if they'd
patch it (as opposed to distribute it to every system that ever downloaded
a test package) this problem would go away. Second, requiring the use of
service packs and patches is common practice, and telling people that they
need to get some hotfix for their borked ~firewall is neither new nor
prohibitive. Third, designing protocols to accomodate broken software is
bad design anyway.

---

From: "John R Levine" <[email-masked]>
Date: 18 Jan 2005 23:43:07 -0500

> stated is that they haven't even patched the code yet,

No, actually, the complaint is that they screwed up the design.  It's not
at all obvious to me how you'd patch around that design other than perhaps
adding a generic pass-through-the-bits call, and even if they did that I
don't know how it might affect calls that do ANY requests.

But it hardly matters whether they've shipped an upgrade or not.  As Dan
Bernstein pointed out, even though the MS firewall is the most egregiously
broken package with respect to new RRs, there are still plenty of *IX
systems running old versions of BIND that will fall over if confronted
with new RR's, too.  I entirely agree that as a long term goal we should
try and figure out how to get people to upgrade their DNS software, but
it's nuts to do designs that you can't use until they do.

Or to put it another way, if you believe that most people update their
software, why aren't we all using IPv6?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Jan 2005 00:01:23 -0500

On 1/18/2005 11:43 PM, John R Levine wrote:

> software

Can we stick to the points I'm actually making?

It's not unprecedented or uncommon to tell people that they have to
upgrade to use some other piece of software. This happens all the time in
MS-land in particular (cf Active Directory, DirectX, Windows XP, etc etc
ect), and this has also happened with DNS extensions as well (eg, "upgrade
BIND if you need to use SRV"). Besides which, if they aren't even patching
the software, then it's effectively abandonware and is irrelevant to the
design anyway. In either case, the shortcomings of a particular product
should be and effectively is irrelevant.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Jan 2005 07:40:40 +0200 (EET)

> every other kind of software that were shipped years ago.

Probably.  But how many of those SMTP servers which need to make these 
lookups, or how many DNS servers (providing information about that 
site's zone) are behind such firewalls?

There's no doubt there's breakage out there, but the point is whether 
we need to care about it.

I can't imagine a major mail system or DNS server would be behind such 
a firewall.  And our primary target is major mail systems and zones, I 
suspect.  In the big picture, small sites using broken and abandoned 
firewalls seem irrelevant.

The simple answer could be, "if you have a broken firewall, you can't 
use this mechanism.  Here [link] are instructions on known-bad and 
known-good implementations".

We've been there with ECN.  We're there with different DNS equipment 
breaking AAAA (or anything except A) records.  We'll continue to get 
there.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "John R Levine" <[email-masked]>
Date: 19 Jan 2005 01:49:20 -0500

> site's zone) are behind such firewalls?

DNS servers, probably not many.  SMTP servers, lots of them.  They're
running Exchange, if they weren't behind a firewall they wouldn't last
five minutes.

> we need to care about it.

As Dan B. noted, the MS firewall is the biggest single collection of RR
brokenware, but there's plenty more in the form of obsolete versions of
BIND and other DNS software that people are still running.

I'm not saying that we should give up and never ever add a new RR type,
but I am saying that requiring a new RR is in 2005 a major bar to
widespread deployment.

Regards,

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Jan 2005 09:20:29 +0200 (EET)

> running Exchange, if they weren't behind a firewall they wouldn't last

Are big/significant exchange servers, receiving incoming mail, behind 
*such* firewalls?  I'd suspect most (and almost all bigger ones) 
Exchange servers would definately be behind a *real* firewall, not a 
proxy server by MS (or whatever causing the problems quoted here).

> but I am saying that requiring a new RR is in 2005 a major bar to

True, though if we're never going to use it, we're never going to get 
there...

I think the most important thing here is to recognize the scenarios 
where we absolutely want to get this deployed, versus those sites 
which would possibly want to use this thing (but can't, due to 
miscellanous brokenware).

We may need to make the deployment sufficiently easy for those we 
absolutely want to use this thing (e.g., very big mail providers, very 
big zone owners, ...?), but we *necessarily* don't need to do that for 
those who are not critical for the success of this solution.  They'll 
upgrade their brokenware if they see an incentive to do so. Otherwise, 
it's their mail that gets spoofed, or they cannot check the originator 
of the mail.  Why do we care?

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jan 2005 15:45:21 +0700

Date:        19 Jan 2005 01:49:20 -0500
    From:        "John R Levine" <[email-masked]>
    Message-ID:  <[email-masked]>

  | As Dan B. noted, the MS firewall is the biggest single collection of RR
  | brokenware, but there's plenty more in the form of obsolete versions of
  | BIND and other DNS software that people are still running.

His point was just that's there's lots of ancient stuff around, which can't
handle new types.   And that's both correct, and not very relevant.

The point you keep ignoring is that the only people who need to handle the
new type are those who want to use it (as client or server).   That is,
it is irrelevant that someone's system can't handle the BOZO RR type, if
they don't add it to their servers, and don't have clients that query for it.

This may be a good test of just how real the demand for SPF (or similar)
really is, and how must of it is just hype.   If you tell people that to
use SPF they're going to have to spend $'s to upgrade (or even
totally replace with something from a different vendor) their systems,
we'll find out just how important SPF really is to them, won't we?

If they're prepared to do that, then all this noise about new types being
hard to deploy will be just irrelevant, as people would be actively
deploying it.   If they're not prepared to upgrade, then clearly the
functionality being claimed as important, isn't really all that important
after all.

  | I'm not saying that we should give up and never ever add a new RR type,
  | but I am saying that requiring a new RR is in 2005 a major bar to
  | widespread deployment.

Only if you're trying to force widespread deployment of something for
which people see no benefit to themselves.   If the end users who have
to upgrade can see a genuine benefit in the upgrade, they do it.

Note here that the whole net doesn't have to upgrade to support a new RR
type - that's what Paul V's message was trying to illustrate.   SRV records
have been added, and are used.    Yet as djb's message indicated, there
are still zillions of servers around that have no idea what an SRV record
is, and have no chance of ever processing one correctly.   Yet everything
still works - those who need SRV have servers that handle it.   Those who
don't simply don't care - if their servers are OK for other reasons, fine,
if they're not, as long as they work for their actual needs, that's also fine.

kre

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 13:44:04 -0600

> site's zone) are behind such firewalls?

SPF is not just used in SMTP servers.  For example, SpamAssassin does
SPF checks and it is often run after the email has been delivered.
There is at least one version that runs after POP/IMAP.

For Microsoft's CallerID/SenderID, it is my understanding that they
primarily intended it to be part of the MUA.  Imagine every future
copy of Outlook having SenderID support built into it.

So, the answer to your question is that, yes, there are a lot of
machines that would be trying to run these checks from behind these
broken firewalls.

-wayne

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Jan 2005 20:41:58 -0500

At 12:40 AM 1/19/2005, Pekka Savola wrote:

>breaking AAAA (or anything except A) records.  We'll continue to get there.

And wer're there now with EDNS0 even though it's been in the protocols
for 5 years and still firewalls don't understand the DNS UDP packets can
be larger than 512 bytes.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Jan 2005 21:16:46 -0500

>but I am saying that requiring a new RR is in 2005 a major bar to

I think this is being overblown. You need to look at the interaction vector.
What DNS servers need to know about the new RRs?

The two endpoints:
one the SMTP server receiving the request and the other the domain that
is purporting to be the sender. They have every incentive to upgrade their
DNS Servers to support the new type. If they don't support it then the
query will fail anyway.
The only other ones that are involved in the lookup are:
the root servers, which really don't care about the type as they will only
hand you a referral anyway and in any case are regularly upgrade to support
new types;
the TLD's which again will just hand out a referral and are also
upgraded regularly.

  What other DNS's need to be involved and for what?

Danny

---

From: "John R Levine" <[email-masked]>
Date: 19 Jan 2005 21:33:57 -0500

> What DNS servers need to know about the new RRs?

Only the ones the serve them, but unfortunately the caches in front of
every client that want to use them need to know about them too.  In theory
caches should treat unknown RR types reasonably, in practice, a lot of
them don't.

Regards,

---

From: Danny Mayer <[email-masked]>
Date: Thu, 20 Jan 2005 00:36:34 -0500

>caches should treat unknown RR types reasonably, in practice, a lot of

Exactly which caches are you referring to? Unless you are doing forwarding
you shouldn't need to worry and if you are you should stop doing that
anyway as it really doesn't buy you much. It's the local DNS that needs to
understand the RR type as well as the clients themselves. If you are not
talking about DNS servers then it's irrelevant here.

Danny

---

From: "John R Levine" <[email-masked]>
Date: 20 Jan 2005 00:59:37 -0500

> Exactly which caches are you referring to?

Uh, the ones in front of the clients, like I said.  Surely you aren't
proposing that DNS clients should run without caches and hammer on the
servers.  The cache may well be on the same host as the client, but it's
still a cache and it can screw up.

> Unless you are doing forwarding you shouldn't need to worry and if you
> are you should stop doing that anyway as it really doesn't buy you much.
> It's the local DNS that needs to understand the RR type as well as the
> clients themselves. If you are not talking about DNS servers then it's
> irrelevant here.

If only life were that simple.  In an ideal world, everyone who wrote a
DNS cache or firewall proxy would have read and understood RFC 3597, and
caches and proxies would handle all RR types properly and transparently.
Unfortunately, in this world, things are a mess.  As I've pointed out in
several previous messages, hosts behind MS firewalls can't query for any
RR types other than the ones the firewall explictly supports, and I gather
that other caches have been known to screw up unexpected RRs as well.
That's the problem, that's why you have to be sure that the cache and, if
there is one, firewall in front of the client can handle new RRs, too.

Regards,