Subject: morishita-dnsop-misbehavior-against-aaaa

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 16:18:57 +0200 (EET)

Hi,

I think we should make:

draft-morishita-dnsop-misbehavior-against-aaaa-00.txt

a WG document.  This is a very important issue to cover.

Agreement/objections?

On a similar note, we should include
draft-ietf-dnsop-ipv6-dns-issues-02.txt to include more text to refer to
v6 DNS issues and operational guidelines (e.g. the draft above and more)  
or create a new document.  I'll be thinking of new text in the coming
days..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 14:44:19 +0000

> a WG document.  This is a very important issue to cover.

I agree.

> or create a new document.  I'll be thinking of new text in the coming

Also good, especially since it has expired - the latest version can be
found here for info:
http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-02.txt

Is Alain updating or looking for new authors to help?

Tim

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 19 Nov 2003 00:40:03 +0900 (JST)

> > a WG document.  This is a very important issue to cover.

	seconded.

itojun

---

From: Yasuhiro Orange Morishita / 森下泰宏<[email-masked]>
Date: Wed, 19 Nov 2003 02:45:12 +0900 (JST)

Pekka,

> a WG document.  This is a very important issue to cover.

Thank you for your comment. I'm glad to read this.
I agree of course. 

Jinmei-san, do we update the draft according to the current situation?

