Subject: RE: Issue: Add a new QTYPE

From: "Christian Huitema" <[email-masked]>
Date: Wed, 19 Nov 2003 11:21:51 -0800

>   | my strong recommendation is still that we include A RR's in the
> additional
>   | data section of any response to AAAA.
> 
> That might work, if we can get enough servers to actually implement
it.
> But it is a short term hack, which we'd need to eradicate eventually,
> and that's one reason I don't think it is a good idea.

We actually discussed and rejected the additional processing suggestion
-- it was present in the original draft of 1886. The argument was pretty
much the one Robert just gave: we will have to remove the processing
requirement eventually. It was also not clear that it would be useful in
most cases.

OTOH, I don't believe that the protocol police will jail you if you
actually return the A records in the additional section of an AAAA
query, especially if the AAAA record set is empty.

-- Christian Huitema

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 19:31:38 +0000

> requirement eventually. It was also not clear that it would be useful in

i believed i had shown during the debate over 1886, and i believe i have
shown again here today, that the lifetime of the data will be the same
as the lifetime of its usefulness.  this really is not a bad idea, folks.

> query, especially if the AAAA record set is empty.

isc has sometimes been accused of "legislating from the bench" by using
the power of the bind installed base to get things into the protocols
that ietf did not otherwise think was a good idea.  we won't be doing
that here.  unless there's consensus that adding A RR's as additional
data for AAAA responses (empty or not) is non-harmful, it won't happen,
or at least, it won't happen in bind.

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Nov 2003 16:27:38 +0700

Date:        Wed, 19 Nov 2003 19:31:38 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

I actually believe that Christian's suggestion is a good one.

  | isc has sometimes been accused of "legislating from the bench" by using
  | the power of the bind installed base to get things into the protocols
  | that ietf did not otherwise think was a good idea.

But this isn't that - no-one is actually saying that including A with AAAA
query isn't a good idea, what is being said is that legislating that it
must happen is not a good idea.

There isn't a lot about the additional section in the RFCs really,
most of what is there is an indication of what data should be added
(A when doing an NS or MX lookup, for example).   There isn't anything
which says what may not be there.

1035 says about the section just ...

	the additional records section contains RRs
	which relate to the query, but are not strictly answers for the
	question.

I think it is entirely reasonable to claim that A records relate
to an AAAA query (and AAAA records relate to an A query), and simply
include them - if the server author believes the additional information
will be useful.

We don't want to legislate it, because then you'd have to keep doing it,
long after it stopped being useful.   Simply doing it allows you to
simply stop doing it either when it is determined to not be useful (or
no longer be useful) without having to wait years for some IETF working
group to create a new RFC and remove the "AAAA causes A additional section
processing" rule.

As an additional example, if anyone actually used WKS records for anything,
it would be entirely reasonable to include WKS as additional information
in any A (or AAAA) lookup - allow the client to determine what services
are supported at the host they're considering contacting, so they can avoid
sending a SYN to a port that the server owner has stated in the WKS has
no server listening.    Of course, no-one actually uses WKS, so this would
be an utter waste of time and bytes - but back in the early days when WKS
was considered a good thing, this would be been entirely reasonable for
a server to have done - the available port information is clearly relevant
to many address lookups.   If some RFC had said to do that, I suspect that
BIND would still be adding WKS in the additional section (assuming they
exist in  the zone of course), even though everyone knows that no client
uses WKS records for anything, and that bothering to send them is pointless.

  | we won't be doing
  | that here.  unless there's consensus that adding A RR's as additional
  | data for AAAA responses (empty or not) is non-harmful, it won't happen,
  | or at least, it won't happen in bind.

I don't think anyone is claiming it is harmful, so I think you can just
about take that as a consensus already.   What some of us don't want to
do is actually tell people that they should do this, or suggest to any
client that they can actually expect it to happen.   Just allow the A
to land in the local cache when the AAAA lookup is done, making a later
AAAA query much quicker.    I don't see that hurting, regardless of
whether ANCOUNT==0 or ANCOUNT>0 in the response.

In another message you said ...

  | for it to be a short term hack in need of eventual eradication, there would
  | have to be a large difference in expected lifetime between "names for which
  | A RR's exist" and "clients who need A RR's".  i think that those two
  | lifetimes are in the same rough order of magnitude, and that by the time
  | you'd be thinking of eradicating it because the additional data wasn't
  | generally useful, the data itself would go into end-of-life. 

I believe that one possible scenario (not necessarily the one that will
happen, but certainly one possibility, that we need to allow for) is that
eventually all the backbones, will be IPv6 alone, and all hosts that
matter at end sites will have IPv6 enabled (essentially we'd have a
complete IPv6 net).

However, I expect IPv4 hosts to still be quite common in appliance type
devices (old ones perhaps) - say switches, bridges, ...  for quite a long
time - as long as they are still working just fine, and so no replacements
needed.   Those things generally need only be accessed locally - which is
fortunate for this.   To do that, I'd expect local IPv4 routing to still
exist inside end sites (and even private inside transit sites) long after
the backbone has stopped routing any IPv4 addresses.   In effect, the entire
IPv4 address space will have moved into the 1918 class.

If we reach that state, then we could simply allow people to populate
their local DNS with A records for those hosts that are IPv4 only, and
perhaps for a few servers that they need to be able to contact.

As long as everyone (those ancient hosts excluded of course) does AAAA
lookups first, and attempts an A lookup only if the AAAA fails (NODATA),
then all this works, without needing any two faced DNS (or DNS views,
or anything else as ugly) to support it.   But at this point we most
certainly do not want to include A records with the AAAA responses.

This is easy if it is OK to simply install a DNS server that doesn't
do that - much harder if there's an RFC out there somewhere that says
that A additional records in AAAA answers should be done, and consequently
all DNS servers do that.

kre

---

From: Paul Vixie <[email-masked]>
Date: 20 Nov 2003 20:02:59 +0000

Robert Elz <[email-masked]> writes:

> ...
> ...

and yet if bind is the only implementation who does it, it won't have much
impact.  so how about instead of legislating it, we (namedroppers) authorize
it as an optional practice, and perhaps recommend that it be configurable?
-- 
Paul Vixie