At 08:53 AM 3/29/2005 +0100, Chris Haynes wrote:
"David MacQuigg" commented:
> At 01:09 PM 3/28/2005 -0800, William Leibzon wrote:
> >On Mon, 28 Mar 2005, Chris Haynes wrote:
> >
> >>The "Additional Information" section in DNS messages is, according to
> >>RFC1035,
> >>used only for responses. The obsolete RFC884 has some examples of it
> >>being used
> >>in association with _special_ queries (not any that are used by SPF). I
> >>cannot
> >>find any query type in RFC1035 for which the "Additional Info" field
is not
> >>_required_ to be <empty> while the query is being transmitted to the
server.
> >>
> >>Of course, there are a further 19 RFCs which update RFC1035, which I
have not
> >>studied. If you can show us a use of "Additional Information" somewhere
> >>in one of those, then I guess you will have made your point.
> >
> >None that I know of.
> >
> >>From a more pragmatic standpoint, I would be amazed if any of the
standard
> >>software suites (bind, etc.) expect to find an "Additional Information"
> >>section in an inbound query, or would be able to do anything with it if
> >>it were present. Nor, I hazard, would any standard clients be prepared to
> >>send it for you.
> >
> >Chris is right, but only partially. Basicly the interface to dns
resolver and
> >dns library that almost all programs use do not have direct access to dns
> >packet and let the library transform it into something usefull. At the
same
> >time bind library also includes low-level functions for directly parsing
> >dns packet (almost as if you were doing it byte-byte) and with those you
> >could potentially make use of this data. An example of utility that makes
> >use of low-level functions is DIG and you can see its code about it.
> >
> >However all this is not important considering that SPF does not have any
> >substantial influence on people who create dns software, many/most of them
> >actually dislike SPF project and will do nothing to accomodate us,
> >certainly northing close to what is being talked about. Additionally DNS
> >is the most widely used TCP/IP protocol and current specs are part of
hardware
> >implementation of many servers, routers, firewalls, NAT, etc. As Paul
> >Vixie said, it'd take 5 years (and this was his most liberal estimate) for
> >most of the clients and servers to have been updated that new extensions
> >can be relied upon by non-dns protocols.
>
> I'm disappointed that the designers of DNS did not have the forsight to
> anticipate that some later application might want to include additional
> parameters in a query. They even have a field for it, but if the spec
> doesn't say an implementation MUST ignore unexpected information in this
> field, we can expect that some will choke. It's good to see that SPF has
> left room for extension with the "unknown modifier" syntax.
>
> Maybe this was a deliberate design decision, to prevent people from using
> DNS as a general-purpose database.
Ah, maybe I was not clear about the situation. There are two aspects to the
protocol design:
1) A framework in which a number of individual query types can be defined,
2) The definition of each of these query types and of the parameters contained
in each query.
Today, there are 25-ish individual query types defined (A, MX etc.).
Potentially
there could be 64K.
Queries and responses use one or more of the 'sections' defined in the
framework. The definition of each query type says which sections may / must be
present (in query and then in response) for each such type. Generally
speaking,
the content of the 'query' section is query-type-specific, while the
<i>structures</i> of the other three sections are pre-defined by the
framework.
(The <i>semantics</i> of these other sections are, obviously, to some degree
query-specific).
Logically, what you appeared to be asking for is to find a way of carrying the
SPF-source IP address in an 'existing' query type, - A, MX or PTR. There is
nowhere within the query section for these _existing_ queries where you could
put that infomation, so I assumed you were proposing to use the Additional
Information section (which they do not currently use during the query
phase). I
was demonstrating that this probably cannot be done.
What _could_ be done within the overall framework is to define new message
types
(A2, MX2 ?) in which the information you want is carried in the _query_
section.
This is perfectly well supported by the architecture; you have only the
inertia
of the IETF and of bind etc. product life-cycles to content with.
Excellent! Why do we have such difficulty in these communications? This is
a common pattern. Someone with a broad perspective, but no specific
expertise says "Let's try X", and the experts respond "Utterly
impossible!". The generalist knows it has to be possible, but has to pore
over the docs and even the code to find the right terminology to
communicate with the specialist. It is hard to find an expert with a "can
do" attitude, someone like yourself who will spend even a few minutes
thinking "How would I do this, if I really wanted to."
Think, guys! Do you want to help solve the spam problem, or do you prefer
to show off your brilliance by shooting down new ideas with a flood of
mind-boggling techno-babble and cryptic sarcasm. I'm willing to accept my
share of the blame. Sometimes I provoke negative reactions because I sound
too sure of myself. In the rush of discussion, I neglect to say "I'm not
sure of this, but ..." Please let me know (off list if you prefer) when I
am doing this. Constructive criticism is always welcome.
IMHO there is nothing wrong with the framework architecture of DNS. Being able
to extend the information carried by an _existing_ query is an unreasonable
expectation.
This process of adding a new query type to the repotoire, by the way, is
in the
'roadmap' for SPF evolution. Microsoft started this ball rolling by getting
some kind of 'nod' from the IETF guardians of DNS that this would be
considered
favourably (see MXCOMP posts on this). This was intended simply as a
replacement
for the use of TXT by the SPF-family (which, of course, the DNS experts hate
with a passion), but I would think including the IP in this new query would be
an excellent idea.
Maybe we could sell to the DNS folks the idea that a general ability to add
a new query type is good for the future of DNS. This might motivate them
to add those low-level API functions, rather than just grudgingly add one
more hardwired query.
However, and here is the delightful irony: As William said (above) you need
access to the 'framework' APIs in your client resolver software to be able to
support a new message type. Microsoft reportedly descovered that in the
architecture of the resolver they have in all current and historic versions of
Windows, only the APIs for the existing message types are made available.
There
is no access to the low-level section-parsing functions, and no opportunity to
'drop in' modules for new message types. So they could only support any
new DNS
type (needed if Sender-ID is to migrate off TXT) by issuing a new Operating
System version and getting MS-MTA-user organizations to upgrade to that OS.
Life-cycles again!
Ah but Microsoft has a unique advantage in being able to patch their
operating system "on the fly". Seems like this could be folded into one of
their security updates. The Linux upgrades might be a little slower, I
don't know.
Adding an IP address to the query is not something we need immediately. I
brought it up now, so we can get the ball rolling if we decide it might be
useful in the future. The added field can be a SHOULD for the client and a
MAY for the server.
So, don't 'diss' the designers of DNS! They did what I consider an excellent
piece of engineering.
It does look like a good design. I'll withhold final judgement until I see
how DNS can provide for a new authentication query.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *