[rbldnsd] multiple TXT element answers?

[Michael Tokarev]

Kai Schlichting wrote:
> Greetings everyone - I recently joined the list.

You're welcome!

> Question: I am trying to run a mirror of the asn.routeviews.org zone, which
> provides BGP ASN origin and prefix for a given IP number, including wildcards,
> e.g.:
> 
> $ 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"
> 
> (the zone returns all hits, not just "patricia trie"-like longest prefix match)

It's ip4set.  So far so good.  I wonder what's the right-hand 'value' and why
the digits are different.. but that's another question.

[]
> My attempts to replicate this return of multiple TXT elements in quotes with rbldnsd have
> failed so far.
> 
> rbldnsd version 0.996 (19 Feb 2006)
> 
> I've tried an ordinary ip4set datatype (requiring a rewrite of the above data's left side),
> as well as a dnset datatype where one can more or less take the above data into the zone
> directly.
> 
> Problem: no matter how I try to define the TXT record, the result is always an entire quoted
>          string, quotation-marks are escaped with backslashes:
[]
> 55.5.12.asn.asnbl.org.  60      IN      TXT     "12163 12.5.48.0 21"
> 55.5.12.asn.asnbl.org.  60      IN      TXT     "\"12163\" \"12.5.48.0\" \"21\""
> 
> Is there a way to get what I need in order to be a mirror for this zone?

Not currently.  Oh well.

The quotes around text as 'dig' returns are not part of the data as
transmitted from nameserver.  It's part of dig output.  The issue is
in the way how TXT record is represented on the wire.  It's like
this (omiting some details):

  <rrtype=DNS_T_TXT><rrlen><tlen1><txt1><tlen2><txt2>...
                           [.......rrlen bytes..........]

Ie, inside one TXT record there may be several strings represented as
one-byte length followed by actual string bytes.  This is one record,
with multiple "chunks" -- another record will contain similar stuff.
Dig quotes each chunk, and it's how data is represented in master-file
format as well:

  xxx  TXT "abc" "def" "ghi" ...

here are 3 chunks of length 3 each.

"Normal" TXT record contains just one chunk, so there's only one
(tlen,txt) pair, and tlen == rrlen-1.

Rbldnsd does not enforce any 'structure' in the text entries.  It
returns them as-is (substituting $-stuff etc), ie, it's just one
plain string.  So it always generates "normal" TXT record (as many
of them as there are entries/lines listed).  There's just no code
to parse the strings into multiple chunks in there, no delimiters
defined, no code to collect the chunks into one TXT RR etc.  For
DNSBLs, the TXT template should be as simple as possible, and there's
no need for any structure - it's like a comment for the listing.

Ofcourse, when you place quotes into the rbldnsd's TXT template,
those quotes becomes part of the TXT value (single chunk of it),
and dig happily escapes them when formatting the result.

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).

 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...

/mjt