Subject: [dnsop] WG Last Call: draft-ietf-dnsop-misbehavior-against-aaaa-00.txt

From: David Meyer <[email-masked]>
Date: Tue, 23 Mar 2004 10:09:08 -0800

All,

This is a WG Last Call (WGLC) for comments on "Common Misbehavior
against DNS Queries for IPv6 Addresses",

http://www.ietf.org/internet-drafts/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt

Please review the document carefully, and send your feedback to
the list.  Please also indicate whether or not you believe that
this document is ready to go to the IESG for Informational.

The WGLC will end on Wednesday, 07 April 2004, at 1500 PST.

Thanks, 

Rob and Dave

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Tue, 23 Mar 2004 22:53:42 +0100

Please see some remarks attached. I went into as a first time reader. My 
global remark is that it tells me where the problems are rather than how to 
solve them (subjective global feeling). When you compare with 
Postel/Mokapetris texts, there are less real practical examples. I would 
suggest to describe a configuration with all the possible cases and to use 
it to document each point. I know it is complex but couldbe usefull.
Thank you.
jfc morfin

1.2 Independence of DNS Transport and DNS Records

    DNS has been designed to present a single, globally unique name space
    [6].  This property should be maintained, as described here and in
    Section 1.3.

| the meaning of the word "global" differs in American and in English.
| the reference to RFC 2826 is inadequate. The reason why is that RFC 2826
| is for information, is ambiguous and over disputed. RFC 883 says the
| same thing better - even if contradicted by RFC 882 at the time.

| When introducing a tool of globality such as IPv6, it is inappropriate
| to refer to obsolete documents. RFC 2826 is obsoleted by ICP-3 which
| considers that future (IPv6?) might lead to a non unique authoritative
| root file.

| the DNS has not been designed to present "a" single unique name space.
| The current use of the only "IN" RR leads to that. As an example the
| preparation of the 2005 WSIS in Tunis considers the demand of the users
| as the defintion of "Tunnet". The use of a "TN" RR would permit to
| test them without disrupting the current Internet. This kind of
| experimentation, under these terms, is what is called for by ICP-3.
| The experiementation of new IPv6 features should be proposed under
| an experimentatal name space, for example "I6". This RFC should
| document it as a way to transition and safely experimenting.

    In DNS, the IP version used to transport the queries and responses is
    independent of the records being queried: AAAA records can be queried
    over IPv4, and A records over IPv6. The DNS servers must not make any
    assumptions about what data to return for Answer and Authority

Durand, et al.            Expires July 1, 2004                  [Page 3]

Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004

    sections.

    However, there is some debate whether the addresses in Additional
    section could be selected or filtered using hints obtained from which
    transport was being used; this has some obvious problems because in
    many cases the transport protocol does not correlate with the
    requests, and because a "bad" answer is in a way worse than no answer
    at all (consider the case where the client is led to believe that a
    name received in the additional record does not have any AAAA records
    to begin with).

| this leads to accept a layer violation as a legitimate consideration.
| the DNS is about resolving 0-Z strings into IP adresses. External issues
| such as used protocols are orthogonal, except when a part of the
| query - like for mail services and "MX". Phrasing should underline this?

...

2.1 Limited-scope Addresses

    The IPv6 addressing architecture [5] includes two kinds of local-use
    addresses: link-local (fe80::/10) and site-local (fec0::/10).  The
    site-local addresses are being deprecated [7], and are only discussed
    in Appendix A.

    Link-local addresses should never be published in DNS, because they
    have only local (to the connected link) significance [8].

| "should" ? Should it not be possible to enforce this in writing codes
| voiding the concerned RRs if entered ?

...

5.2 Recursive DNS Resolver Discovery

    Recursive IPv6 DNS resolver discovery is a subject of active debate
    at the moment: the main proposed mechanisms include the use of
    well-known addresses [21], the use of Router Advertisements to convey
    the information [22], and using DHCPv6 (or the stateless subset of it
    [23]) for DNS resolver configuration. No consensus has been reached
    yet.

    Note that IPv6 DNS resolver discovery, while an important topic, is
    not required for dual-stack nodes in dual-stack networks: IPv6 DNS
    records can very well be queried over IPv4 as well.

| it seems inadequate to publish a comprehensive document with such a
| lack of consensus. Or to mention that as a point for a further RFC.

7.1 Applicability of Reverse DNS

    Today, some applications use reverse DNS to either look up some hints
    about the topological information associated with an address (e.g.
    resolving web server access logs), or as a weak form of a security
    check, to get a feel whether the user's network administrator has
    "authorized" the use of the address (on the premises that adding a
    reverse record for an address would signal some form of
    authorization).

    One additional, maybe slightly more useful usage is ensuring the
    reverse and forward DNS contents match and correspond to a configured
    name or domain.  As a security check, it is typically accompanied by
    other mechanisms, such as a user/password login; the main purpose of
    the DNS check is to weed out the majority of unauthorized users, and
    if someone managed to bypass the checks, he would still need to
    authenticate "properly".

    It is not clear whether it makes sense to require or recommend that
    reverse DNS records be updated.  In many cases, it would just make
    more sense to use proper mechanisms for security (or topological
    information lookup) in the first place.  At minimum, the applications
    which use it as a generic authorization (in the sense that a record
    exists at all) should be modified as soon as possible to avoid such
    lookups completely.

| wording seems unadequate for an RFC? Should it not be afirmative?
| Saying "there are diferent positions" : as a developper or a
| manager, I cannot make any sense out of this?

....

7.3 DDNS with Stateless Address Autoconfiguration

    Dynamic DNS with SLAAC is a bit complicated, but manageable with a
    rather low form of security with some implementation.

| quite subjective, unprecise and uninformative "a bit", "rather low"?

    Every node on a link must then be allowed to insert its own reverse
    DNS record in the reverse zone.  However, in the typical case, there
    can be no stronger form of authentication between the nodes and the
    server than the source IP address (the user may roam to other
    administrative domains as well, requiring updates to foreign DNS
    servers), which might make attacks more lucrative.

| "lucrative" seems subjective :-). It does not tell the kind of risk.
| As a user I want to understand what I am to do and why.

    Moreover, the reverse zones must be cleaned up by some janitorial
    process: the node does not typically know a priori that it will be
    disconnected, and cannot send a DNS update using the correct source
    address to remove a record.

| "some" ? Janitorial ? What is the process to specifically carry ?
| I should understand what I am to develop.

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 24 Mar 2004 14:53:32 +0900

>>>>> On Tue, 23 Mar 2004 22:53:42 +0100, 
>>>>> "J-F C. (Jefsey)  Morfin" <[email-masked]> said:

> it to document each point. I know it is complex but couldbe usefull.

I guess you're responding to a wrong WGLC.  You actually made
comments on draft-ietf-dnsop-ipv6-dns-issues-04.txt, not
draft-ietf-dnsop-misbehavior-against-aaaa-00.txt, didn't you?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Mar 2004 10:50:56 +0100

In your previous mail you wrote:

   

=> your ideas (to be polite) about RFC 2826 / ICANN ICP-3 are irrelevant.

   
=> I strongly disagree: glue, additional section, etc, are necessary in
some contexts and have nearly always a real impact on performance: this
is *not* a layer violation and the issue is real.

   
=> this should be kept as an implementation choice. IMHO this is a bad
idea to blindly enforce this...
   
Regards

[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Mar 2004 12:45:08 +0200 (EET)

Wrong thread, so I changed the subject..  Thanks for feedback; most of 
these seem to be caused by confusion that this would be a normative 
reference for implementors, managers and users; it is not.  Maybe this 
needs to be strengthened in the Introduction..

> | document it as a way to transition and safely experimenting.

This document represent current practice and understanding, not what 
might be or could be, (or what some others may hope will never be).

Thus I do not see a need to make changes here.

> | query - like for mail services and "MX". Phrasing should underline this?

Note that the latter paragraph only describes that there has been 
debate about a subject, and states why this is a bad idea.  If you 
think this is insufficient (and as there was some other pushback about 
changes), could you propose text you'd like to see changed (and how)?

> | voiding the concerned RRs if entered ?

Enforcing anything is beyond the scope of this document.  It may give 
hints to implementers and the DNS spec writers, but that's all about 
it.

> | lack of consensus. Or to mention that as a point for a further RFC.

This subject is out of scope for this work, and is being solved 
separately.  I think the question is which is better, publishing a 
document describing current understanding or waiting for long time to 
get consensus so that every issue has already been decided.  For 
informational purposes, I think publishing (even if still raw) results 
is appropriate.

However, there is work in progress to describe this at more length
before the next IETF -- but that's a separate topic.

> 7.1 Applicability of Reverse DNS
[...]
> | manager, I cannot make any sense out of this?

That's as it should be, in this case: this document is not trying to 
be *normative* reference on how things must be done, but to point out 
different arguments (if there are more than one) to give the reader 
the opportunity to judge on his own.

> | quite subjective, unprecise and uninformative "a bit", "rather low"?

Yes, but this is explained at more length below.  Other suggestions?  
Note that anything is likely to be subjective here :-)
 
> | As a user I want to understand what I am to do and why.

It is intended to point out that attacking is eas(y/ier) if you just 
use IP addresses as a form of authentication.  I agree that this 
wording should be better.  Maybe along the lines of:

             .  In this case the attacker would only need to be able to 
     spoof the source address to be able to hijack a DDNS-managed 
     name -- compared to obtaining breaking cryptographic keys if a 
     more secure form of DDNS management was used.
     
sound good enough? other suggestions?
 
> | I should understand what I am to develop.

This document is not meant to be normative, so the details are left as 
an exercise of the reader; I don't think it is useful to try to 
specify the exact steps here, but if you have suggestions what to add 
here...?

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

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 24 Mar 2004 21:00:53 +0900

>>>>> On Tue, 23 Mar 2004 10:09:08 -0800, 
>>>>> David Meyer <[email-masked]> said:

> The WGLC will end on Wednesday, 07 April 2004, at 1500 PST.

Just to reduce the overhead of others on known issues:

- as already discussed and agreed, we'll remove Appendix A ("Live
  Examples") before sending it to the IESG.  I belive I edited the
  draft we can simply remove the appendix without leaving dangling
  references.

- I noticed a minor wording nit in the second paragraph of Section
  4.4:

   When a caching server asks the server for AAAA RRs in the zone, it
   recognizes the delegation is lame, and return a response with the
   RCODE being 2 (SERVFAIL) to the stub resolver.

  where "return a response" should be "returns a response".  This was
  already fixed in my local copy of the draft.

					JINMEI, Tatuya

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Wed, 24 Mar 2004 16:00:01 +0100

>needs to be strengthened in the Introduction..

Dear Pekka,
as explained in my response to Francis, I do not comment the
solutions, but as requested, the final text. And from a non involved
but - I suppose - informed (I dont say competent) user.

What you say makes the intented RFC also a Best Practice
or an RFC for infromation?

>Thus I do not see a need to make changes here.

Accepted in the context above, if this "current practice and understanding"
is mentionned. We still are in RFC 882 perspective rather than 883.

>changes), could you propose text you'd like to see changed (and how)?

As indicated in the response to Francis, my only concern is to avoid
legitimising a wrong debate. There is debate. I think the debate is of
real interest but that its first problem is to be presented in wrong terms.

I only suggest not to feed the wrong presentation and to help the real
debate in putting it into its real perspective (i.e. not "from transport" but
"in relation to transport".

>hints to implementers and the DNS spec writers, but that's all about

Agreed. This is why I suggest to be more specific about what
implementer and spec writers could do to avoid an operations
management (the purpose of this RFC) bug.

>informational purposes, I think publishing (even if still raw) results

Full agreement in the perspective quoted on top.

>the opportunity to judge on his own.

Accepted in the pespective above with the provision that this
document is to be of use. A normative RFC is for developpers.
An information RFC is - as you said - for others to think. Not
detailing all the positions with their con and pros does not
really help?

>Note that anything is likely to be subjective here :-)

I just mean that the wording lead to think it is subjective. This is
a real working document with a lof of efforts behind.

>      more secure form of DDNS management was used.

Perfect! I am sure that all my points could be easily adressed
this way, documenting the reason of the comments.

>an exercise of the reader; I don't think it is useful to try to specify the
>exact steps here, but if you have suggestions what to add  here...?

Some hints at what kind of janitorial works is right now discussed.

As a general point, to be more specific. The texte often says
there are opposed positions or different propositions, but does
not document them, so it does not fuel the thinking.

The real problem for an non specialist is to know about _all_
what is discussed in an IETF environment where there is no
state of the art/debate summary.

.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Wed, 24 Mar 2004 15:35:41 +0100

Dear Francis,
I proposed comments as requested.

1. My point of view is the one of a user of the current TCP/IP technology,
     not one of its designers. As a user I certainly consider first real life
     aspects from ICANN, DARPA, Verisign, manuifacturers, WSIS, and
     first of all from users feed backs.

2. My contribution's interest is only to come from an informed user,
     commenting the text (not the technicalities) as not being confusing.

     Its interest is not in commenting the technical solutions. I should
     have shared in the debate. Its interest is that I did not shared in
     the debate and I am not biased by the meanings you developed
     and I read them as people who did not shared in the debate will
     read them.

>=> your ideas (to be polite) about RFC 2826 / ICANN ICP-3 are irrelevant.

Respectfully, I do not consider that your politeness about my
comments has anything to do in here.

The text above is confusing because it revives here a controversy and
opens a new one totally orthogonal to the matter. Whatever the root
you use, the problems addressed in the proposed RFC will be the same.

The only reference which could be made would be to 882/883 the
oppositions of wich are reduced by the globalization solutions as the
ones discussed. Harping on 2826 is of no interest to the context,
while using some general sentences of 883 would help the reader to
understand this RFC is above this kind of outdated controversy.

At least this is my users point of view. But I certainly respect your
faith as a member of whatever chapel.

>is *not* a layer violation and the issue is real.

This is not my point. I do not comment the technical positions: I comment
on the wording. The wording discuss what is a layer violation (to consider
the DNS from a transport point of view) as if it was legitimate. An other
wording would give the same result.

Saying "in relation to transport" rather than "from transport" would repect
the independance between transport and DNS and achieving the same
result. But I am speaking Franglish and I leave good wording to others.

>idea to blindly enforce this...

Again, I do not comment the solution, I ask a question on the text.
The should here is not used as saying that the technology should,
but that the manager should. Unless this is a Best Practice, the
text should say something like "confusion created by publication
is such that Manager should care never to publish and designers
could write code to prevent this from happening".

jfc

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Mar 2004 15:23:49 +0200 (EET)

> or an RFC for infromation?

The intended category as expressed by the chairs is Informational.

(btw, I clarified the applicability of this document by adding in the 
introduction:)

        <t>The purpose of this document is to give information about
important issues and considerations related to DNS operations with
IPv6; it is not meant to be a normative specification or standard for 
IPv6 DNS.</t>

> detailing all the positions with their con and pros does not

(This was in context of reverse DNS records.)

I was not sure whether you were objecting to the contents of this 
section or not so I'm assuming you could be.. so..

I think all the main arguments have been fairly portrayed (in more
detail in other documents).  If you believe otherwise, please raise a
specific objection.

> this way, documenting the reason of the comments.

Please specify the exact paragraphs and issues where you're raising a 
point, possibly giving some context, and let's see if we can flesh 
these out.  It's difficult if we don't understand each others' 
comments :-)

> not document them, so it does not fuel the thinking.

OK; I tried to fuel the thinking a bit:

        <t>A problem with defining the clean-up process is that it is
difficult to ensure that a specific IP address and the corresponding
record are no longer being used.  Considering the huge address space,
and the unlikelyhood of collision within 64 bits of the interface
identifiers, a process which would remove the record after no traffic
has been seen from a node in a period of time (e.g., a year) might be
one possible approach.</t>
 
> state of the art/debate summary.

I've tried to keep these debates out of this document (in the
interests of not delaying it, and giving possibility to fully discuss
it in other documents), just summarizing the situation if applicable.  
When concerned, one should check the references pointed at in the 
paragraphs for more information.

Of course, in some cases (e.g., this janitorial process) there has not 
been much formal work on that.  It's unfortunate, but hopefully some 
new documents, in the future could be kick-started in the future.

.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Thu, 25 Mar 2004 17:08:53 +0100

Thank you for this. I just commented to help the reading.
I think you fully addressed that. Except on one point, but
I am not competent to seriously addres your question (see
below)/

>IPv6; it is not meant to be a normative specification or standard for

Thak you.

>detail in other documents).  If you believe otherwise, please raise a

I do not object the content. As said above. But as a reader I wish
to understand what is said to me one shot.

>point, possibly giving some context, and let's see if we can flesh these
>out.  It's difficult if we don't understand each others'  comments :-)

I just commented the reading as a reader. I think you already met
most of my outsiders remarks. BTW Thank you.

>one possible approach.</t>

Great: I mean in term of explaining - however I am not sure it
should not call for a TTO (Time to Obsolecence) to be specified?

>it in other documents), just summarizing the situation if applicable.

Yes. What I meant was to list the points under debate. Not to
discuss them.

>new documents, in the future could be kick-started in the future.

This is what I suggested. To explain what is concerned by the
janitorial aspects, to push for new documents. I suspect that
these janitorial/ancillary issues may be the real operational
issues?

Thank you for your understanding.
jfc

.

---

From: "Barber, Piet" <[email-masked]>
Date: Thu, 25 Mar 2004 16:52:11 -0500

Although servfail rcodes have already been mentioned in this draft, I 
would like to add this nice little gem of DNS. This name server responds 
to AAAA queries in a particularly odd way:

1) 'aa' bit + SERVFAIL.
2) Reflexive CNAME.
3) answer section given, despite the SERVFAIL

dig @ns.intouch.net ns.intouch.net aaaa +norecurs

; <<>> DiG 9.2.1 <<>> @ns.intouch.net ns.intouch.net aaaa +norecurs
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58716
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.intouch.net.                        IN      AAAA

;; ANSWER SECTION:
ns.intouch.net.         3600    IN      CNAME   blade230.intouch.net.
blade230.intouch.net.   3600    IN      CNAME   blade230.intouch.net.

;; Query time: 92 msec
;; SERVER: 212.26.192.1#53(ns.intouch.net)
;; WHEN: Wed Mar 24 16:17:16 2004
;; MSG SIZE  rcvd: 69

.

---

From: bert hubert <[email-masked]>
Date: Fri, 26 Mar 2004 08:12:25 +0100

> to AAAA queries in a particularly odd way:

Hi Piet! This is PowerDNS.

> 1) 'aa' bit + SERVFAIL.

The 'aa' might not be right but if a nameserver cannot satisfy the question
because the CNAME points to something that does not exist, it should give
out a SERVFAIL.

If I'm mistaken, please let me know! I can easily fix this.

> 2) Reflexive CNAME.

Mad incompetence of the operator :-) 

> 3) answer section given, despite the SERVFAIL

Try it with BIND, it does (or did) the same thing, with the possible
exception of the aa bit.

This is not in any way bound to AAAA btw, the same would happen with 'A'. 

Thanks for reporting this.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 09:49:35 +0200 (EET)

> should not call for a TTO (Time to Obsolecence) to be specified?

This was added just to convey the time frame, that is, "months or
years" rather than "every hour".  I'll change it to be a bit more 
vague..

.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Fri, 26 Mar 2004 13:55:04 +0100

>years" rather than "every hour".  I'll change it to be a bit more

Oh! I try to get the text more specific!

What I mean is that if you introduce a new concept in the DNS
affecting the availability/existance of the RRs you should make
ita very precise feature. From what I gather the TTO would be the
delay before non called entry should be discarded. I think the
concept is great as it may really help managers tracing their
own mismanagement.

But :

1. I do not know where it is to be introduced because I do not
     see easily how it may survive a reload (we are talking of the
     master file management). This means an associated base
     keeping the date of the last use and called at loading time.

2. this would pemit a feature I want for a long in the DNS, which
     is temporary names for security/ebusiness purposes. If I set
     a TTO of 15 minutes and a TTL of 5 minutes on a Dynamic
     entry : the name will be valid for 20 minutes maximum on the
     network.

jfc

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 17:01:51 +0200 (EET)

>      entry : the name will be valid for 20 minutes maximum on the

I think there has been a misunderstanding about the context where such 
a janitorial process would operate.  I was not proposing changes to 
DNS records, but rather how the zones are operated.

For the cases where the names would be statically assigned, they 
cannot be expired out without being checked for validity.  So, unless 
we assume that the nodes using DDNS would be updating the record just 
in case even though it is up-to-date (to signal that, yes, "I'm still 
here"), the process has to operate in a different context.

That is, for example, you could be running an arpwatch -like daemon in
your network, and storing the IP addresses used.  Or you could do 
syslogging from your border router based on IP addresses.  Or 
something else.  After you've collected a lot of data like this, you 
would run some process which would find the old information from the 
pile, and remove their records from the DNS files.

Yes, this is complicated, but ideas for something better are welcome.

And if we figure out something better (e.g., recommend that DDNS is 
run regularly), all the better -- but that probably doesn't need to go 
into this document, especially if it takes a lot of time to "get 
right".

.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Fri, 26 Mar 2004 19:01:21 +0100

>DNS records, but rather how the zones are operated.

Full agreement. It is just that something timely negative (removing on a 
time condition cannot be limited to zone management) you need
indepednent references.

>After you've collected a lot of data like this, you would run some process 
>which would find the old information from the pile, and remove their 
>records from the DNS files.

Yes. my idea was not to remove them from DNS files (authority decision and 
you do not know if they arenot generated by another process - I use virtual 
zones to support IDNA and co-registries). Just not to load them and report, 
the manager could force them.

I tend to think that IPv6 will lead to a drastic change in the files 
actually used by the zone managers.

>doesn't need to go into this document, especially if it takes a lot of 
>time to "get right".

Yes. Far too premature. IPv6 is the first significant change in the DNS for 
20 years. A lot of delayed needs will show up. They shouldl stabilize first 
and be reduced to a simple common configuration language or format.
jfc

.