-- Orange
--
Yasuhiro 'Orange' Morishita
DNS Technical Engineer
Research and Development department, Japan Registry Service Co.,Ltd. (JPRS)
E-Mail: [email-masked] / [email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Nov 2003 03:43:19 +0900

Morishita san;

A nice document.

> Thank you for your comment. I'm glad to read this.

However, I think very few is AAAA (or, A6 :-) specific that it
should better be:

	draft-morishita-dnsop-misbehavior-00.txt

						Masataka Ohta

---

From: Rob Austein <[email-masked]>
Date: Tue, 18 Nov 2003 16:27:10 -0500

<hat=wg-co-chair>

  I've heard several requests to make this a wg doc, no opposition,
  and the authors appear to be willing to continue work on the doc.

  Any objections to taking this work on in the wg?

</hat>

<hat=just-another-bozo-on-this-bus>

  There are several directions in which this work could go.

  - Merge into the ipv6-dns-issues draft.

  - Expand into a "bad name server behaviors we have seen" doc, sort
    of the counterpart to the bad-dns-res draft.  As Ohta-san points
    out, much of what this draft discusses isn't really specific to
    IPv6 (except perhaps in the sense that some of the bad nameserver
    behavior is triggered by AAAA queries rather than A queries).

  - Continue in present form as a stand-alone document.

  In any case, I suspect that we should not be publishing the names of
  specific culprits in an archival document series.  Publishing a
  description of the bugs is ok.

</hat>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Nov 2003 23:35:19 +0100

> http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues 

I don't see this problem:

   "it is also obvious that it is important to
    avoid fragmenting the name space available to IPv4 only hosts. I.e.
    during transition it is not acceptable to break the name space that
    we presently have available for IPv4-only hosts."

If I run an IPv6-only service, why would IPv4-only systems need to be  
able to resolve my DNS names?

Obviously some public health type warnings wouldn't be bad, but somehow  
I suspect that people who might be inclined to run an IPv6-only  
nameserver for IPv4-relevant domains won't be deterred much by words of  
wisdom from the IETF.

---

From: Rob Austein <[email-masked]>
Date: Tue, 18 Nov 2003 18:31:48 -0500

> able to resolve my DNS names?

See draft-ietf-dnsop-ipv6-transport-guidelines-01.txt, soon to be in
WG last call.

The short answer is: sez here this is one Internet with two versions
of IP, and and the (public) DNS is supposed to look the same no matter
who or where you are, so anything in the (public) DNS that's visible
with one version of IP ought to be visible with the other.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 Nov 2003 00:16:17 +0000

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:

    Iljitsch> If I run an IPv6-only service, why would IPv4-only
    Iljitsch> systems need to be able to resolve my DNS names?

Let's turn that question around. Why should an IPv4-only system be
denied access to names of IPv6-only systems? Even though I don't run
ChaosNET or Hesiod, my name server supports these DNS classes and will
answer queries for names in them. Admittedly not in any meaningful
way, but they would give sensible answers for these classes.

Now to answer your question -- I hope you'll answer mine! -- there are
many reasons why an IPv4 only host would need to resolve your IPv6
only names. An IPv6 host might need to use a local IPv4-only DNS
resolver. Or a dual-stack resolver that chooses to send queries to you
over IPv4. Please don't confuse the means by which DNS packets get to
you with the actual clients that made the initial lookup. Secondly, my
IPv4-only resolver will need the capability to lookup your IPv6-only
names. Say to find out if you're using AAAA or A6 records. Or just to
know what the IPv6 address of one of those names is today. [For
instance to find out why we can't get mail to you as your SMTP server
is on an IPv6-only host (say).] Or to simply find out what names
actually exist. My client might like to have that info even if it's
just so it knows some name isn't reachable over IPv4. Yet another
reason is getting sane responses from the DNS irrespective of the
transport protocol used. Think of this as a variant on the nasties
Verisign caused when they put a wildcard A record into the .com zone
pointing at their Sightfinder service.

Now you might not care that the IPv4 world could break in weird ways
whenever it tries to get to your IPv6-only world because your bit of
the name space is misconfigured. However the former *will* care. And
they've got a much bigger installed base. :-)

Having IPv6-only name servers for useful zones will be very unwise for
the forseeable future. It would be as bad as putting all the servers
for say muada.com on RFC1918 addresses that aren't routed on the
internet.

There will be other reasons too. The ones above are enough to be going
on with.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: [email-masked]
Date: Wed, 19 Nov 2003 11:34:13 +1100

> able to resolve my DNS names?

	Because the IPv4 systems can then decide to use a proxy to
	connect to you.

	The caching nameserver doing the lookup may be IPv4 only
	but its clients may be IPv6 capable.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Paul Vixie <[email-masked]>
Date: 19 Nov 2003 01:10:12 +0000

other misbehaviours in the ipv6/dns transport arena include interrim bind8/9
behaviour (which will be fixed in the next releases of each, possibly with
patches) is the aggressive search for "missing" glue.  let me explain, and
then someone else can decide whether this needs to be added to some draft's
list of things that an implementation ought not do.

this has to do with the behaviour of caching/forwarding resolvers, which BIND
terminology calls "recursive name servers".

if you learn of the existence of an NS RRset, most likely due to reception
of a delegation response, but you do not know all of the glue (A and AAAA)
for those NS.NSDNAMEs, then it's probably best that you go out and fetch it
so that your own subsequent emissions of this NS RRset can include full glue.
(a common cause of knowing an NS RRsets without full glue is "truncation".)

however, it's important not to be overly aggressive in fetching such glue,
where one definition of "overly" is "trying to fetch what doesn't exist."
interrim (current, that is) BIND8 and BIND9 are overly aggressive, in that
they will search for AAAA whenever its absence is felt during the 
construction of an additional data section.  (and the root servers cried.)

the right thing to do is query for both A and AAAA if you lack both A and
AAAA.  this can lead to the unfortunate corner case where silent truncation
dropped an AAAA (or an A) RRset but left the A (or AAAA) in place.  it's
probably important to recommend the use of round robin to "spread the pain"
during such corner case events.  it's also important to prioritize the glue
so that the kind most likely to be missed if absent (A RRs) are done first,
since whenever AAAA RRs are going to be useful, EDNS0 will have been used.

is this an appropriate topic for the morishita or durand drafts?
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Nov 2003 20:27:10 -0500 (EST)

> way, but they would give sensible answers for these classes.

This is a good example. Neither ChaosNET or Hesiod have Root DNS entries.
You can't easily look up my hesiod entries since you can't find
nameservers for av8.net, class HS.  Hesiod and ChaosNET are therefore
"fragmented".  I recall much controversy about this many years ago, when I
wanted root DNS entries for Hesiod.  We learned to live with it.

In this case, I think simultaneous IPv6-IPv4 issue is too much of a
complicating issue, and similarly to Hesiod, is something that can easily
be worked around by those needing to do so by having separate networks
that are gateway'ed or tunneled, and run more like a simultaneous
novell/IPv4 networks.

To have an IPv6-only host interact with IPV4 DNS, one needs a dual-stack
host somewhere. Either the local IPv6 host is dual stack (not really
ipv6-only), or the DNS cache is dual stack, or a Ipv6-Ipv4 proxy. In any
case there can just as easily be two separate nameservices, just like the
case of Novell and IPv4.

There is no good reason for supporting both IPv4 and IPv6 in IPv4 DNS,
other than marketing IPv6 as a happy, compatible upgrade to IPv4. Of
course, that song and dance was given up some _long_ time ago.  Anyway, I
thought that this decision was already cast in stone, and that we are
stuck with it. Is it really possible that this decision might be
reconsidered?

		--Dean

---

From: Rob Austein <[email-masked]>
Date: Tue, 18 Nov 2003 20:44:37 -0500

At 19 Nov 2003 01:10:12 +0000, Paul Vixie wrote:
> 
> other misbehaviours in the ipv6/dns transport arena include [...]
> aggressive search for "missing" glue. [...]  is this an appropriate
> topic for the morishita or durand drafts?

I'd think so.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 19 Nov 2003 17:35:44 +0900

>>>>> On Wed, 19 Nov 2003 02:45:12 +0900 (JST), 
>>>>> Yasuhiro Orange Morishita <[email-masked]> said:

> Jinmei-san, do we update the draft according to the current situation?

I don't have an objection to making our draft as a wg document, and
yes, I'm willing to work on updating the draft if necessary.

Before doing this, however, I'd like to be sure about several points.

- what's the goal of this draft as a wg document?  An informational
  RFC (whether a separate document or a part of another doc)?  Though
  I believe our draft provides useful information, I'm not sure if the
  goal is the publication as an RFC (I'm just wondering, not making an
  objection to the publication).  If we are *not* going to publish the
  document, I don't see the strong need for revising the draft as a wg
  doc.

- if we are going to publish the document, we should remove concrete
  domain names and particular implementations, as Rob pointed out.
  (BTW: we, the authors, thought it might not be appropriate to
  describe live examples even in an I-D.  However, we finally decided
  to do so for this particular issue since otherwise the value of the
  document would be reduced much).

- when we revise the draft, either as an individual or a wg doc, we'll
  probably need to change the title to a more general one for the
  reason that Ohta-san and Rob pointed out (I thought Pekka already
  pointed this out when he first made comments on the document).  The
  wording of the draft will also need to be adjusted accordingly.

- because of the previous point, I don't think this document should be
  merged into the ipv6-dns-issues draft.  It may be a part of other
  document talking about general misbehavior issues, such as
  draft-ietf-dnsop-bad-dns-res-01.  I don't have a particular opinion
  on this, but in any event, I guess it's better to revise our draft
  (if necessary) separately at the moment.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 19 Nov 2003 09:32:43 +0100

Subject: Re: morishita-dnsop-misbehavior-against-aaaa Date: Tue, Nov 18, 2003 at 04:27:10PM -0500 Quoting Rob Austein ([email-masked]):

(I support the document being accepted as WG item, btw.)

>   description of the bugs is ok.

Strongly agree. This is WKA at its worst ;-) 

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

On the road, ZIPPY is a pinhead without a purpose, but never without a
POINT.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 15:39:45 +0200 (EET)

> 	draft-morishita-dnsop-misbehavior-00.txt

FWIW, I have no objections to generalizing it as long as we're not 
losing the original goal here (publish it for information) -- not make 
it a forever-running piece of broken DNS behaviour.

I'd prefer to get it revised and WG LC'ed within 6 months (hopefully
less), and published as Informational RFC within a year (at most).

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 20 Nov 2003 02:36:24 +0900

>>>>> On 19 Nov 2003 01:10:12 +0000, 
>>>>> Paul Vixie <[email-masked]> said:

> construction of an additional data section.  (and the root servers cried.)

Could you be more specific on "whenever its absence is felt"?  As far
as I can see in the code, BIND9 seems to limit itself about fetching
missing glues when it knows the glue RR for the particular type
doesn't exist (that is, the "NOERROR and an empty answer" case).  So,
if an appropriate negative TTL is provided, the fetching should be
leveraged.

I'm also not sure if this really makes the root servers cry.  Consider
the typical case (as of today) where an authoritative server only has
an IPv4 address (and the corresponding A RR is provided, of course).
When a recursive name server first tries to fetch A/AAAA RRs for the
authoritative server, it may ask a root server.  However, once the
recursive server knows the IPv4 address of the authoritative server,
succeeding queries for AAAA RRs will be directly sent to the
authoritative server, without making additional queries to root
servers (until the TTL for the cached A RRs expires).

A subtle situation may happen if the authoritative server "misbehaves"
as described in the morishita draft, though.  For example, if the
server ignores queries for AAAA RRs, the recursive server may try to
fetch the AAAA RRs in an "overly aggressive" way.

> since whenever AAAA RRs are going to be useful, EDNS0 will have been used.

I'd like to make the above points clear first, but anyway, another
possible way would be to introduce a timer before re-fetching missing
glues.  I think BIND[89] already takes this approach for the case
where a remote server that did not support EDNS0 has then supported
the extension.

> is this an appropriate topic for the morishita or durand drafts?

I don't think the morishita draft is an appropriate of the issue
itself, since the draft is concentrating on how an authoritative
server (badly) responds to AAAA (or non-A in general )queries.
However, it might be useful to mention the issue as an effect of the
misbehavior (i.e., the subtle situation I mentioned above).

					JINMEI, Tatuya

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2003 00:38:22 +0100

> denied access to names of IPv6-only systems?

Simple: because they can't use them as intended anyway.

> resolver.

How could an IPv6-only host make use of an IPv4-only resolver? But 
granted, this resolver could be dual stack and point to an IPv4-only 
resolver.

> Secondly, my
> is on an IPv6-only host (say).]

I agree this could be useful, but not to the degree that we should 
_require_ otherwise IPv6-only networks to run IPv4 nameservers.

> they've got a much bigger installed base. :-)

I don't believe running an IPv6-only network is misconfiguration. If 
v4-only users care, so much the better, then they can upgrade and visit 
my stuff over IPv6.  :-)

> the forseeable future.

Agree with this (but who are we to deny people the right to be uwise?), 
...

> It would be as bad as putting all the servers

... but not with this one. IPv6 and RFC 1918 are very different beasts.

> There will be other reasons too. The ones above are enough to be going

I suggest that the authors take this text and put it in the draft, as 
it currently only refers to the obviousness of the lack of wisdom of 
doing all of this.

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 Nov 2003 00:40:03 +0000

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:

    Iljitsch> IPv6-only service, why would IPv4-only systems need to
    Iljitsch> be able to resolve my DNS names?

    >> Let's turn that question around. Why should an IPv4-only system
    >> be denied access to names of IPv6-only systems?

    Iljitsch> Simple: because they can't use them as intended anyway.

Sorry, wrong answer. From time to time my IPv4 network will presumably
need to lookup the names of your IPv6 hosts. The answer from the DNS
will presumably be AAAA records which indiccate to my clients your
hosts are unreachable to them. That's fine: we're both using our hosts
and name servers as the DNS as intended. If my IPv4 hosts can't lookup
your names because they're on IPv6-only name servers, this means
you're not using the DNS as intended. My hosts can't get answers. This
is very different from getting a DNS answer which says some name is
unreachable.

    Iljitsch> I agree this could be useful, but not to the degree that
    Iljitsch> we should _require_ otherwise IPv6-only networks to run
    Iljitsch> IPv4 nameservers.

I think you've confused networks with the provision of DNS service.
What kinds of name servers you might or might not have on your network
isn't important to anyone but you. However the names of your IPv6
hosts should be capable of being looked up from the IPv4 internet. So
your IPv6 hosts should be served on an IPv4 name server somewhere.
Unless of course your net is completely invisible to the internet.

    >> Now you might not care that the IPv4 world could break in weird
    >> ways whenever it tries to get to your IPv6-only world because
    >> your bit of the name space is misconfigured. However the former
    >> *will* care. And they've got a much bigger installed base. :-)

    Iljitsch> I don't believe running an IPv6-only network is
    Iljitsch> misconfiguration.

That's not what I said. Please re-read the text above. A *name space*
which is only visible though IPv6-only name servers is misconfigured.
[Except for isolated networks, obviously.] Judging by what you say
below you seem to be agreeing with this.

    Iljitsch> If v4-only users care, so much the better, then they can
    Iljitsch> upgrade and visit my stuff over IPv6.  :-)

That's easier said than done. There's an awful lot of IPv4 only stuff
deployed that can't/won't be upgraded any time soon.

    >> Having IPv6-only name servers for useful zones will be very
    >> unwise for the forseeable future.

    Iljitsch> Agree with this (but who are we to deny people the right
    Iljitsch> to be uwise?), ...

It's not a question of denying rights. After all this is the internet
and people do unwise things all the time. What we're trying to figure
out here is how to make the DNS work sensibly for both IPv4 and IPv6
networks without breaking anything or fragmenting the name space and
preserving backwards compatibility with the installed base too. This
may well mean you have to put up with more IPv4 stuff than you'd like
for quite some time. Tough. :-)

    >> It would be as bad as putting all the servers for say muada.com
    >> on RFC1918 addresses that aren't routed on the internet.

    Iljitsch> ... but not with this one. IPv6 and RFC 1918 are very
    Iljitsch> different beasts.

On the contrary. In this context, they're identical. An IPv6 address
is essentially unreachable from an IPv4 host. RFC1918 addresses are
essentially unreachable on the internet. So if a name server is on an
IPv6 or an RFC1918 address, it can't be reached from the IPv4 internet.
Like a resolving name server, I see no difference: the end result is
the same in either case.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 20 Nov 2003 18:10:53 +0900

>>>>> On Thu, 20 Nov 2003 02:36:24 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> servers (until the TTL for the cached A RRs expires).

I guess I should have considered a bit more details in the second
point...  Perhaps the original post from Paul intended queries for
AAAA glues of the root servers.  If so, then this can make some of the
root servers cry since some root servers also (happen to) have the
authority of the root-servers.net zone.

But my first point should still apply: isn't it enough to limit the
frequency of refetching based on the negative TTLs?  Maybe not,
considering the scalability at the TLD cases.  But I want to be sure
if we're discussing this with the consideration on the rate limitation
or with the assumption that the current implementation simply
refetches missing AAAA glues without any rate limitation.

					JINMEI, Tatuya