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(_dot_)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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg