On Fri, 14 Nov 2008, Hardie, Ted wrote:
Since you now have two different meanings for what an A record is, you
now need two different code trees that understand what A records are,
and those code trees are not interoperable.
What do you mean by "interoperable" here? What would it mean for DNSBL
lookup code to interoperate with host address lookup code?
Standard libraries called in this circumstance won't work,
In the code I'm familiar with, most of the DNS lookups go through the
standard resolver library's res_search() interface, including host
lookups, MX lookups, DNSBL lookups, etc. The structure of the code would
not be the slightest bit different if DNSBLs had their own RR type.
and you'll need some mechanism to disambiguate the context so you know
when to call the special library for a-record-in-dsnbl versus the code
in a-record-in-standard-dns. At the moment, this is by application, but
it may not always stay that way.
I wouldn't say per-application: it's more like per-feature.
Note that I'm not arguing against a new RR type, I'm just trying to
understand the arguments against the de facto standard.
One significant advantage which I have not seen clearly articulated is
that a new RR type could combine the functions that are currently
performed by A records (bit vector) and TXT records (explanatory URL)
which could greatly reduce the number DNS lookups.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC BECOMING WESTERLY, 6 TO GALE 8, PERHAPS SEVERE
GALE 9 LATER. VERY ROUGH OR HIGH. RAIN THEN SHOWERS. MODERATE OR GOOD.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf