[Asrg] Another dnsbl draft, now standards flavored

Larry M. Smith SgtChains at FahQ2.com
Sun Jul 20 11:01:49 PDT 2008


John Levine wrote:
> The IESG has expressed interest in my dnsbl draft turning into a 
> standards track RFC rather than informational.  I've done another 
> version of it to make it read like a standard, and there's also a few 
> places where I invented some standard practices, e.g., standard test 
> entries for IPv6 DNSBLs.  Take a look, tell us if I got anything 
> seriously wrong.
> 
> We're in the I-D blackout period, so I've posted xml, html, and txt at 
> http://www.taugh.com/dnsbl
> 
> In related news, there WILL be an ASRG session in Dublin.  Who other 
> than me is planning to be there?
> 

I realize that its been years since I have provided any input on this 
document...  I do have some questions, perhaps they are better late than 
never.

--8<-----------------------------------------------------------------

 > 2.1.  IP address DNSxL
 >
[...]
 > If a range of addresses is listed in the DNSxL, the DNSxL MUST
 > contain an A record (or a pair of A and TXT records) for every
 > address in the DNSxL.  Conversely, if an IP address is not listed in
 > the DNSxL, there MUST NOT be any records for the address.
[...]

Currently DNSBLs are seeing a fair amount of requests for AAAA records. 
  I'm currently wondering if these could/should be treated as requests 
for A records, as it is quite possible that the DNSBL client is 
completely unaware that these requests are being done by the resolver.

--8<-----------------------------------------------------------------

 > 2.2.  IP address DNSWL
[...]
 > There is no widely used convention for mapping sublist names to bits
 > or values, beyond the convention that all A values SHOULD be in the
 > 127.0.0.0/8 range to prevent unwanted network traffic if the value is
 > accidentally used as an IP address.
[...]
 > 5.  Test and contact addresses
[...]
 > The combination of a test address that MUST exist and an address that
 > MUST NOT exist allows a client system to defend against DNSxLs which
 > deliberately or by accident install a wildcard that returns an A
 > record for all queries.  DNSxL clients SHOULD periodically check
 > appropriate test entries to ensure that the DNSxLs they are using are
 > still operating.
[...]
 > 6.  Typical usage of DNSBLs and DNSWLs
[...]
 > A client MUST interpret any returned A record as meaning that an
 > address or domain is listed in a DNSxL.  Mail servers that test
 > combined lists most often handle them the same as single lists and
 > treat any A record as meaning that an IP is listed without
 > distinguishing among the various reasons it might have been listed.
 > DNSxL clients SHOULD be able to use bit masks and value range tests
 > on returned A record values in order to select particular sublists of
 > a combined list.

Perhaps something could be said to warn about the domain name 
aftermarket, and that clients might want to quantify the return values 
to ensure that A records exist within 127/8.  Historically domain names 
hosting the DNSBL have expired and the new owners install wild-card records.

--8<-----------------------------------------------------------------

 > 2.3.  Combined IP address DNSxL
[...]
 > A single DNSxL could in principle contain both IPv4 and IPv6
 > addresses, since the different lengths prevent any ambiguity.  If a
 > DNSxL is represented using traditional zone files and wildcards,
 > there is no way to specify the length of the name that a wildcard
 > matches, so wildcard names would indeed be ambiguous for DNSxLs
 > served in that fashion.

Perhaps a recommendation that DNSBL operators not combine there IPv4 and 
IPv6 lists, instead using sublists for each could be inserted here.

--8<-----------------------------------------------------------------

 > 3.  Domain name DNSxLs
[...]
 > A few name-based DNSBLs encode e-mail addresses using a convention
 > adapted from DNS SOA records, with the mailbox name encoded as the
 > first component of the domain name, so an entry for fred at invalid.edu
 > would have the name fred.invalid.edu.doms.example.net:

Note that this can be ambiguous with hostnames and sub-domains.

--8<-----------------------------------------------------------------

 > 3.  Domain name DNSxLs
[...]
 > Name-based DNSWLs can be created in the same manner as DNSBLs, and
 > have been used as simple reputation systems with the values of octets
 > in the A record representing reputation scores and confidence values,
 > typically on a 0-100 or 0-255 scale.

This appears to be an historical reference to some name-based DNSBL and 
inserted here because of the reference...  Perhaps this would be better 
placed in section 2.3 where bit-masks and multi-responses are discussed.

--8<-----------------------------------------------------------------

 > 5.  Test and contact addresses
[...]
 > IPv6 based DNSxLs MUST contain an entry for ::2, and MUST NOT contain
 > an entry for ::1.

While a DSNBLv6 should never list ::1, 0000::/8 is reserved and (at 
least under theory) ::2 could be used in the future with unpredictable 
results for DNSBLs.

Perhaps is is best to keep the test addresses in ::FFFF.127.0.0.0/96.


SgtChains


More information about the Asrg mailing list