Subject: [DNSOP] WGLC: "Considerations for the use of DNS Reverse Mapping"

From: Peter Koch <[email-masked]>
Date: Fri, 14 Mar 2008 04:45:00 +0100

Dear WG,

in accordance with the roadmap posted the other day, this is to initiate
a working group last call on

	"Considerations for the use of DNS Reverse Mapping"
	draft-ietf-dnsop-reverse-mapping-considerations-06.txt

ending Friday, 2008-04-04, 18:00 UTC.

The document is aimed at a status of "BCP".
Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.  We have taken names of volunteers,
but everyone is encouraged to review.  There will be a five reviewer threshold
and _no_ default action.

-Peter [co-chair hat on]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Mar 2008 00:07:29 -0400

> but everyone is encouraged to review.  There will be a five reviewer threshold
I have reviewed the draft, and support it moving forward without any 
further changes.

Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Mar 2008 00:07:29 -0400

Brian Dickson

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Mar 2008 18:51:50 -0400 (EDT)

I oppose this document. I won't go into details since none of my
objections have ever been addressed, other than to say "We addressed
your objection" with a frivolous change or no change at all. Reposting
the details seems an utter waste of time.

If this document is eventually approved by the WG, I will file a
detailed objection with the IESG.  I see no point in further detailed
discussion until that event transpires, except to note that I remain
opposed.  I don't expect my opposition to change unless the previously
noted problems are addressed, and so far, they've either been ignored or
frivolously handled.  I believe the objections of others have also been
ignored or frivolously handled.

Thanks,

		--Dean

On Fri, 14 Mar 2008, Peter Koch wrote:

> Please review the draft and send comments and/or statements of support orFrom [email-masked]  Fri Mar 14 15:54:16 2008
Date: Fri, 14 Mar 2008 18:51:50 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Peter Koch <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse
	Mapping"
Sender: [email-masked]

I oppose this document. I won't go into details since none of my
objections have ever been addressed, other than to say "We addressed
your objection" with a frivolous change or no change at all. Reposting
the details seems an utter waste of time.

If this document is eventually approved by the WG, I will file a
detailed objection with the IESG.  I see no point in further detailed
discussion until that event transpires, except to note that I remain
opposed.  I don't expect my opposition to change unless the previously
noted problems are addressed, and so far, they've either been ignored or
frivolously handled.  I believe the objections of others have also been
ignored or frivolously handled.

Thanks,

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Mar 2008 15:22:52 +0100

On Fri, Mar 14, 2008 at 04:45:00AM +0100,
 Peter Koch <[email-masked]> wrote 

> 	draft-ietf-dnsop-reverse-mapping-considerations-06.txt

I've read and reviewed
draft-ietf-dnsop-reverse-mapping-considerations-06 and, basically,
this document is OK for its intended status.

I find it succeeds in the very delicate balance between two extremes,
mFrom [email-masked]  Wed Mar 26 07:25:55 2008
Date: Wed, 26 Mar 2008 15:22:52 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: IETF DNSOP WG <[email-masked]>
Organization: NIC France
Subject: Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse
	Mapping"
Sender: [email-masked]

On Fri, Mar 14, 2008 at 04:45:00AM +0100,
 Peter Koch <[email-masked]> wrote 

> 	draft-ietf-dnsop-reverse-mapping-considerations-06.txt

I've read and reviewed
draft-ietf-dnsop-reverse-mapping-considerations-06 and, basically,
this document is OK for its intended status.

I find it succeeds in the very delicate balance between two extremes,
making PTR mandatory and claiming they are useless. Its general
approach (PTR are useful and should be added but should not be relied
on) seems a realistic one to me.

I also appreciate that it introduces a much needed terminology, both
rigorous and non pejorative, to talk about things like "matching
reverse data".

No editorial comments.

---

From: Andras Salamon <[email-masked]>
Date: Wed, 26 Mar 2008 23:49:32 +0000

> 	draft-ietf-dnsop-reverse-mapping-considerations-06.txt

I have reviewed the document and believe it presents the current
network situation in a balanced way.  Its suggestions allow for a
variety of different administrative policies, while still arguing that
the benefits of maintaining reverse mappings in most cases outweigh
the costs.

Personally I would have preferred additional citations, for instance
to support many of the statements in 3.1, but I support the document
progressing as is.

