[rbldnsd] Re: TODOs for rbldnsd

[Michael Tokarev]

Bruce Gingery wrote Sun, 9 Mar 2003 03:17:55 -0700 (MST):
> You wrote:
> 
>>I had written:
>>
>>> In this patch, both the opening of the PID file and the write+close
>>> are conditioned on !nodaemon -- so that foreground operation ignores
>>> the added "-p </abspath/pidfile.pid>" parameter, even if given.
>>
> 
>>Umm...  why ignore parameter if it is given?
> 
>   Because it's not applicable, and shell aliases are convenient
>   for commandlines -- but could have an "-n" appended ...
> 
>        alias dorbld="rbldnsd \$1 [flags] [zones] ..."
> 
>        dorbld -n
> 
>   Since it's the PID of the _backgrounded_daemon_process_ that is
>   written to the pidfile, and there is no such backgrounded daemon
>   when "-n", it just fits the definition.

Ok if it's really backgrounded daemon's pid.  Well... redone your
changes.

>>TCP is mostly for AXFR.  Normal DNS answers are limited to 512 bytes..
> 
>   Well, UDP answers are limited to 512 bytes by single-packet reply
>   definitions.  But, no!  TCP is for any response that will not fit
>   in one packet.  Add 6 NS records with poorly compressable long names
>   to one-or-more A records (or CNAMEs if implemented) and potentially
>   AAAA records, and a long TXT or more, and it quickly grauates to TCP.

Well, that's a problem, really.  I dislike DNSBL servers which requires
TCP mode - and unfortunately, there are many of them out there.  What a
waste of resources/traffic, after all, for a single yes/no (in case of
A RR) answer, get first 512 bytes using UDP and reconnect using TCP to
get rest of 600-byte packet...

I don't really know DNS well.  Maybe you may answer two questions:

  - is it ok to have AUTORITY section (with a list of NS RRs), but NO
    ADDITIONAL section (where list of As for those NSs are provided),
    at least in "normal" (non-NS, non-SOA) answers?

  - and, why not use the following structure:

    dnsbl.example.org NS ns.example.org
    ns.example.org A 1.2.3.4
    ns.example.org A 2.3.4.5
    ns.example.org A 3.4.5.6
    ...

    so only one NS record will be required, and all names are well-
    compressable?  Well, this requires knowlege IP addresses of all
    nameservers, and may be prone to administration difficulties
    (one may change A RR for his own nameserver and forgot to notify
    others).

>   In 1998 or so, many people were starting to discover firewalls.  There
>   were bizzare generic instructions that could still be found on the web,
>   I think, that recommended blocking TCP to nameservers except from
>   hosts that are allowed AXFRs.  It was wrong advice.  Broke MANY
>   inexpertly administered services.  My guess is that quite a number
>   of SERVFAILs are still because of that.

well... yes.

[]
>>The only problem is that, at the same time, I want to be able
>>to "derive" SOA serial number from the date of data file, and
>>it's not obvious how to avoid clash with SOA specified in
>>"generic" zonedata, and where to find other fields required
>>for SOA if only one zonefile is given like currently.
> 
> 
>   I would still prefer that zone serial numbers be generated
>   externally from the daemon.  But a sub-zone file does NOT
>   (in BIND) need to have the same serial as the parent zone.
>   A new SOA interposes where it exists in the dot-divided
>   hierarchy.

That's ok.  Maybe I missed something, maybe you misunderstood
me.  I didn't talk about subzones, but about the same zone:

zone bl.example.com {
   ip4vset:/file/name/ip4vset
   generic:/file/name/generic
}

in ip4vset:
   127.0.0.2 :127.0.0.2:Test entry
and in generic
  @ NS ns.example.com
  @ SOA ns.example.com. dnsadmin.example.com (1234 3H 1H 1D 3H)

becomes

   2.0.0.127.bl.example.com A 127.0.0.2
                            TXT "Test entry"
   bl.example.com NS ns.example.com
                  SOA ns.example.com. dnsadmin.example.com (1234 3H 1H 1D 3H)
   about.bl.example.com TXT "about example.com blocklist"

That to say: a zone is composed of several independant datafiles,
all about the same zone.

[]
>     etc.  Although NS records are provided, the hosts carrying the
>     parent zone(s) may NOT be authoritative for given sub-zones.

Sure.  Just like root or .ru nameservers aren't autoritative for
corpit.ru domain.

>     The NS records in the parent zone for a subzone, SHOULD match
>     the NS records in the subzone for the subzone.

Well... yes.  In fact, BIND behaves somewhat strange with ANY
record (except of NS) present in parent zone.

>     Cacheing Mirrors MAY try to follow all the trails, for AXFRs,
>     and raise errors when they're unable to access a sub-zone for
>     which they're not authoritative.  That's a bug (e.g. in bind).
> 
>>Currently, rbldnsd (and DJB's rbldns) just refuses the request, and if
>>sendmail is asking local named cache, named returns SERVFAL and the whole
>>system does not work.
> 
>   Why not return NXDOMAIN for any specific query for which you don't
>   support the record type?

Two reasons.

  - in additional to queries, there are other operations (AXFR being
    one) - it's funny to return NXDOMAIN to AXFR request.  Hmm... Well,
    I need to study DNS spec once more, I fell like something is wrong
    in my mind here.

  - and for this specific AAAA example: this is even more idiotic traffic,
    in addition to UDP vs TCP.  IPv6-enabled Sendmail (as seen on Solaris)
    will query 2.0.0.127.bl.example.com AAAA first, will get NXDOMAIN, and
    when will requery (if at all) A RR.  It should not query for AAAA in
    a first place, OR rbldnsd should return something meaningful to AAAA
    query - I'm just not sure how DNSBL should behave in IPv6 environment
    (note: actual RR value is almost always irrelevant here, only presence
    of record matters).

> Here's some notes you might find useful ...

This reminds something to me... dejavu?.. :)  But thanks.

[]
> ======================================================================
>         AXFR    QueryType=252
>         MAILB   QueryType=253
>         MAILA   QueryType=254
>         *       QueryType=255
>         IXFR    QueryType=6 ??? rfc1995
> ======================================================================
> Class IN         1      Internet
> Class CS         2      CSNet (obsolete)
> Class CH         3      CHAOS
> Class HS         4      Hesiod
> 
> Class *         255     All/Any Class -- invalidated in BIND as of
> 			v8.something because of a security hole I
> 			pointed out to Vixie.  Might have been a temp
> 			disabling.

Interesting.


/mjt