On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com>
wrote:
On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt
<schlitt(_at_)theworld(_dot_)com> wrote:
As the manager of a modestly large network I found the TXT record as a useful
tool in management of the network. Such a use was even suggested by other
system managers. That was a time when the Internet was a friendlier place.
Today I might do things differently and not make some of the TXT records
visible on the public Internet. But they would still be useful for internal
management.
TXT records can be useful for ad-hoc local configs and the SPF use has made
this harder. But it is hard to see how the SPF record makes that situation
any better.
Probably a better solution would be to take a chunk of the reserved RR code
space and stipulate that these have TXT form records so folk have 10,16 or so
records for this use.
In the longer term, the problem with the SPF RR is that it is a point
solution to 'fix' only one protocol. It is an MX record equivalent. Which was
OK given the circumstances when it was developed.
A shift from TXT to SPF records is not likely to happen for the niche SPF
spec. But may well be practical for a wider client/initiator policy spec.
Dear Phillip,
It seems many of the larger providers are unwilling to process SPF macros due
to inherent risks and inefficiency. Rather than accessing data using the DNS
resource selectors of Name, Type, and Class, SPF uses mechanisms above DNS to
utilize an additional domain, IP address, and email address input parameters
merged with results generated from a series of proscribed DNS transactions.
The macro feature was envisioned as leveraging these additional inputs to
influence query construction. It seems lack of support by large providers has
ensured scant few macros are published.
in the beginning, there were several wanting a macro language to managing DNS
processing with little idea where this would be headed. At the time there was
already a dedicated binary resource record able to fully satisfied the
information now obtained and used from SPF. Policy aspects of SPF are largely
ignored due to exceptions often required. An SRV resource record resolving
the location of a service could include an APL RR with CIDR information of all
outbound IP addresses. This would offer load balancing and system priorities,
while mapping outbound address space within two DNS transactions instead of the
111 recursive transactions expected by SPF. If one were starting over, DANE
TLS or DTLS is a better solution that should be even easier to administer since
it avoids a need to trust IP addresses and NATs. As with PKI, there are too
many actors influencing routing's integrity.
Regards,
Douglas Otis