[rbldnsd] multiple TXT element answers?

[Kai Schlichting]

On Wed 05/17/06 at 12:53 PM, "Florian Weimer" <fw at deneb.enyo.de> wrote:

> * Kai Schlichting:

>> relevant entries for the example above:
>>
>> 55.5.12         IN TXT  "12163" "12.5.48.0" "21"
>> *.55.5.12       IN TXT  "12163" "12.5.48.0" "21"
>> 55.5.12          IN TXT  "12163" "12.5.54.0" "23"
>> *.55.5.12       IN TXT  "12163" "12.5.54.0" "23"

> I think most users were better off if you included only the longer
> prefix.  After all, that's the one which is relevant for Internet

that is a design decision by the routeviews.org folks, not me.
And users of the zone use code that finds the longest prefix - I have
personally modified http://linuxmafia.com/~karsten/Download/procmail-asn-header
to do that, for example.


> routing.  AFAIK, the current behavior is just a limitation of the zone
> generation process.

Rather: a BIND limitation:
the need to be able to supply answers to wildcard-matched
hierarchies (e.g.: any address in a /16), while other, longer prefixes
in the same space may exist. BIND does "any" matching, just like
rbldnsd's ip4set, as opposed to ip4trie.


> I'm also surprised that your BIND process reaches 800 MB in size; my
> own experiments led to a process size of 120 MB.  I used slightly more

that was their (routeviews.org's) word - including the other zone (aspath)
they serve.

> compact A records, and the global table was a bit smaller back then,
> but I would be surprised if BIND 9 needed more than 150 MB these days.
> (Provided that you optimize the zone properly.)  However, this is
> something the asn.routeviews.org operators need to do.

they are making efforts to write their own specialized DNS daemon - and
we all know how difficult of an effort that is (the word "architecture-
dependent multi-threading problems" has been mentioned more than once :)

If I can help it, and make it work with rbldnsd, that effort could be
safely abandoned - and I am at the beginning of that investigation right
now.

Thank you,
bye,Kai