Subject: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal

From: Alfred Hönes <[email-masked]>
Date: Fri, 6 Nov 2009 22:02:05 +0100 (MEZ)

The recent I-D, "DNS Extensions to Support IPv4 and IPv6",
draft-li-dnsext-ipv4-ipv6-02, proposes a new specific QUERY TYPE
to pick up A and AAAA RRsets in a single DNS request.

This seems to be a specific solution restricted to a narrow,
yet frequent, desire / use case.

I suggest to expand on this proposal by defining a more versatile and
general mechanism that does not need to be changed again should any
new 'address' RRtype be defined in the future, and that will have
different other use cases for the pickup of 'grouped' RRsets
(e.g. TXT records together with PTR records on DNSBL lookups,
mail policy TXT RRs together with MX RRs, etc.).

This proposal is inspired by similar functionality present in DHCP
and an old, expired proposal to allow multiple queries in a single
DNS request.

It should help save round trips and eliminate the need to specify
dedicated additional section processing for some new RR types in
the future, saving additional, RR type specific processing logic in
authorities and caching resolvers.

Rough sketch of the idea:  << RR-Group Query >>

A new 'Query' RRtype, say "RGRP", is used to request the delivery
of an arbitrary set of 'data' RR types, specified in a bitmask --
similar to the one used in NSEC/NSEC3, but handed over in a new
EDNS option, say "RGMASK".

The semantics I envision for the authority/cache might be sketched
as follows:

-  CLASS-independent.

-  No Additional Section processing (beyond EDNS).

-  Any RRset matching (QNAME, QCLASS) with RRtype flagged in RGMASK
is returned -- similar to what is done for QTYPE=ANY queries with
a virtually restricted "set of interest", but more tightly controlled
as follows:

-  The RGMASK EDNS option is echoed back (iff the answerer understands
RGRP and this option).  Any bit still set in the echoed bit mask
indicates knowledge at the answerer of the corresponding RRset (with no
such RR present in the answer signalling per-RRtype selective NODATA);
clearing of a bit would indicate lack of knowledge of the corresponding
RRset and only be allowed only for cache servers, not for authorities.

-  It could be considered to use particular flag bit setting(s) to
request from a recursive resolver 'exhaustive' behavior, essentially
like an authority.

Rationale for using an EDNS option: It is expected that responses
to RGRP queries are larger and would generally benefit of increased
response size.  The proposal will only be implemented in "new" DNS
software that should support EDNS0 anyway.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 6 Nov 2009 13:19:50 -0800

Instead of creating a new query type, why not just issue ANY queries
on a new name?  E.g., instead of sending A/AAAA queries for host.dom,
just send an ANY query for _address._ip.host.dom.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Nov 2009 21:35:56 +0000

> From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
> Date: Fri, 6 Nov 2009 22:02:05 +0100 (MEZ)
> 

what a terrible idea.  we're not going to add yet another query before
the start of every tcp/ip session.  the way to handle this is to include
AAAA as additional data in A responses, and include A as additional data
in AAAA responses.

> ...

this should also be pursued, but not as part of deploying IPv6.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Nov 2009 16:52:14 -0500

> AAAA as additional data in A responses, and include A as additional data

So why doesn't this happen today?  What caused us not to choose that
path in the past?  (Something must have, but I've been unable to
figure out what.  I'd sure like to know, however, because I'm busy
having arguments over in behave about a related topic.)

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 6 Nov 2009 23:13:06 +0100 (MEZ)

> just send an ANY query for _address._ip.host.dom.
 
Matt,
The unreliable, informative nature of ANY has been discussed many
times, and it makes it impossible to rely upon ANY for this purpose.
With this in mind I came up with the proposed feedback mechanism
for RGRP.

  Alfred.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Nov 2009 22:32:24 +0000

