Subject: RE: TECH-ERROR: DNS Record Types

From: Ólafur Guðmundsson<[email-masked]>
Date: Thu, 02 Sep 2004 16:08:53 -0400

At 19:50 31/08/2004, Jim Lyon wrote:

>  On Saturday, August 28, 2004 at 7:56 PM,  Ólafur Guðmundsson wrote 
> (about DNS record types):
> > The fundamental difference between your position and mine is
> > you: want everyone to be compliant at all times.
> > me: Specify clearly fully compliant state and tolerate non compliance
> >      during phase-in.
>
>This is the crux of the disagreement.  However, there are at least two 
>relevant phase-in periods:
>
>1.  In the first phase-in, mail senders begin to publish records, and 
>those mail senders who need to begin to add additional headers.
>
>2.  In the second phase-in (more relevant to this discussion), people with 
>"challenged" DNS implementations begin to publish and/or query for the new 
>record type.
>
>The problem is that the first phase-in lasts months, but the second 
>phase-in lasts many years. (As I mentioned previously, it's at least 10 
>years before the number of installed Microsoft OS's with lousy DNS 
>implementations becomes small enough to ignore.)
>
>So, given that Ólafur's "short term" isn't in fact short, my point still 
>stands.  Require (MUST) TXT records and encourage (SHOULD) new record types.

I disagree: we are designing a protocol for use on the Internet,
as explained to your colleague before on this mailing list in:
         http://www.imc.org/ietf-mxcomp/mail-archive/msg01853.html
your set up its classified as "not being on the Internet" as you are
sitting behind a broken middle box.
IMHO we need to document protocols in such a way that it is clear
the middle box is the BROKEN component. That is what the current
text does.

A number of working groups have faced a similar issues before, whether
to include constants placed by exiting limited functionality middle boxes
in the protocol or to force updates. In every case I have seen so
far the WG's have gone with "update or no play".

There are number of other possible solutions then just upgrading
all of your infrastructure.  Those include:
   +     placing a modern DNS recursive caching server inside your
         firewall and query it instead off what you're querying now.
         (I'm aware of at least 5 different ones that pass unknown types
         that are available today including one from Microsoft).

   +     another alternative it is to use a more modern Windows DNS library
         than you are using today.

In short there are other ways to quickly overcome your current bad
design. If fighting SPAM is important to this particular organization
we have to assume that they are willing to make changes to take
advantage of SPF records sooner than in 10 years.

Its counterproductive to keep harping on the same points that had
been rebutted number of times both on the mailing list and in the
working group meeting in San Diego. Unless other members off the
working group come forward and say they had the same problem there
is no need to tune a protocol around somebody's bad implementation
choice!

>Ólafur also worries that if we go this route, there will never be a time 
>when publishing only an SPF2 record becomes acceptable.  This isn't 
>necessarily so.  There are two possible futures:
>
>a. "Challenged" DNS implementations get fixed over time, and more and more 
>people come to query/use SPF2 records.  Eventually, a new standards action 
>requires the new record type and deprecates use of TXT records.
>
>b. "Challenged" DNS implementations continue to be plentiful over 
>time.  In this case, we'd sure look stupid of we followed Ólafur's approach.

Below (in PS) is a simple script that uses nslookup to check if your
host can get unknown types from my DNS server. Just open
Command Prompt window and after typing "nslookup" paste this text,
if the output scrolls over many pages, you get unknown types.

>Assuming that we go with MUST for TXT records now, I submit that a 
>built-in opportunity to revisit the issue is when SenderId is considered 
>for advancement from Proposed Standard to Draft Standard or Internet 
>Standard.  Should upgrades to DNS servers proceed faster than the 
>standards track, it's not hard to convene a working group to reconsider 
>this issue.

process issue: changing the SHOULD and MUST around will likely require
that the documents be recycled at proposed standard.

         Olafur

PS: Commands for nslookup to check if a query will return UNKNOWN types.
----cut here--
set debug
set type=txt
set class=chaos
version.bind.
set type=any
set class=in
set domain=test.ogud.com.
ssh
unknown
--- end of cut ---

First this script attempts to get version information from server.
Then it queries for all types at two names, one contains SSHFP RR that
was defined this year (not yet an RFC) but type code allocated.
The second name is contains lots of records of different types and
results in a 782 byte answer. If the only RR you see is the TXT Record
then you are behind one of the evil bad Middle boxes.

Feel free to send me the results of running this nscommand or
the corresponding Unix shell script at this link:
         http://stora.ogud.com/DNSSEC/unkown/unknown-types-script.sh
Here is the Nslookup command sequence:
         http://stora.ogud.com/DNSSEC/unkown/nslookup.cmds

---

From: "Jim Lyon" <[email-masked]>
Date: Thu, 2 Sep 2004 14:12:33 -0700

On Thursday, September 02, 2004 at 1:09 PM, Ólafur Guðmundsson wrote:
> ... your set up its classified as "not being on the Internet"

In other words, you're willing to pretend the problem doesn't exist, by declaring that everyone with the problem isn't on the Internet.

The real issue here is that this technology isn't useful unless almost all mail senders publish records.  Telling people that they can't publish before upgrading software (and changing vendors too) means that they just won't publish.

> working group meeting in San Diego.

My recollection of the meeting in San Diego was that the consensus favored what the protocol-02 draft said, which is quite different from the current draft.

> host can get unknown types from my DNS server.

Here are results (debugging output removed for brevity) from my run of your script:

C:\projects> nslookup
Default Server:  red-dns-01.redmond.corp.microsoft.com
Address:  157.55.254.211

> version.bind.
Server:  red-dns-01.redmond.corp.microsoft.com
Address:  157.55.254.211
*** red-dns-01.redmond.corp.microsoft.com can't find version.bind.: Not implemented
> set domain=test.ogud.com.
Server:  red-dns-01.redmond.corp.microsoft.com
Address:  157.55.254.211
*** red-dns-01.redmond.corp.microsoft.com can't find ssh: Non-existent domain
> unknown
Server:  red-dns-01.redmond.corp.microsoft.com
Address:  157.55.254.211
*** red-dns-01.redmond.corp.microsoft.com can't find unknown: Non-existent domain
> ^Z

In other words, I'm behind one of your "evil, bad middleboxes". The only way to access your DNS server is through the Windows APIs, not by directly sending DNS packets.

The point is that many other people are too.  If the goal is interoperation, we need to take these people into account.

-- Jim Lyon