In
<Pine(_dot_)LNX(_dot_)4(_dot_)62(_dot_)0508111430470(_dot_)2268(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
On Thu, 11 Aug 2005, wayne wrote:
* djbdns only returns 8 RRs instead of the complete RRset
(e.g. add a warning that some resolvers are known to give
incomplete information and using them in conjunction with SPF
checks can lead to errors.)
Which part of draft will it go into?
I'm not sure. It is just a TODO item...
* it is easier to convert IPv4 to IPv6 and work with just that
(this is just an implementors note.)
Don't add this in. Implementation notes should be few in protocol
specification draft.
This is why I throw this kind of stuff out. I can't say I liked it,
but both Julian and Shevek really liked it and I didn't see much
negative feedback about it when Julian suggested it.
* bugs in the ABNF
* "redirect=aaa" is accepted by 'name "=" macro-string' instead of
being rejected.
* "a:ab%-" is accepted because <domain-end> uses <macro-expand>
* CIDR values are not checked for the ranges
And this is ABNF how?
You can specify the valid CIDR values in the ABNF.
* the TXT and SPF RRs can get out of sync due to TTLs being different.
Therefore, we should allow implementations to freely choose which
record they want to use.
No, please don't make this change. The appropriate thing is to specify
instead that TXT and SPF RRs dns records MUST have the same TTL.
Having the same TTL doesn't solve the problem. See the thread started
by Mark Shewmaker. Basically, if you have one app that queries the
TXT only, and another app that queries both, the TTLs can get out of
sync. The TXT and SPF RRs do not form an RR-set, so the caching name
server will let them get out of sync.
-wayne