> Date: Fri, 6 Nov 2009 16:52:14 -0500
> From: Andrew Sullivan <[email-masked]>
> 
> > the start of every tcp/ip session.  the way to handle this is to
> > include AAAA as additional data in A responses, and include A as
> > additional data in AAAA responses.
> 
> So why doesn't this happen today?  What caused us not to choose that path
> in the past?  (Something must have, but I've been unable to figure out
> what.  I'd sure like to know, however, because I'm busy having arguments
> over in behave about a related topic.)

because i didn't think about it or propose it during DNSIND's review of the
draft of RFC 1886, and then when i did propose it there was a Strong Desire
on the part of All Parties to Be Done and so we didn't want to pull the
covers off.  also, it was widely recognized that additional data could be
added at any time, and so the thought was, somebody would write it up later,
there was no reason to hold up the current draft.

nobody has written it up.

now, in the time since then, kaminsky showed us the nonwisdom of caching any
data other than the direct response to the question you asked.  so if we 
were to write this up today, we'd say, it has to be an authoritative answer
and the owner name has to exactly match the answer name.  or something.

(i sort of wish we had multiple question support.  if all the qnames are the
same, and all the qclasses are the same, and all the qtypes are different,
then we could reasonably fill the answer section with multiple rrsets.  would
have been nice.  at this point it would draw a lot of FORMERR responses and
so doing it would amount to another kind of pairwise protocol negotiation --
which if we're going to do we should do as part of EDNS somehow.  i digress.)

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 07 Nov 2009 10:23:53 +0900

> to pick up A and AAAA RRsets in a single DNS request.

That's an abandoned idea.

All of you stupid, read RFC1035

   The difficulty is that the presence of one
   RR type in a cache doesn't convey any information about the other
   because the query which acquired the cached information might have used
   a QTYPE of MF, MD, or MAILA (which matched both).
 
							Masataka Ohta

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 06 Nov 2009 21:33:19 -0800

On 6 Nov 2009, at 13:35, Paul Vixie wrote:

> the way to handle this is to include

I agree. FWIW, this is exactly what we do in Multicast DNS:

<http://tools.ietf.org/id/draft-cheshire-dnsext-multicastdns.txt>

8.2 Responding to Address Queries

    In Multicast DNS, whenever a Responder places an IPv4 or IPv6  
address
    record (rrtype "A" or "AAAA") into a response packet, it SHOULD also
    place the corresponding other address type into the additional
    section, if there is space in the packet.

In addition, if there isn't a record of one or other type, we indicate  
this using an NSEC record.

This is for cases like where an SRV response has an A record in the  
additional section but no AAAA. Including the NSEC asserting the  
nonexistence of AAAA records saves us having to do another round-trip  
to get the no-answer-no-error response telling us that the name has no  
AAAA records.

    In the event that a device has only IPv4 addresses but no IPv6
    addresses, or vice versa, then the appropriate NSEC record SHOULD
    be placed into the additional section, so that queriers can know
    with certainty that the device has no addresses of that kind.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 7 Nov 2009 16:43:47 +0900

On Fri, Nov 06, 2009 at 10:02:05PM +0100,
 Alfred Hönes <[email-masked]> wrote 
 a message of 71 lines which said:

> (e.g. TXT records together with PTR records on DNSBL lookups, mail
> policy TXT RRs together with MX RRs, etc.).

Or SPF and TXT together for SPF queries (RFC 4408, section 4.4).

> clearing of a bit would indicate lack of knowledge of the
> corresponding RRset and only be allowed only for cache servers, not
> for authorities.

Good idea and I specially like this clever detail (which addresses
Ohta's troll^H^H^H^H^Hremark).

---

From: Andras Salamon <[email-masked]>
Date: Sat, 7 Nov 2009 11:01:07 +0000

>RRset and only be allowed only for cache servers, not for authorities.

The meaning of set/cleared bits is unclear to me.

What is the right thing to do if:
1. a server receives one of these blob queries for type X and Y,
2. the cache contains an authoritative entry for type X,
3. the cache contains an NXDOMAIN entry for type Y?

Due to negative caching there seem to be three possible states:
present, absent, negative-present (this last being a weak proxy
for known-absent-from-zonefile).  Further, does "knowledge" mean
"authoritative" or "present in cache"?

-- Andras Salamon                   [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 7 Nov 2009 22:58:21 +0900

On Sat, Nov 07, 2009 at 11:01:07AM +0000,
 Andras Salamon <[email-masked]> wrote 

> 3. the cache contains an NXDOMAIN entry for type Y?

I don't understand. 2) and 3 cannot be true at the same time.

---

From: Andras Salamon <[email-masked]>
Date: Sun, 8 Nov 2009 10:45:02 +0000

>I don't understand. 2) and 3 cannot be true at the same time.

My mistake: I meant NODATA for type Y in point 3, not NXDOMAIN.
(RFC 2308 section 2.2.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 8 Nov 2009 20:38:26 +0900

On Sun, Nov 08, 2009 at 10:45:02AM +0000,
 Andras Salamon <[email-masked]> wrote 

> My mistake: I meant NODATA for type Y in point 3, not NXDOMAIN.

In that case, it is explicitely covered in Alfred Hönes' original
proposal: the bit "I know about it" is set both for type X and type
Y. And the answer includes only RRset of type X. And the stub resolver
algorithmically deduces there is a NODATA (which is consistent with
the RFC you quote).

We'll discuss it tomorrow if you want (outside of the WG because I'm
afraid there is no free slot in the agenda).

---

From: <[email-masked]>
Date: Sun, 8 Nov 2009 14:31:29 +0100

Dear Alfred, all,

Some comments below:

- I fully agree with the motivations of draft-li for optimising the delay the retrieve DNS records. The proposal can be enhanced to cover also IPv4-embedded IPv6 records. This proposal aims at decreasing the delay required to retrieve a valid record. Furthermore, it optimises the amount of issued requests by end hosts and may also reduce the load of DNS servers.

- A more generic solution to solve this issue (i.e., a single message enclosing a set of queries types) can be preferred than defining a specific solution for A and AAAA records. But, do we have other use cases (!# than the one defined in draft-li)?

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 6 novembre 2009 22:02
À : [email-masked]; [email-masked]
Objet : [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal

The recent I-D, "DNS Extensions to Support IPv4 and IPv6", draft-li-dnsext-ipv4-ipv6-02, proposes a new specific QUERY TYPE to pick up A and AAAA RRsets in a single DNS request.

This seems to be a specific solution restricted to a narrow, yet frequent, desire / use case.

I suggest to expand on this proposal by defining a more versatile and general mechanism that does not need to be changed again should any new 'address' RRtype be defined in the future, and that will have different other use cases for the pickup of 'grouped' RRsets (e.g. TXT records together with PTR records on DNSBL lookups, mail policy TXT RRs together with MX RRs, etc.).

This proposal is inspired by similar functionality present in DHCP and an old, expired proposal to allow multiple queries in a single DNS request.

It should help save round trips and eliminate the need to specify dedicated additional section processing for some new RR types in the future, saving additional, RR type specific processing logic in authorities and caching resolvers.

A new 'Query' RRtype, say "RGRP", is used to request the delivery of an arbitrary set of 'data' RR types, specified in a bitmask -- similar to the one used in NSEC/NSEC3, but handed over in a new EDNS option, say "RGMASK".

The semantics I envision for the authority/cache might be sketched as follows:

-  CLASS-independent.

-  Any RRset matching (QNAME, QCLASS) with RRtype flagged in RGMASK is returned -- similar to what is done for QTYPE=ANY queries with a virtually restricted "set of interest", but more tightly controlled as follows:

-  The RGMASK EDNS option is echoed back (iff the answerer understands RGRP and this option).  Any bit still set in the echoed bit mask indicates knowledge at the answerer of the corresponding RRset (with no such RR present in the answer signalling per-RRtype selective NODATA); clearing of a bit would indicate lack of knowledge of the corresponding RRset and only be allowed only for cache servers, not for authorities.

-  It could be considered to use particular flag bit setting(s) to request from a recursive resolver 'exhaustive' behavior, essentially like an authority.

Rationale for using an EDNS option: It is expected that responses to RGRP queries are larger and would generally benefit of increased response size.  The proposal will only be implemented in "new" DNS software that should support EDNS0 anyway.

Kind regards,
  Alfred HÎnes.

-- 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 9 Nov 2009 01:15:13 +0100 (MEZ)

Stuart Cheshire wrote:

>> AAAA as additional data in A responses, and include A as additional
>> data in AAAA responses.
>
>
>     In Multicast DNS, whenever a Responder places an IPv4 or IPv6 address

I also had this draft in mind.  But given the lack of acceptance of
these ideas (and other multi-question proposals) in the IETF this
did not seem a good base for a *new* proposal.

The drawbacks of Additional Data have become more and more evident
in the recent past, and Paul Vixie already has acknowledged that
in a follow-up message to Andrew's response to his posting.

There seems to be long established consensus that multiple questions (if
considered at all) need to be restricted to same-QNAME plus same-QCLASS.
Multiple Questions (QDCOUNT>1) incur the inherent problem that the
consistency needs to be checked, with many novel error scenarios.
Encoding a multi-question query in a way that inherently enforces
that match-in-QNAME-and-QCLASS restriction and is at least equivalent
(or even better) in terms of packet space requirements might turn out
to be a superior idea.

>     with certainty that the device has no addresses of that kind.

Additional Section processing for RR types that already do specify
that is entirely orthogonal to the problem considered and I would very
much prefer to leave it out of scope of this discussion.
There seems to have been consensus in the past that Additional Section
processing for new RR types should be avoided wherever possible.

> * Internet Architecture Board

The problem with similar specifications is that they *change* existing
specifications in an incompatible way, making attempts to do so a
horrible cross-country ride in the IETF.  Adding new elements and
confining new behavior to these elements seems to be more appreciated
in general, because the interactions needed at layer 8 and above are
less difficult then.  :-)
Specific exceptional rules based on RR type are inflexible and a
burden for server implementations.  I have tried to find a way to
escape these complications.

Given the apparent interest in my proposal (only sketched so far in
coarse granularity), I'll try to write it up in an I-D ASAP -- but
please admit roughly 3 weeks due to pending other efforts.

There remain design choices -- e.g., new meta RR type plus RGMASK
EDNS option (as noted in my proposal), or RGMASK alone, combined
with any 'Data' RR type (omitted from the initial proposal for
brevity) --, and incremental deployment considerations need to be
pursued in detail.  Hints on other existing use cases for the
"RR Group Query" are welcome in the interim!

A related request I'd like to recall:  Could we please consider
in the EDNS0-bis effort a means to signal the intended behavior
regarding EDNS options that the queried server does not "know" (as
in several routing protocols and RSVP) ?  The most easiest way to
do so would be to assign semantics to 2 or 3 most significant bits
of the EDNS option type, thus leaving all legacy options untouched.
Useful encoded behavior would include "mandatory to support",
"ignore if unknown", "echo unchanged", etc.
This would be a small "one-change-forever" detail, but a big deal for
the incremental deployment of new EDNS options, such as the RGMASK
proposed for RR Group Queries.  (See also the IAB deliberations on
protocol extensibility in draft-iab-extension-recs.)

More thoughts on this detail soon in a specific note on
draft-ietf-dnsext-rfc2671bis-edns0.

Kind regards,
  Alfred Hönes.

--

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Nov 2009 16:26:29 +0900

On Sun, Nov 08, 2009 at 02:31:29PM +0100,
 [email-masked] <[email-masked]> wrote 
 a message of 70 lines which said:

> But, do we have other use cases (!# than the one defined in
> draft-li)?

Mentioned by Alfred: TXT records together with PTR records on DNSBL
lookups, mail policy TXT RRs together with MX RRs.

Mentioned by me: SPF and TXT records for SPF lookups (RFC 4408,
section 4.4).

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 08:51:55 +0100

Dear Stephane,

Thank you for the clarification.

I think that a generic solution to retrieve several records using the same query would be more useful that restricting it to IPv4-IPv6 use case (which is by the way my interest as described in http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01#section-4.7).

Cheers,
Med

-----Message d'origine-----
De : Stephane Bortzmeyer [mailto:[email-masked]] 
Envoyé : lundi 9 novembre 2009 08:26
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal

On Sun, Nov 08, 2009 at 02:31:29PM +0100,  [email-masked] <[email-masked]> wrote  a message of 70 lines which said:

> But, do we have other use cases (!# than the one defined in draft-li)?

Mentioned by Alfred: TXT records together with PTR records on DNSBL lookups, mail policy TXT RRs together with MX RRs.

Mentioned by me: SPF and TXT records for SPF lookups (RFC 4408, section 4.4).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Nov 2009 15:57:47 +0000

> Date: Mon, 9 Nov 2009 01:15:13 +0100 (MEZ)
> 
> I also had this draft in mind.  But given the lack of acceptance of these
> ideas (and other multi-question proposals) in the IETF this did not seem
> a good base for a *new* proposal.

the ietf has not rejected this proposal.  it's simply never been heard.  you
should try writing up a unicast version of the proposal before you declare
that it's a bad basis.  ietf resists the multicast work because of personal
politics having to do with the approach stuart took and various competing
work to what apple has now widely implemented.  this one element, separated
out from the rest of "multicast DNS", and authored by someone other than
stuart, would find plenty of traction as i read these tea leaves.

> The drawbacks of Additional Data have become more and more evident in the
> recent past, and Paul Vixie already has acknowledged that in a follow-up
> message to Andrew's response to his posting.

i pointed to an area where caution had to be exercised by implementors, not
to any reason why this approach should be dismissed.

> consistency needs to be checked, with many novel error scenarios.

yes, and it still runs into the problem where RCODE=NODATA is ambiguous, so
i'm not in favour of this approach.

> Encoding a multi-question query in a way that inherently enforces that
> match-in-QNAME-and-QCLASS restriction and is at least equivalent (or even
> better) in terms of packet space requirements might turn out to be a
> superior idea.

agreed.  just as the wire protocol is wrong to treat rrsets as arrays of
<name,ttl,class,type,rdata> which must be reassembled by the receiver rather
than as <name,ttl,class,type,array of rdata> which could only be expressed
correctly, so it is wrong to express a question as a possible array of
<qname,qclass,qtype> rather than as <qname,qclass,array of atype> and wrong
to express RCODE as a scaler rather than as an array.  your proposal here is
a sensible way to work around these wire protocol defects.

> Additional Section processing for RR types that already do specify that
> is entirely orthogonal to the problem considered and I would very much
> prefer to leave it out of scope of this discussion.  There seems to have
> been consensus in the past that Additional Section processing for new RR
> types should be avoided wherever possible.

i do not agree with your description of current or past consensus on this
matter.  the add-A for AAAA, add-AAAA for A, approach would get traction
and would solve an important problem with no change to the wire protocol
and no new negotiations or statefulness.  this should be tried in parallel
with your more general proposal.

> A related request I'd like to recall: Could we please consider in the
> EDNS0-bis effort a means to signal the intended behavior regarding EDNS
> options that the queried server does not "know" (as in several routing
> protocols and RSVP) ?  The most easiest way to do so would be to assign
> semantics to 2 or 3 most significant bits of the EDNS option type, thus
> leaving all legacy options untouched.  Useful encoded behavior would
> include "mandatory to support", "ignore if unknown", "echo unchanged",
> etc.  This would be a small "one-change-forever" detail, but a big deal
> for the incremental deployment of new EDNS options, such as the RGMASK

michael graff is the editor of 2671bis and i am sure that he will take your
suggestion seriously.  send him the text you think should be added?

---

From: [email-masked]
Date: Mon, 9 Nov 2009 18:39:43 +0000

> the ietf has not rejected this proposal.  it's simply never been heard.  you

	actually, the IETF has rejected this work.  It was pushed out of 
	DNSEXT since there was too much on the plate (DNSSEC drafts) at the
	time, was moved to ZEROCONF, its own BOFs, then back to DNSEXT, where
	there was a mandate from the Chairs and AD to have LLMAR and Stewarts
	work resolve their differences and then bring things forward.

	From what I can tell,  since apple had a reasonable deployed base, and
	there was either apathy or outright hostility to the approach, they
	chose to keep working on these ideas independently.

	Ob: I -still- have a pending ID that is now pushing a decade that talks
	about an attribute of multicast DNS.  The holdup?  IETF process issues.
	the document itself has not chanaged in eight years - modulo required
	changes in boilerplate.

	That may not be outright rejection, but an indefinate tabling is as bad
	or worse.

> this one element, separated

	if you truely believe that - i would love to see any fact-based
	data to back up your faith.  why do you think things have changed,
	in either the WG, the IESG, or the IAB to foster/encourage this
	stuff?

--bill

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Nov 2009 19:15:49 +0000

> Date: Mon, 9 Nov 2009 18:39:43 +0000
> From: [email-masked]
> 
> > the ietf has not rejected this proposal.  it's simply never been heard.
> 
> 	actually, the IETF has rejected this work.

i appear to have misspoke.  the ietf has rejected apple's multicast dns
work, that's true.  instead of apple's busted-ass multicast dns we have
microsoft's busted-ass multicast dns, at least as far as the standards
are concerned.  (i note that apple's has greater market share.)

the work that ietf has not rejected, is "add A for AAAA, add AAAA for A".
that's what we need to write up and formally propose.  it'll sail through.

> > this one element, separated out from the rest of "multicast DNS", and
> > authored by someone other than stuart, would find plenty of traction as
> > i read these tea leaves.
> 

since i said "separated out from the rest of multicast DNS" and you answered
as though i had not said that, i think we're in different conversations now.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Nov 2009 10:34:44 +0900

On Nov 10, 2009, at 12:57 AM, Paul Vixie wrote:
> ietf resists the multicast work because of personal
> work to what apple has now widely implemented.

If Stuart's proposals are indeed currently being ignored because of some personal issues on the part of influential IETF participants, that needs to be fixed.   It shouldn't be the case that Stuart has to get someone to submit his drafts for him, and if that is the case we should not simply acknowledge it--we should do something about it.

The whole zeroconf fiasco is one of the worst things I have ever seen the IETF do, and to characterize it as an Apple vs. Microsoft thing is to rewrite history - it was a couple of IETF participants with no stake in the game who created the breakage, not Apple or Microsoft.

On the plus side, it's probably one of the main reasons why your Mac uses IPv6 instead of IPv4 to do ad-hoc communications with other macs on the same wire, so it was a good, if inadvertent, win for early IPv6 deployment.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 Nov 2009 22:36:28 +0900

On Sun, Nov 08, 2009 at 08:38:26PM +0900,
 Stephane Bortzmeyer <[email-masked]> wrote 

> afraid there is no free slot in the agenda).

You'll see it in the minutes but there were a few minutes left to
discuss your proposal. The general advice seems to be "Interesting,
deserves a proper I-D".

Off-mike, someone suggested, in a section of the I-D, to compare with
other solutions, such as sending N requests in parallel.

---

From: John Levine <[email-masked]>
Date: 10 Nov 2009 21:30:22 -0000

>lookups, mail policy TXT RRs together with MX RRs.

For DNSBLs, that's actually A and TXT records.  It would make sense
when either is requested to return the other in the additional
section.  I'll put that on the list for rbldnsd.

R's,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Nov 2009 10:04:40 +0900

On Tue, Nov 10, 2009 at 10:36:28PM +0900,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 13 lines which said:

> discuss your proposal.

I meant Alfred's proposal, sorry.