-- Andras Salamon                   [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andras Salamon <[email-masked]>
Date: Wed, 26 Mar 2008 23:49:32 +0000

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Mar 2008 15:28:17 -0700

At Fri, 14 Mar 2008 04:45:00 +0100,

> but everyone is encouraged to review.  There will be a five reviewer threshold

I've read this version of the draft, and I regret to say I cannot
(yet) support it.  I've always been a supporter of this work, and
been respecting the authors' effort in taking into account
controversial opinions, but I still must oppose to moving forward with
this version.

As a meta (and most substantial) level, this version still doesn't
answer the fundamental question I asked a year ago: "why *should* one
provide reverse mappings for all IP addresses they manage? (despite
the cost of the provision)?".
(see http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html)

I admit I'm partially responsible for the lack of the answer as I
was not very active in the follow-up discussion at that time (I hope I
can be more active and responsive this time).  But I'm very much
concerned about the current tone of the draft, so I cannot help
repeating it.

Since this document does not provide a convincing answer (at least to
me) for the question of "why I should", I, as an operator, will still
only provide reverse mappings as a best effort basis (i.e., I may not
provide them even if there is no "*strong* counter-considerations").
For example I won't provide reverse mappings if I simply cannot (or
don't want to) afford the operational cost.  And I'm afraid I'm not
just one of very few lazy operators; rather, I think a non negligible
number of ordinary operators will take a similar action.  On the other
hand, since this document only requires "thinking carefully" about
adopting (dubious) access control based on reverse mappings, operators
who are currently deploying it will simply continue the operation,
probably with quickly "thinking about it" as an excuse.  I'm also
afraid the unbalanced level of recommendations (i.e., "should provide
reverse mappings" vs "are encouraged to think about it before using
it") will give an excuse for such operators (revmap users) to continue
it.  The end result will be a (continued) poor interoperability, and
the "excuse" may even make it worse.

My interpretation from the discussions so far is that the issues are
too subtle or controversial to provide a convincing reason for
declaring a specific requirement with such a strong word as "should".
Maybe future changes in operation like wider deployment of IPv6 and/or
DNSSEC, or changes in the relationship between the existence of reverse
mappings and SPAM, may change the practice more clearly and we can
revisit it.  But, in my understanding, the "best current practice" we
can agree today is to simply state issues without a strong
recommendation.

I proposed one specific change to Section 4.4 a year ago along with
this point:

From

   Unless there are strong counter-considerations, such as a high
   probability of forcing large numbers of queries to use TCP, all IP
   addresses in use within a range should have a reverse mapping.

To

   A network administrator is encouraged to provide a reverse mapping
   for IP addresses in use within a range of the network if
   administration cost is acceptable according to the local policy.
   In some cases the administrator may rather want to avoid providing
   reverse mapping; for example, when there is a high probability of
   forcing large numbers of queries to use TCP.

I believe this is more fair compared to the counterpart for the users
(i.e., "encourage to think about it carefully") and is more realistic
with the understanding (of mine) that a strong requirement with no
convincing reason will be ignored anyway.  Is there any reason we
cannot adopt this text?  If this is something we can "live with", I
sincerely request adopting it.

One more possibly related thing: what does this document recommend
about "matching reverse data"?  While I still haven't understood why
we are required to provide reverse mappings, if it's something related
to that "administrators at other sites sometimes use reverse mapping
as one of several pieces of evidence in evaluating connection traffic,
particularly in the context of mail systems and anti-spam efforts."
(from Section 4.4), then the recommendation without also requiring the
provision of matching reverse data would be incomplete.

The following are specific comments on the text more or less along
with this major point.  I also have a trivial/less controversial
comments; I'll send them in a separate message so that they won't be
buried in the controversy.

Section 3.2

   Reports from operators suggest that scoring mail on the basis of
   missing or non-matching reverse mapping remains an imperfect but
   useful measure of the likelihood that a given message is spam,
   particularly in combination with other measures.  It is clear that
   the presence of reverse mapping, and a match between the forward and
   reverse zones, is neither a necessary nor sufficient condition for a
   candidate message to be spam.

I'm not very much comfortable with a statement based on "some people
say something" because it's difficult to assess its validity.  In
fact, I cannot really be sure that reverse mapping-based approach is
that effective, considering the fact that most of today's spams are
sent from botnets and the reverse mappings are often provided (when
provided) by the ISP, rather than the end users who host the bots.
I'd rather like to see a solid reference that describes how exactly
effective of this type of scoring is, both in terms of the ability of
identifying spams and of the ability of avoiding false positives.

I'd also like to add a reference to research work in this area that
doesn't rely on reverse mapping, such as a SIGCOM '07 paper:
http://www.sigcomm.org/ccr/drupal/?q=node/267
This is not related to DNS or reverse mapping specifically per se, but
I think it's useful to show people who naively believe the power of
reverse mappings that there are alternatives, which might be more
trustworthy, for their purposes.

Section 3.4

   The larger address space of IPv6 also makes possible "hiding" active
   hosts within a large address block: the impracticability of scanning
   an entire IPv6 network for running network services means that an
   administrator could effectively conceal running services in an IPv6
   network in a way not possible in an IPv4 network.  Such hiding would
   be prevented by a reverse mapping that revealed only existing hosts.
   If such "hiding" is desirable, it is possible nevertheless to provide
   reverse mapping for (a large segment of) the network in question, and
   then use only a small number of the so-mapped hosts.  This approach
   is consistent with the suggestion outlined in section 4.2, below.

I pointed out the suggested alternative might be too optimistic in
terms of reality in my previous comment:
http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html
this version still doesn't address the concern.  I'd like to propose
the following change, which I believe is more realistic.

   ... If such "hiding" is desirable, one possible alternative is to
   provide reverse mapping for (a large segment of) the network in
   question, and then use only a small number of the so-mapped hosts.
   It should still be noted, however, that this approach may not
   easily be realized with deployed implementations, and that
   automatically generated host names that are often used in this
   approach may make them useless. ...

Section 4.2

   In general, the DNS response to a reverse map query for an address
   ought to reflect what is supposed to be seen at the address by the
   machine initiating the query.

Maybe I'm too dull, but I've never succeeded to understand the meaning
of this sentence (I asked the same question on a previous version of
the draft, but this point has never been clarified).  In particular, I
don't understand what this means: "what is supposed to be seen at the
address by the machine initiating the query".  Can't this be more
clarified?

Also Section 4.2

   Unless there are strong counter-considerations, such as a high
   probability of forcing large numbers of queries to use TCP, IP
   addresses in use within a range and referenced in a forward mapping
   should have a reverse mapping.

I failed to understand this sentence.  Does this mean

   IP addresses that are
      - in use within a range, and
      - referenced in a forward mapping
   should have a reverse mapping.

or

   - IP addresses that are in use within a range, and
   - IP addresses that are referenced in a forward mapping
   should have a reverse mapping.

or something else?  In either case, does this mean we don't have to
provide reverse mappings for addresses that are NOT referenced in a
forward mapping?

I also asked the precise definition of 'in use' (especially in the
context of IPv6 stateless address configuration) in my previous
comment, but it's still unclear in this version.

Section 4.4

   Some users continue to report difficulty in ensuring complete
   population of the reverse tree by upstream providers.  This situation
   can be corrected by the provision by those providers of reverse
   mapping; but until the day reverse mapping is universal, complete
   connection rejection on the basis of missing reverse mapping should
   be regarded as a last resort.

(Again, I commented on this before) I don't follow the logic here.
Repeating my previous comment:

> I don't understand the logic of this sentence.  This sounds as if
> complete connection rejection on the basis of missing reverse mapping
> will be encouraged (or at least not discouraged) when reverse mapping
> is universal.  But in my understanding the essential problem of this
> approach is "the use of the reverse tree provides no real security,
> (and) can lead to erroneous results".  This should still apply even if
> "reverse mapping is universal".  So I'd rewrite it to, e.g.:

>   Some users continue to report difficulty in ensuring complete
>   population of the reverse tree by upstream providers.  This
>   situation can be improved by the provision by those providers of
>   reverse mapping; but even if reverse mapping is more widely
>   provided, complete connection rejection on the basis of missing
>   reverse mapping should be generally discouraged, since the
>   existence of a reverse mapping does not necessarily mean the owner
>   of the address is legitimate.

Perhaps my suggested text is too biased toward discouraging the
dubious use of reverse mappings, but at least I want to see something
that is logically more understandable.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Mar 2008 15:28:17 -0700

From

To

Section 3.2

Section 3.4

Section 4.2

Also Section 4.2

   IP addresses that are

or

Section 4.4

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Mar 2008 15:47:29 -0700

> but everyone is encouraged to review.  There will be a five reviewer threshold

Here are my minor comments on the draft:

1. In Section 1.2

   Starting from a given IPv4 address (possibly the result of a query
   for an A RR), the term "existing reverse data" means that a query for
   <reversed-ip4-address>.in-addr.arpa. type PTR results in a response
   other than Name Error.

I don't think this definition is 100% appropriate.  Consider the case
where a PTR RR is not provided for <reversed-ip4-address>.in-addr.arpa
but some other type of RR (e.g. TXT) is.  Then the response to the PTR
query won't be a Name Error, but it wouldn't be reasonable to consider
it the existence of reverse data.  I'd suggest revising this to:

   Starting from a given IPv4 address (possibly the result of a query
   for an A RR), the term "existing reverse data" means that a query for
   <reversed-ip4-address>.in-addr.arpa. type PTR results in a positive
   response (i.e,, one that contains a PTR RRset for the queried name
   in the answer section).

Also about the IPv6 case:

   Starting from a given IPv6 address (possibly the result of a query
   for an AAAA RR), the term "existing reverse data" means that a query
   for <reversed-ip6-address>.ip6.arpa. type PTR results in a positive
   response.

And for the definition of "missing reverse data":

   The term "missing reverse data" means that the query for existing
   reverse data results in a negative response (i.e., one that does
   not contain a PTR RRset for the queried name in the answer section,
   often with a non 0 response code).

2. In Section 2.1 (last line of page 4)

   attacker could acquire access either by by putting the target host

should be

   attacker could acquire access either by putting the target host

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Mar 2008 15:47:29 -0700

1. In Section 1.2

should be

---
JINMEI, Tatuya

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Mar 2008 19:08:23 -0400 (EDT)

>    response (i.e,, one that contains a PTR RRset for the queried name

Would it contain these if classless reverse delegations (eg CNAME's) were
used?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Mar 2008 19:08:23 -0400 (EDT)

Paul

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Mar 2008 16:16:47 -0700

At Fri, 28 Mar 2008 19:08:23 -0400 (EDT),

> Would it contain these if classless reverse delegations (eg CNAME's) were

Good point, I guess the phrase "result in" would implicitly have the
implication, but we may have to revise it a bit like, e.g.,:

  "(i.e,, one that provides a PTR RRset corresponding to the IPv4
  address)".

at the risk of making the definition relatively ambiguous.

Or we could also remove the "i.e" part.

---
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Mar 2008 16:16:47 -0700

---
JINMEI, Tatuya

---

From: Brian Dickson <[email-masked]>
Date: Sat, 29 Mar 2008 00:46:57 -0400

> the cost of the provision)?".

I'd like to get a better understanding of your concern.
Is it that you don't understand why one should, or that the document 
doesn't include the answer itself?

In other words, if someone on the list answers the question, without 
that changing the document,
would you then support it based on your new-found understanding?

> provide them even if there is no "*strong* counter-considerations").

What you are saying, then, is that as a BCP, the guidance provided would 
be something you would
ignore.

The *point* of the language, is to gently nudge those who may otherwise 
not have a strong opinion
on the matter, to adopt the practice which results in the greatest level 
of interoperation and cooperation.

Presuming it is adopted and reaches BCP status, operators wishing to be 
considered within their
community as "responsible" operators, would take its advice at face value.

Which is to say, absent *strong* counter-considerations, to provider 
reverse mappings.

What I don't understand about your question is, if you don't *have* any 
strong counter-considerations,
then why would you oppose doing reverse mappings? And likewise, why 
would you oppose adoption
of this language - again, if there are no strong counter-considerations?

Basically, the best way to describe the choice of language is, that 
doing reverse-mappings won't hurt
anything or anyone, in general, and achieves some benefit. However, the 
benefit is lost, and the use
of the reverse-mappings becomes a hindrance, if they are not applied 
nearly universally - i.e. where
IP addresses are in use, and occur in a forward mapping somewhere in the 
DNS.

This is because,
absent omniscient awareness of the complete population of the DNS 
system, a host cannot know
in advance whether a reverse entry exists without querying for it. And 
if querying for it does not
produce either a fast positive (answer) or fast negative (some kind of 
response), then the act
of checking *if* a reverse entry exists, causes problems for the 
host/application.

It's a question of utility. If you believe anyone benefits from reverse 
mappings, then you support
the existence of in-addr.arpa and ip6.arpa. And from there, it only is 
useful if it is populated.

Conversely, arguing against populating it, is to argue against its 
existence at all.

> sincerely request adopting it.

I do not believe this is something we can "live with" at all.

Providing an "easy out" to anyone who wants one, defeats the purpose of 
the document.

And consider this, when bring up "cost":

IP addresses are not property. They are provided by central assigning 
authorities, for use, and
with the expectation that they be managed, and managed properly.

Part of the expectation in assigning IP address blocks, is that the 
assignee will receive the delegation
for that block, within in-addr.arpa.

So, there is already a large expectation on managing the address space, 
and for having DNS servers
for the in-addr.arpa zones that correspond to the space. The 
*incremental* cost in populating the
zone accurately, is negligible.

And generally, the receipt of IP addresses has with it, a cost of 
maintenance on a yearly basis already,
so the idea that an IP address shouldn't have an operation cost 
associated with it, is already a falacy.

How an operator minimizes the operational cost, is just a part of doing 
business, and left as an exercise
for the operator.

> provided) by the ISP, rather than the end users who host the bots.

It does not matter  *how* effective it is, nor in what way it is used.

The point is, it *is* used, and thus, is a strong justification for 
preserving and enhancing the population
of reverse mappings. The fact that reverse mappings *alone* aren't a 
good way of doing things,
doesn't mean that they aren't of value in a complex mechanism that uses 
them.

>    approach may make them useless. ...

If you don't know how to do this, then please ask for help in doing it, 
rather than making the
above suggestion. I'm sure there are folks who would be happy to help 
you, or to explain
some of the subtleties of steganography that this represents.

> address by the machine initiating the query".  Can't this be more

It is very plain language.

What it means is, if the machine thinks its name is "fred", and will provide
a login prompt of "fred", and speak SMTP using the name "fred", then the 
reverse map should
in some way include "fred", and not "george".

>    should have a reverse mapping.
This one - if *both* conditions are met.

A secondary means of doing forward/reverse population is to set up 
unique dummy names, for those IP addresses
not in use, or for which no forward map exists (other than the dummy). 
This may in some cases be preferable
to not populating reverse mappings if no forward mappings exist.
> comment, but it's still unclear in this version.

For example - if an address is in use, *and* has a forward mapping, then 
likely it is doing dynamic dns.
In such an instance, it would be advisable to have the dynamic dns 
system handling the forward mapping, also update
the reverse mapping.

>> "reverse mapping is universal".  So I'd rewrite it to, e.g.:

No.

It does not presuppose that any particular policy regarding connection 
rejections will be adopted,
nor does it encourage such.

It merely embodies the syllogistic logic of "A implies B", also means 
"NOT B implies NOT A".

It says, in order to rely on reverse mappings for connection rejection, 
the reverse mappings must be universal.
They are not universal, therefore they should not be relied on 
completely for connection rejection.
And, should the status of their non-universality change, this issue 
becomes moot.

> that is logically more understandable.

While your text may be more understandable, it embodies much that was 
deliberately excluded, so it won't likely
be seen as acceptable by the authors or by the majority here, I would 
expect.

If you re-read the text, after reading my explanation, does it seem 
clearer now?

Sincerely,

Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Sat, 29 Mar 2008 00:46:57 -0400

This is because,

No.

Sincerely,

Brian Dickson

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 29 Mar 2008 15:18:04 -0400

Dear colleagues, 

I received some time ago some comments off-list on the reverse-mapping
considerations document.  I attempted unsuccessfully to convince the
reviewer to send his substantive comments to the WG list, but he did
not feel comfortable with that.  (He also provided a number of helpful
editorial comments, which we incorporated in the most recent version
of the draft.)

I here will attempt to summarize my understanding of his comments.

The reviewer takes exception to the suggestion that delegations in the
forward zone should ideally have an entry in the reverse zone too.
Instead, he suggests, that there be _at least one_ matching reverse;
e.g.,

         A (PTR (ipaddr))   == ipaddr                                           
or       A (PTR (A (fqdn))) == A (fqdn)

but not many more.  The reviewer argues that the draft should in fact
argue against adding multiple ("more than a handful") PTR(s) for a
given address.

It was our (the editors') impression that the above is consistebt with
what the draft actually says, but that it has a different emphasis.
That is, we think the draft says that existing reverse data is
generally good, and matching reverse is nice to have, but that you
shouldn't take this too far.  We decided not to try to change this in
the draft on the grounds of the support we had so far, but we're
certainly open to changes if others think this message is garbled in
the existing version of the draft.

I hope I've done justice to the reviewer's comments.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 29 Mar 2008 15:18:04 -0400

Dear colleagues, 

Best regards,

A

---

From: Brian Dickson <[email-masked]>
Date: Sat, 29 Mar 2008 16:31:33 -0400

> argue against adding multiple ("more than a handful") PTR(s) for a

Ah. I think the issFrom [email-masked]  Sat Mar 29 13:31:39 2008
Date: Sat, 29 Mar 2008 16:31:33 -0400
From: Brian Dickson <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] WGLC: "Considerations for the use of
	DNS	Reverse	Mapping"
Sender: [email-masked]

> argue against adding multiple ("more than a handful") PTR(s) for a

Ah. I think the issue that (presumably) the original review had was, 
that if you have, say, 100 FQDNs,
all of which have:

    A ( fqdnXX ) == A.B.C.D
    (for all values of XX ranging from 00 to 99)

then the issue is, does there need to be 100 PTR records, where

    PTR ( A.B.C.D ) == fqdnXX
    (for all values of XX ranging from 00 to 99).

I would suggest that the forward/reverse validation embodied in this, 
could better be handled
from an operational perspective, with the following alternative solution:

    CNAME ( fqdnXX ) == fqdn00
    (for all values of XX ranging from 01 to 99)

and then only the one PTR record is needed to validate the 
forward/reverse universe:

    PTR ( A.B.C.D ) == fqdn00.

It's not perfect, but may be adequate for many of the uses of 
forward/reverse matching.

It also does a better job of embodying the *intent* of both PTR and 
CNAME, when there are many
domains served/hosted on a single IP address.

(I would suggest that anyone considering doing the CNAME exercise, do so 
with sub-domain entries
rather than with the entire domain, so that SOA information can be kept 
separate for each domain.
E.g. have a real SOA for subdomain25.example.com, and a CNAME for 
www.subdomain25.example.com
which points to www.example.com, rather than having 
subdomain25.example.com be a CNAME pointing
to example.com.)

> the existing version of the draft.

I think the language in the current draft does a good job of describing 
the general use and intent
behind its own recommendation, without delving into the minutia that 
having examples iterating
over many use cases would require.

I think in all cases, it is imperative that a solid understanding of the 
implications of design choices
exists, prior to embarking on implementing a given design. It is highly 
unlikely that a BCP can
do more than guide readers on the high-level issues, and the deeper 
understanding is the
responsibility of the reader, not the authors.

Brian Dickson

ue that (presumably) the original review had was, 
that if you have, say, 100 FQDNs,
all of which have:

    A ( fqdnXX ) == A.B.C.D
    (for all values of XX ranging from 00 to 99)

then the issue is, does there need to be 100 PTR records, where

    PTR ( A.B.C.D ) == fqdnXX
    (for all values of XX ranging from 00 to 99).

I would suggest that the forward/reverse validation embodied in this, 
could better be handled
from an operational perspective, with the following alternative solution:

    CNAME ( fqdnXX ) == fqdn00
    (for all values of XX ranging from 01 to 99)

and then only the one PTR record is needed to validate the 
forward/reverse universe:

    PTR ( A.B.C.D ) == fqdn00.

It's not perfect, but may be adequate for many of the uses of 
forward/reverse matching.

It also does a better job of embodying the *intent* of both PTR and 
CNAME, when there are many
domains served/hosted on a single IP address.

(I would suggest that anyone considering doing the CNAME exercise, do so 
with sub-domain entries
rather than with the entire domain, so that SOA information can be kept 
separate for each domain.
E.g. have a real SOA for subdomain25.example.com, and a CNAME for 
www.subdomain25.example.com
which points to www.example.com, rather than having 
subdomain25.example.com be a CNAME pointing
to example.com.)

> the existing version of the draft.

I think the language in the current draft does a good job of describing 
the general use and intent
behind its own recommendation, without delving into the minutia that 
having examples iterating
over many use cases would require.

I think in all cases, it is imperative that a solid understanding of the 
implications of design choices
exists, prior to embarking on implementing a given design. It is highly 
unlikely that a BCP can
do more than guide readers on the high-level issues, and the deeper 
understanding is the
responsibility of the reader, not the authors.

Brian Dickson

---

From: Robert Story <[email-masked]>
Date: Sat, 29 Mar 2008 18:23:53 -0400

On Fri, 28 Mar 2008 15:28:17 -0700 JINMEI wrote:
JT/> AFrom [email-masked]  Sat Mar 29 15:24:13 2008
Date: Sat, 29 Mar 2008 18:23:53 -0400
From: Robert Story <[email-masked]>
To: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= <[email-masked]>
Organization: SPARTA
Cc: Peter Koch <[email-masked]>, IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse
 Mapping"
Sender: [email-masked]
On Fri, 28 Mar 2008 15:28:17 -0700 JINMEI wrote:
JT/> At Fri, 14 Mar 2008 04:45:00 +0100,
JT/> Section 3.2
JT/> 
JT/>    Reports from operators suggest that scoring mail on the basis of
JT/>    missing or non-matching reverse mapping remains an imperfect but
JT/>    useful measure of the likelihood that a given message is spam,
JT/>    particularly in combination with other measures.  It is clear that
JT/>    the presence of reverse mapping, and a match between the forward and
JT/>    reverse zones, is neither a necessary nor sufficient condition for a
JT/>    candidate message to be spam.
JT/> 
JT/> I'm not very much comfortable with a statement based on "some people
JT/> say something" because it's difficult to assess its validity.  In 
JT/> fact, I cannot really be sure that reverse mapping-based approach is
JT/> that effective, considering the fact that most of today's spams are
JT/> sent from botnets and the reverse mappings are often provided (when
JT/> provided) by the ISP, rather than the end users who host the bots.

But that's exactly _why_ it's effective.. the bots cannot change the ISP's
reversing mapping, so a system admin can decide to mark mail coming from dynamic27381.big-isp.example.com as very likely being spam.

-- 
Robert Story
SPARTA

---

From: [email-masked]
Date: Sat, 29 Mar 2008 23:17:27 +0000

I'm going to ask this question here too..  are we talking about the DNS
or are we talking about an applications use of data published in the DNS?

i see this draft in the context of the historical DNS ... it is a mapping
service,  a name to an address AND an address to a name.  the mapping service
is OPTIONAL ... the Internet does not now (and should NEVER) depend on this
service being available for any other service to work.

I think a key point here is that -reciprocity- is and should be highly valued
feature of DNS provisioning.

that said, if one provisions mapping in one direction, it should also be
provided in the other.  

e.g.  

	label1 == address1  implies   address1 == label1

so, if it is legal to have this construct:

	label == address1
	      == address2
	      ...
	      == addressN

then this construct should also be legal:

	address == name1
	    	== name2
		...
		== nameN

what we have is a mess....

	label1 == address1918
	address1918 == lable8

which, while technicallu legal, violates the spirit of the 
lema posited above, as does;

	label35 == address1918
	and address1918 has no matching label.

we now return you to your SMTP coloured discussion.

--bill

---

From: [email-masked]
Date: Sat, 29 Mar 2008 23:17:27 +0000

e.g.  

	label == address1
	      == address2
	      ...
	      == addressN

	address == name1
	    	== name2
		...
		== nameN

	label1 == address1918
	address1918 == lable8

	label35 == address1918

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 30 Mar 2008 11:55:04 -0400

Hello,

On Fri, Mar 28, 2008 at 03:47:29PM -0700, JINMEI Tatuya / 神明達哉 wrote:

> but some other type of RR (e.g. TXT) is.  

(And similar).  Excellent point.  Thanks very much!

Given the discussion later in this thread, the definitions seem still
to need more work.  I'll try to put final proposed text together.
I've opened issue 20 for this.

>    attacker could acquire access either by by putting the target host

Thanks.  I've fixed this in the source.

Best regards,

A

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 30 Mar 2008 11:55:04 -0400

Hello,

Best regards,

A

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Mar 2008 13:17:11 -0400

>or are we talking about an applications use of data published in the DNS?

I think that this is the important question when it comes to know 
what to write.

As far as DNS is concerned, "so what" if there are multiple PTR 
records, yadda, yadda, yadda.  It's nothing to the protocol.

I was made aware of the desire for limiting PTRs to 1 per address 
entry via traceroute.  What name should be printed in the one line 
traceroute gives a hop?

In general, that's the application's problem.  Apps that can't handle 
multiple PTRs are the problem to me.  (Why is is that weakly written 
apps point fingers at the DNS and blame troubles on DNS-being-DNS?)

Perhaps this document should tell apps writers what they can 
accomplish with multiple PTRs.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Mar 2008 13:17:11 -0400

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Apr 2008 06:34:38 +1100

> accomplish with multiple PTRs.

	Multiple PTR records do not scale.

	Today we have reverse lookups that fail because people
	followed this path and exceeded the 64K DNS message size
	of TCP.

	When people have a 100 thousand virtual domains on a 
	box you just can't have PTR records for all of them.

	Mark
-- 
Mark Andrews, From [email-masked]  Mon Mar 31 12:34:50 2008
To: Edward Lewis <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Tue, 01 Apr 2008 06:34:38 +1100
Cc: IETF DNSOP WG <[email-masked]>, [email-masked],
	Peter Koch <[email-masked]>
Subject: Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse
	Mapping"
Sender: [email-masked]

> accomplish with multiple PTRs.

	Multiple PTR records do not scale.

	Today we have reverse lookups that fail because people
	followed this path and exceeded the 64K DNS message size
	of TCP.

	When people have a 100 thousand virtual domains on a 
	box you just can't have PTR records for all of them.

	Mark
-- 
Mark AndrewsISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: [email-masked]
Date: Mon, 31 Mar 2008 20:27:13 +0000

> 	Multiple PTR records do not scale.

	what does that mean Mark?
	
	why does "Multiple A records" scale and not others?
	is this a DNS protocol issue or an implementation artifact?

> 	followed this path and exceeded the 64K DNS message size

	and the same failure would be true for multiple instances
	of any RR type. 

> 	box you just can't have PTR records for all of them.

	and apparently you can't have A records for them either.

> 	Mark

	so the actual spec limit is any mixture of RR types that
	will fit into a 64k DNS message on TCP.  Right?

--bill

---

From: [email-masked]
Date: Mon, 31 Mar 2008 20:27:13 +0000

--bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Apr 2008 07:55:26 +1100

> 	is this a DNS protocol issue or an implementation artifact?

	Multiple PTR records scale worse than multiple A records.

	You get ~4000 A records in 64K.
	You get ~2000 AAAA records in 64K.

> 	and the same failure would be true for multiple instances

	Yes.  It's just very very rare for there to be enough of
	the other types to cause a problem.

	It's not uncommon for there to be too many PTR records to
	cause a problem especially when you start advocating that
	each address records needs a corresponding PTR record.  The
	only reason we don't see more problems is that people have
	been saying that it is a waste of time to have multiple PTR
	records.

-- 
Mark Andrews, ISC

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Apr 2008 07:55:26 +1100

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Mar 2008 22:23:20 -0400

Mark,

> 	been saying that it is a waste of time to have multiple PTR

Does the current draft's language address worries you have here?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Mar 2008 22:23:20 -0400

Mark,

A

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2008 10:36:28 -0400

>	Multiple PTR records scale worse than multiple A records.

That sentence is hard to parse.

I looked at the draft again and this thread.

The issue is not clear.  Yes, you can have multiple PTR records. 
Yes, there is a limit on how many records of any type can be in an 
RRset while fitting into the maximum DNS message size.

The doc says you should consider the consequences, which is about as 
accurate a statement as can be given.  However maybe more detail 
should be in the document.

Such as:

Multiple PTR records can be stored in a single PTR RRset.  If a 
device at an IP address (v4 or v6) has multiple identities with 
domain names, it would be good to have a PTR for each.  However, this 
is not always practical.  In some operational situations, an address 
may have thousands of domain names holding an address record (A or 
AAAA) with the address as the value.

The number of address records in an PTR set before tripping the upper 
limit on what can fit on even a TCP carried DNS message is 
approximately 4000 for A RR only and about 2000 for AAAA RR only.

If an address has just a few corresponding forward map records, it is 
worth entering them all.  If an address has many, a better strategy 
is to enter a few as is needed, adding more only when there is an 
operational request.

>	been saying that it is a waste of time to have multiple PTR

No, I don'tFrom [email-masked]  Tue Apr  1 07:37:43 2008
Date: Tue, 1 Apr 2008 10:36:28 -0400
To: Mark Andrews <[email-masked]>
From: Edward Lewis <[email-masked]>
Cc: Peter Koch <[email-masked]>, [email-masked],
	Edward Lewis <[email-masked]>, IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse
 Mapping"
Sender: [email-masked]

>	Multiple PTR records scale worse than multiple A records.

That sentence is hard to parse.

I looked at the draft again and this thread.

The issue is not clear.  Yes, you can have multiple PTR records. 
Yes, there is a limit on how many records of any type can be in an 
RRset while fitting into the maximum DNS message size.

The doc says you should consider the consequences, which is about as 
accurate a statement as can be given.  However maybe more detail 
should be in the document.

Such as:

Multiple PTR records can be stored in a single PTR RRset.  If a 
device at an IP address (v4 or v6) has multiple identities with 
domain names, it would be good to have a PTR for each.  However, this 
is not always practical.  In some operational situations, an address 
may have thousands of domain names holding an address record (A or 
AAAA) with the address as the value.

The number of address records in an PTR set before tripping the upper 
limit on what can fit on even a TCP carried DNS message is 
approximately 4000 for A RR only and about 2000 for AAAA RR only.

If an address has just a few corresponding forward map records, it is 
worth entering them all.  If an address has many, a better strategy 
is to enter a few as is needed, adding more only when there is an 
operational request.

>	been saying that it is a waste of time to have multiple PTR

No, I don think that's the reason.  I think we don't see "more 
problems" is that "it isn't that much of a problem" and possibly 
"where it could be a problem, people just don't put many in."

I don't think it is a waste of time.  The two downsides - the very 
real cap on the number of possible records (as mentioned above) and 
applications that aren't written correctly enough to handle the 
situation.

>>  	and apparently you can't have A records for them either.

The confusing element here is that this is a case of having -

5000 domains with one A record versus 1 domain with 5000 PTR records

It's not 1 domain with 5000 AAAA's => 1 domain with 5000 PTR's.  The 
problem is not symmetric.

>>  	will fit into a 64k DNS message on TCP.  Right?

I suppose so.

't think that's the reason.  I think we don't see "more 
problems" is that "it isn't that much of a problem" and possibly 
"where it could be a problem, people just don't put many in."

I don't think it is a waste of time.  The two downsides - the very 
real cap on the number of possible records (as mentioned above) and 
applications that aren't written correctly enough to handle the 
situation.

>>  	and apparently you can't have A records for them either.

The confusing element here is that this is a case of having -

5000 domains with one A record versus 1 domain with 5000 PTR records

It's not 1 domain with 5000 AAAA's => 1 domain with 5000 PTR's.  The 
problem is not symmetric.

>>  	will fit into a 64k DNS message on TCP.  Right?

I suppose so.