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.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net