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@xxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf