[rbldnsd] multiple TXT element answers?

[Michael Tokarev]

Kai Schlichting wrote:
> On Wed 05/17/06 at 4:20 AM, "Michael Tokarev" <mjt at corpit.ru> wrote:
> 
>> Kai Schlichting wrote:
>>> $ dig  1.55.5.12.asn.routeviews.org txt
>>> [...]
>>> ;; ANSWER SECTION:
>>> 1.55.5.12.asn.routeviews.org. 84426 IN  TXT     "12163" "12.5.48.0" "21"
>>> 1.55.5.12.asn.routeviews.org. 84426 IN  TXT     "12163" "12.5.54.0" "23"
[]
> sorry, I wasn't clear enough. The above 3 TXT fields are, in order:
> - origin ASN
> - network number
> - prefix length
> 
> e.g: 12.5.55.1 lives in 12.5.48.0/21 (and 12.5.54.0/23), with both prefixes
> announced by AS 12163
> 
> Have a look at http://linuxmafia.com/~karsten/Download/procmail-asn-header for
> some rather simplistic use.

In that script, I see:

RAW_ASN = `host -W 6 -R 10 -t txt $REVERSE_SENDERIP.asn.routeviews.org | \
    sed -e 's/.* text //' -e 's/"//g'`
                          ^^^^^^^^^^^
ASN = `echo $RAW_ASN | cut -d ' ' -f 1`
ASN_CIDR = `echo $RAW_ASN | cut -d ' ' -f 2`/`echo $RAW_ASN | cut -d ' ' -f 3`

So you're removing the structure from the TXT field, converting it to a space-
delimited list of fields.  So, after just removing the quotes around all the
strings and loading data into rbldnsd, *your* script will continue to work ;)

>>> Is there a way to get what I need in order to be a mirror for this zone?
> 
>> Not currently.  Oh well.
> 
>> It's not difficult to add the code to do so, but I've two questions
>> before:
> 
>>  1) is it really needed?  See above - I don't know what those numbers
>>    mean, and if the structure is really necessary (maybe just space-
>>    separating list is sufficient.. modulo the historical stuff and
>>    existing users).
> 
> it would be a novel use for rbldnsd - possibly opening the door to
> more creative DNS uses than strictly for DNSBLs.
> 
> When the routeviews.org-guys designed this DNS-based service (not a DNSBL,
> by any means), it was designed with the limitations of BIND - unfortunately
> users tend to follow and program code that makes use of the data as
> presented, so yes: this is essentially to accommodate an established,
> yet inconvenient format due to current use.

Well, the format is 3 fields.  Be them space-separated or in different strings...
Ofcourse, giving the above script, I can imagine someone uses something like:

 host ... | sed -n 's/.*text is "\([^"]*\)" "\([^"]*\)" "\([^"]*\)".*/\1 \2 \3/'

in which case, after quote removal it will continue to work.

Maybe it's simpler to change the format in the first place - I dunno for the
current usage.

>>  2) how to specify those chunks in the data files, preserving
>>     existing usage/users?  One idea comes to mind: if TXT template
>>     starts with double-quote, treat it as a series of chunks...
> 
> what level of effort would be required for this on your part?

It's not difficult, maybe 2 hours is a good estimate.  But it means all
the strings will take at least one more byte in memory, for all data
(number of chunks, or an indicator that there are chunks present or
something like that).  Plus I'm not sure for current *rbldnsd* usage --
I remember someone used quotes in their data that looked similar to
the above -- "aaa" "bbb" "ccc".  Not a big deal I think.

But again: if it's just 3 words, it does not matter if you pack them
as 3 different strings or a single space-separated string.  Modulo the
example above - Ie, the current usage.

BTW, you know, this change can be made in bind data files just easy -
just by removing 4 extra double-quotes in every TXT line ;)

> I am still investigating and in the process of 'selling' this idea
> (to use rbldnsd instead of the BIND-clunk) to the routeviews.org folks -
> so you indicating "yeah, I can hack that into the code in the next 2 hrs"
> would certainly give me proper direction....

I'd ask for the format change first... ;)  But yeah, see above - it's
quite easy.

/mjt