Alan DeKok wrote:
Does that extensibility have to exist in DNS records?
I think that's the point of contention, here. Hadmu
was flamed mercilessly for proposing to put policy
records somewhere else, as they were too large to be
"proper" for DNS.
He's right, IMHO. DNS is not a general-purpose directory, and the extra
strain on DNS servers might not be palatable to everyone.
Jim Lyon wrote:
3. It MUST be possible for EVERY organization who
chooses to, to publish their policy data in such a
fashion that fallback to DNS over TCP is not required.
Indeed. Not only DNS fallback to TCP is largely untested, but there are
huge numbers of firewalls and access-lists out there that allow UDP/53
but not TCP/53. In many situations, the network admin has elected to
open TCP/53 only to a small set of semi-trusted hosts, such as other DNS
servers that are doing zone transfers.
The issue here is as follows: in hardened environments, there is not a
single TCP listener open from the outside to the DNS server (granted,
telnet and SSH are open, but same as TCP/53 only to a small set of
hosts). Opening TCP/53 to everybody instead of a small set of trusted
DNS server does make the DNS server vulnerable to SYN flood attacks and
more generally to any TCP vulnerability.
It is to be expected that the typical answer when asking to open TCP/53
will be something along the lines of "It has worked just fine for the
last 15 years, I am not going to open this whole new can of worms and
compromise security on external DNS servers to test that new thing that
nobody's used more than 2 weeks". I am not arguing about the validity of
the opposition, I'm just saying that what's above has to be accounted
for.
Alan DeKok wrote:
If the policy records are going to be huge, and can't
go in DNS, then they can go off-line (WWW, as Hadmut
suggested),
This is floating around the SPF mailing list:
v=spf2 xml=http://www.schmerg.com/spf.xml mx -all
It does have its dark sides, but there are a few benefits, such as using
HTTPS instead of HTTP without having to re-invent the wheel.
Clifford Hammerschmidt wrote:
Also note that the recent poll on the SPF mailing list
came out 12:1 against XML, and there is now talk of
forking SPF should XML be introduced. (Some already
want to fork based on it's consideration alone.) If
MARID continues to consider XML it should also start
thinking about how it's going to generate buy-in from
the existing SPF community to prevent a fork from
happening should XML be adopted in the end.
Indeed. I would suggest making XML optional or at least looking the
other way when seeing implementations that ignore it.
As a publisher, I like this:
Tim Meadowcroft wrote:
Similarly a publisher can choose to
publish either or both records
SPF, no XML: v=spf2 mx -all
XML, no SPF: v=spf2 xml=http://www.schmerg.com/spf.xml
Both: v=spf2 xml=http://www.schmerg.com/spf.xml mx -all
About requirements:
Jim Lyon wrote:
I would humbly suggest that people who don't like
XML, or don't like TXT records, or don't like
something else, either need to argue that the above
requirements aren't appropriate
I think they are reasonable, although I would add the following,
understanding that what's below is somehow redundant with what you
wrote:
- We MUST NOT require modifications to a large number of existing DNS
servers.
- We MUST NOT require modifications to a large number of
firewall/router/access-list configurations.
- Domain owners MUST be able to choose whether they want to publish a
TXT record, or XML, or both.
or they need to explain why their favorite alternative
does a better job than the current design of meeting the
above requirements.
I see three issues with the current design:
a) There will likely be issues with record size, such as:
Clifford Hammerschmidt wrote:
Also note that TXT records are limited to 127 or 255 bytes
by some nameservers, not the full 512 reserved for the entire
packet. Most XML records will exceed the 127 byte limit very
fast and thus break point 1 of your requirements.
b) Setting aside a) for the moment, I have not encountered difficulties
getting a 50-byte TXT record published, but I would expect large numbers
of DNS administrators screaming bloody murder about 512-byte records. It
will not take much time to count how many MX queries one gets, and do
some simple math adding 512 bytes to the current size of an MX reply.
DNS admins of large organizations or who provide DNS services to large
number of domains will not like how this projects.
c) Setting aside a) and b), the 512-byte limit remains. This does not
look good to me in terms of extensibility: if for any reason in the
future we need 513 bytes we'll have to go over deployment obstacles all
over again.
This appears to me as one solution that is in the middle of the road
v=spf2 xml=http://www.schmerg.com/spf.xml mx -all
Michel.