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