Subject: wrt: draft-ietf-dnsop-inaddr-required-00.txt

From: Robert Elz <[email-masked]>
Date: Sun, 13 Aug 2000 16:54:12 +1000

Sorry people, this draft is a total waste of time.

I'm an absolute supporter of properly running in-addr.arpa domains,
and if someone wanted to write an RFC to explain to people what they're
useful for, and why the data needs to be maintained, that would be fine.

But to pretend to make it a requirement (on anyone) to maintain the
things is just silly.

Worse than that, the doc just says that the data needs to exist, it
doesn't (and cannot rationally) say that it has to contain anything
particularly sensible, so

	1.0.0.127.in-addr.arpa	IN	PTR	127.0.0.1.

would be just a fine (and totally useless) PTR record to include (and
the point here has nothing to do with my choice of the loopback address
to use - that's just an arbitrary example - any other number could be used).

Similarly
	*.0.0.127.in-addr.arpa	IN	PTR	bogus.example.com.

would also satisfy the requirements, but is no use to anyone at all.

Then there's this paragraph ...

   Many applications use DNS lookups for security checks. To ensure
   validity of claimed names, some applications will look up IN-ADDR
   records to get names, and then look up the resultant name to see if
   it maps back to the address originally known. Failure to resolve
   matching names is seen as a potential security concern.

which doesn't seem to have any relevance whatever.   If the IN-ADDR
lookup fails (which is what is of concern to the draft) then there is
no name to look up the address of, and the stuff about comparing with
the originally known address is irrelevant.

Making any requirements in this area is close to hopeless, and attempting
to do so by specification is completely hopeless, those who don't care
will continue to not care, those who do care, don't need a requirement
like this.   The only ways to get people to have this done correctly are
straight out education (which this draft isn't), or by having things fail
to work if the in-addr.arpa zone isn't correct (the way that some FTP servers
used to refuse anonymous logins if the in-addr.arpa of the source wasn't
correct.)  Unfortunately, these days, getting anyone who could make a
difference to refuse connections for any reason at all is not likely to
have a lot of success - the advantage is all on the side of getting as many
people as possible to connect to your web server (which is almost all that
matters), not to prevent anyone getting there, unless they're doing you
active harm.

kre

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Aug 2000 10:11:34 -0400

At 2:54 AM -0400 8/13/00, Robert Elz wrote:
>like this.

This isn't about the contents of the draft, but rather the justification
for including this in the working group...

I am not sure whether I completely disagree with this, or agree
whole-heartedly.

On one hand, the IETF has no enforcement mechanism.  There is no "RFC 3872
compliant" branding that is acheived by passing some round of
interoperability tests.  In that sense, the IETF can never really require
anything.

Besides the lack of enforcement of conformance, many specifications are not
written in a style that is easily translated into a set of requirements and
into a set of testing documents.  I know of one case where an organization
wanted software to conform to an RFC, but determinted that it would take a
lot of time to determine if the/any software was actually compliant becuase
of the looseness of the wording in the RFC.

(BTW, is there a hard/legal/contractural requirement to use IP on the
Internet?)

With that said, I agree with the comment.  However, there is another way in
which this draft can be "used."

I think it is important that a document specify "good behavior" of a
well-run and well-configured element of the network (in this case DNS,
specifically reverse map).  This is important to have so that an ISP can be
held accountable for failing to provide this service.  (I'm thinking of an
ISP "playing dumb" to avoid costs, or an ISP that is insufficiently
prepared to do their job.)

This document will not give the IETF (whatever *that* is) the legal muscle
to go to an ISP and shut them down because they aren't running reverse
maps.  This document should be a resource by which a customer or network
peer of an ISP can refer when trying to get reverse map service instituted.

So, in that sense, I disagree with the original comment.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 14 Aug 2000 10:58:21 -0400

>At 2:54 AM -0400 8/13/00, Robert Elz wrote:

...

>prepared to do their job.)

by having a BCP RFC on this subject,
+ a customer of an ISP can:
  - refer to it in the RFP for ISPs
  - refer to it in the written contrat with its ISP
+ media/others/... can:
  - refer to it.

So, even without an enforcement mechanism, a good BCP can be useful.

So I disagree with Robert and agree with Edward.

Marc.

>So, in that sense, I disagree with the original comment.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 14 Aug 2000 17:55:28 +0200

> (BTW, is there a hard/legal/contractural requirement to use IP on the

I thought that part of the definition of the Internet was use of IP.

Shane

---

From: Alex Kamantauskas <[email-masked]>
Date: Mon, 14 Aug 2000 11:51:25 -0400 (EDT)

> I thought that part of the definition of the Internet was use of IP.

 Is there a standard definition of "the Internet"?

-- 
Alex Kamantauskas
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Aug 2000 13:15:21 -0400

> Is there a standard definition of "the Internet"?

Not so far as I know - in fact, in the US, "Internet" was (and may be still
is) a trademark held by a non-IP entity.  The/an automated bank teller
network (ATM's) was built by someone and they called it the Internet and
were granted a trademark.  This issue was debated by the ISOC board, they
presented reports on this at the most recent Washington, D.C., IETF.

I will say this, not in hopes of starting a flame war/red
herring/inappropriate thread, but in the hopes of clarifying my statement
that started this...

If I were to dial in to my home ISP and sent them Appletalk, and they
forwarded Appletalk to others, the IETF (again, whatever that is) cannot
stop this.  (Nor would I expect anyone to really want to.)

This is what I envisioned when I said there's nothing requiring I use IP...

PS - Appletalk, DECnet, NetBUI, insert your favorite protocol.

---

From: Gunnar Lindberg <[email-masked]>
Date: Tue, 15 Aug 2000 11:39:21 +0200 (MET DST)

Personally I see absolutely no harm in a (BCP) RFC saying "do this",
regardless of available "enforcement mechanisms".

Some people understand the reasons that you want described; they
already run .in-addr.arpa NSs. Other don't, but would not care to
read anyway. For some of those it would help to simply have an RFC
to point to - "please read RFCxyz.txt".

So, if for nothing else please move this draft forward.

	Gunnar Lindberg

>From [email-masked]  Sun Aug 13 09:02:40 2000
>From: Robert Elz <[email-masked]>
>To: [email-masked]
>Subject: wrt: draft-ietf-dnsop-inaddr-required-00.txt
>Date: Sun, 13 Aug 2000 16:54:12 +1000
>Message-Id: <[email-masked]>

---

From: Lars-Johan Liman <[email-masked]>
Date: Tue, 15 Aug 2000 12:25:43 +0200

> regardless of available "enforcement mechanisms".

I'm for rev-DNS, but for me to be able to tell others to do it, with a
clear conscience, I need to have a motivation, and that should be a
motivation that I can take to limited-IP-clue-people, and say "this is
why you should have reverse DNS".

With forward DNS I can:

  Technician: If your forward DNS doesn't work, people can't get to
              your web pages, an cannot shop from your web shop. We would
              lose money.
  Customer:   Oh?! That's bad! Please make sure it works.

But:

  Technician: If your reverse DNS doesn't work, my friends on the 'net
              cannot help us to solve problems, and it _may_ be that
              we have problems reaching one or two ill-configured web
              sites out there.
  Customer:   Who cares?! The 'net works now, and I don't care about
              those web sites anyhow.

Help us find and formulate such a motivation, and put it in the
document, and we'll all be happier for ever on! (TM) :-)

If we can't find a _good_ motivation, I see no basis for the document
to become a BCP. The motivation is really the big point here.

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, Systems Specialist	! E-mail: [email-masked]
# KTH Network Operations Centre         ! HTTP  : //www.sunet.se/~liman
# Royal Institute of Technology, Sweden	! Voice : Int +46 8 - 790 65 60
#----------------------------------------------------------------------

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Aug 2000 04:18:59 -0700

>               we have problems reaching one or two ill-configured web

and many sites out there check before letting you web to them or even accept
mail from you.

randy

---

From: Lars-Johan Liman <[email-masked]>
Date: Tue, 15 Aug 2000 14:52:16 +0200

[email-masked]:
> and many sites out there check before letting you web to them or
> even accept mail from you.

Yes, sure, but is that A Good Thing (TM) or is it broken behaviour?

It's like:

Hotel:	We won't take your reservation unless you give us your credit
	card number.

... and I can give them any number I want, and they think they are
happy campers and safe and secure. I wouldn't like to see it mandated
that the hotels ask for credit card numbers, because it's broken
behaviour.

Is the behaviour to check and verify reverse lookup something that we
really want to encourage? Then why? There are lots of legal situations
where the forward lookup mismatches the reverse lookup, and there is
IMHO no real security to be gained from checking the reverse
name. And, it adds to the general load of the Internet.

So, what is _REALLY_ the LOGICAL reason for having to provide reverse
information.

Again, I'm not advocating not doing rev-DNS, I'm just trying to find
out _why_ it should be done.

				Cheers,
				  /Liman

---

From: Kent Crispin <[email-masked]>
Date: Tue, 15 Aug 2000 06:02:38 -0700

> and many sites out there check before letting you web to them or even accept

Does anyone have any numbers on this?  

-- 
Kent Crispin                               "Do good, and you'll be
[email-masked]                           lonesome." -- Mark Twain

---

From: Kent Crispin <[email-masked]>
Date: Tue, 15 Aug 2000 06:43:39 -0700

On Tue, Aug 15, 2000 at 02:52:16PM +0200, Lars-Johan Liman wrote:
> where the forward lookup mismatches the reverse lookup,

Named virtual hosts (where one IP serves many virtual domains, and only
one of them could be the proper in-addr, and the browser supplied name
is used to disambiguate).  There are millions of these.  Most of them
are used only for web sites with email, and web servers and email
servers typically don't do the check that Randy describes (what's the
inverse address of a mx record?)  So for web and email, you can't 
require in-addr.

In any case, the number of domains with no in-addr is huge, and will 
remain so.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 15 Aug 2000 10:08:49 -0400

> Yes, sure, but is that A Good Thing (TM) or is it broken behaviour?

Not sure it matters. It's a wide-spread practice, easily implemented
with sendmail, and so it's a problem. For this working group, the
question is how to word a document strongly encouraging network
operators to provide inaddr mappings. There's a much greater likelihood
of getting network operators to fix their inaddr mappings than there is
of getting every mail server in the world to stop relying on such
mappings.

> really want to encourage?

Ask it another way: if folks are doing this already, should we encourage
network operators to make sure inaddr at least functions properly so
that IT is not contibuting to end user problems?

> Then why? There are lots of legal situations

Yet we know SSHD does it, sendmail does it, and some web servers do it
too. These programs are going to make the inaddr lookups regardless.
We're not going to alter or encourage that by NOT publishing a BCP on
this subject. The BCP needs to point out that present use of this
information exists, not that we think it's a good idea.

Dan

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Tue, 15 Aug 2000 14:52:43 +0000 (UCT)

On Tue, 15 Aug 2000, Lars-Johan Liman wrote:

| [email-masked]:
| > and many sites out there check before letting you web to them or
| > even accept mail from you.
| 
| Yes, sure, but is that A Good Thing (TM) or is it broken behaviour?

  Is this requirement going to scale reasonably into the day when every
appliance in my kitchen is connected to the network and has its own
address?

  I've never really been convinced that the reverse lookup stuff is that
helpful.  As I see it there are basically two ways to get at the
administrative information regarding who 'owns' or is otherwise
responsible for a given block of IP addresses: 1) DNS PTR records or 2)
properly SWIP-ped address allocations.  ISPs tend to fail to do both of
these consistently.  If they do, I suspect they tend to be
over-generalized (i.e. general mappings for large portions of the entire
block in the case of PTR).

  My first reaction to this document was 'so what', but I see the merits
of recommending this as a BCP.  Using DNS for this purpose isn't going to
be a panacea for identifying responsibility domains for addresses, but I
don't see what harm it could do, and would at least provide a standard
document for reference purposes.

  -bws

---

From: Lars-Johan Liman <[email-masked]>
Date: Tue, 15 Aug 2000 17:01:31 +0200

[email-masked]:
> Ask it another way: if folks are doing this already, should we
> encourage network operators to make sure inaddr at least functions
> properly so that IT is not contibuting to end user problems?

Well ... it's one thing to say "everyone does this, so therefore you
should too", but a BCP to me is really a "Best Current Practice",
meaning "this is what a bunch of enlightened experienced people think
is the best for the Internet". I'm not sure "doing what everybody else
does" is the best for the Internet.

I have no problems publishing an informational RFC stating the common
behaviuor on the 'net, and how to co-exist with it. But I would
hesitate to call it a BCP, unless there is proper technical motivation
for it.

The cause-consequence relationship is wrong in "applications do these
strange lookups, therefore give them what they want". It should be
"there is reliable reverse DNS, therefore applications are welcome to
use it", but the latter is sofar untrue. We want to make it true. To
do that we have to start with the first part of it, "there is reliable
reverse DNS". Now why do we have to provide reliable reverse DNS to
the applications?

Maybe I should formulate it thus: Why should an application be able to
expect proper data in the reverse DNS?

In the forward DNS case there is a logical answer. The domain name is
an abstraction layer, making it easier for humans to remember Internet
addresses and information pointers, and facilitating change of the
underlying infrastructure without changing these addresses. Now, what's
the counterpart of that in the rev-DNS case?

And, yet again: I _really_ honestly want to know! I've been looking
for this reason for _years_, and so far my logical brain is
dissatisfied. I'm willing to accept going to a BCP if I hear many
voices saying that my demands are too high, so please speak up,
working group! :-)

				Cheers,
				  /Liman

---

From: Daniel Senie <[email-masked]>
Date: Tue, 15 Aug 2000 11:10:34 -0400

> does" is the best for the Internet.

We're talking about a BCP on DNS INADDR, not a BCP about sendmail. I'd
like to focus the discussion of whether we should or should not publish
a document on that first. The CONTENT of the BCP, talking about the
different applications that might run into trouble is another point of
discussion.

Perhaps an additional document should be something like "stupid DNS
tricks, or what NOT to do with the DNS system." That might better
address your concerns about people doing stupid things. In the mean
time, I'd like to see ISPs have more encouragement to actually get their
INADDR tables set up and/or set up properly.

---

From: Lars-Johan Liman <[email-masked]>
Date: Tue, 15 Aug 2000 17:11:33 +0200

[email-masked]:
> Is this requirement going to scale reasonably into the day when
> every appliance in my kitchen is connected to the network and has
> its own address?

I see that as less of an issue. If we require that people do it, they
will make it scale. By the time your stove reads e-mail, DHCP and
dynamic DNS will be well deployed.

> helpful.

Well, if you're a network admin, traceroutes with text in them is
_really_ helpful at times, provided that the rev-DNS is to some degree
correct. Being able to see that my packet from Sweden go through
Washington DC to reach Spain, gives me a lot of info. With regards to
hosts, its useful when the forward DNS is wrong. "ping foo.org" tells
you "trying bar.net" and you realise that there might be more to
investigate. So there is benefit, but not for the party providing the
information - that's the quirk.

> My first reaction to this document was 'so what', but I see the
> merits of recommending this as a BCP.  Using DNS for this purpose
> isn't going to be a panacea for identifying responsibility domains
> for addresses, but I don't see what harm it could do, and would at
> least provide a standard document for reference purposes.

Someone is going to question the "rules" if there is no motivation for
them. "Why should I put costly manpower into maintaining this if it's
just for someone else's convenience?"

				Cheers,
				  /Liman

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Aug 2000 11:57:22 -0400

>different applications that might run into trouble is another point of

IMHO, the thread is converging on this position:

We want to pursue the document.  Further, the document needs to cover the
technical rationale of why rev-maps are necessary, or are just a good idea,
or are just window dressing.  (Along with addressing other concerns Robert
Elz mentioned.)

If the document justifies the need for rev-map, then this is a BCP.  Else,
it is headed for informational.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 15 Aug 2000 12:15:28 -0400

> just for someone else's convenience?"

The same argument can be made for other BCPs I've worked on, Ingress
filtering (RFC 2827) and directed broadcast disable (RFC 2644). One of
the reasons to publish a BCP is to remind folks that something might be
for the good of the whole 'net. While each of these areas is less useful
to the network operator themselves, when they're affected by someone
else's network not doing these things, they might change their minds.

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Tue, 15 Aug 2000 16:30:52 +0000 (UCT)

On Tue, 15 Aug 2000, Daniel Senie wrote:

| The same argument can be made for other BCPs I've worked on, Ingress
| filtering (RFC 2827) and directed broadcast disable (RFC 2644). One of
| the reasons to publish a BCP is to remind folks that something might
| be for the good of the whole 'net. While each of these areas is less
| useful to the network operator themselves, when they're affected by
| someone else's network not doing these things, they might change their
| minds.

  The ingress filtering proposal was also known as the 'good neighbor
policy' if I recall correctly.  I think that this proposal can be
positioned similarly.

  Realistically most large ISPs didn't do a great job of implementing that
proposal (I know UUNET doesn't for example, and we tried to implement this
at ANS but the effort involved made it somewhat infeasible), but least
there was a document that said what operators 'should' be doing.

  -bws

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 15 Aug 2000 10:02:34 -0700

I've been trying to stay out of this, but I just can't help myself.

This draft misses the point completely! The goal is not to require PTR 
records, since as it is pointed out, "xxx" is a perfectly valid value 
according to the draft and gives no useful information. Also, despite the 
title, there is not one MUST in the document so there are no requirements set 
forth.

IMO, for this draft to have value it must take on the issue of what is 
meaningful in PTR records. That would be worth a BCP, and pointing at it might 
produce useful benefit to the Internet. Text reenforcing the importance of 
general use of PTRs would be an appropriate part of such a BCP, but is not 
useful on it's own.

To do this, the draft must briefly examine the uses of PTR records and make 
some recommendations that find a balance between narrow and broad. It could 
even make references to things like LOC, that could also be useful if 
generally deployed. This follows nicely the questions that the chair posed.

I also believe that there needs to be a paragraph in the security section of 
any draft that reenforces the need to not blindly accept the information given 
in the PTR record.

jerry

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Aug 2000 10:16:54 -0700

it is not mine to tell hotels how to feel secure.  i have only one lance,
in questionalbe condition, and there is a *large* number of windmills.

so the question may be that we are so opposed to this particular windmill
that we feel a moral imperative to refuse to support it by using the fact
of its existence as a reason for our particular cause.

randy

---

From: Simon Josefsson <[email-masked]>
Date: 15 Aug 2000 19:06:29 +0200

> just for someone else's convenience?"

I don't think a BCP has to dictate what should be Right Thing for
everyone, just what's good for the net as a whole and what would
improve interopability.

If people were to think "I'm spending money to make other peoples life
easy", I can't see why they would follow any IETF "standards" at all.
Most cost manpower to maintain.  Supporting IP, SMTP, HTTP, DNS and
even rev-DNS is a investment in infrastructure, they don't generate
revenues themself.

Just my $.2 worth.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 15 Aug 2000 10:47:27 -0700

> Most cost manpower to maintain.

Yep. People ignore important stuff all the time simply because they don't
see any direct benefit from doing what's best for the network as a whole.
There are loads of ISPs who are using private addresses on network
interfaces that are publically accessible, for example, which is not only
bad form but which is potentially harmful in many situations.

In this regard, a BCP could help to elevate awareness of proper management
of the PTR space, but I seriously doubt it will have any measurable
impact. At best, a few organizations will be told that the Internet wishes
they would do such and such, but overall there would be no significant
impact. This doesn't mean it shouldn't be done though.

There are absolute benefits from properly managing the PTR space. All a
BCP has to do is itemize them, point out alternate uses such as the
1101-style network PTRs, point out issues such as public addresses being
unresolvable on the public Internet and that all PTRs are succeptible to
spoofing, and generally act as a generic target for "this is what is
suggested by the Internet community" referrals for folks with complaints.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Daniel Senie <[email-masked]>
Date: Tue, 15 Aug 2000 16:40:44 -0400

> title, there is not one MUST in the document so there are no requirements set

At the DNSOP meeting, I received a lot of negative feedback about the
use of MUSTs, so I changed them. I guess I'm wrong either way.

> generally deployed. This follows nicely the questions that the chair posed.

I don't disagree. I welcome all input.

> any draft that reenforces the need to not blindly accept the information given

Good input, thanks.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Aug 2000 09:51:05 +0200

> and many sites out there check before letting you web to them or even accept

I don't know about "many".  After all, it is in the recipient's best 
interest to receive mail!  I imagine most customers would be quite 
concerned, and probably switch providers, if they reported that they 
weren't getting certain mails, and the ISP started mumbling about the 
sender "has incorrectly configured DNS IN-ADDR APRA".  To the customer, 
this would sound like, "our dilithium crystals aren't aligned".

Here's the list of problems I've noted with incorrectly configured 
IN-ADDR.ARPA:

1. IRC won't work very well (I don't know about AIM, ICQ, or any of 
those happy new lightweight IRC replacements) - a lot of servers 
require proper IN-ADDR for some reason

2. You can't download a lot of software with strong encryption, as a 
lot of the sights distributing such software (incorrectly) use your 
source IP to verify you're not trying to download software from one of 
the 6 or 7 countries the Hill & Mr. Bill don't like

3. Connecting to some sights takes a bit longer - this is caused by the 
server at the other end trying to tell you where you're coming from 
(duh), and having to wait for DNS to timeout (e.g. "you are FTP user 13 
of a maximum of 50, connecting from foo.bar.mil")

That's about it.  I've never noticed e-mail being dropped.

Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Aug 2000 11:56:54 +0200

> 	Can we kill this legend.
> 
> 	Returning NXDOMAIN takes the same amount of time as returning
> 	a PTR record.
> 
> 	If there are delays it is not due to the DNS unless there is a
> 	bad delegation.  A more usual cause is IDENT and firewalls that
> 	block / do not generate ICMP responses.

It's a simple 3 step process:

Step 1:  Company changes DNS servers
Step 2:  Company doesn't notify ARIN
Step 3:  There's no step 3!

The legend lives on.  Apologies to Steve Jobs.

Shane

---

From: Simon Josefsson <[email-masked]>
Date: 16 Aug 2000 12:25:05 +0200

> That's about it.  I've never noticed e-mail being dropped.

As a postmaster, I receive ~5 bounces / day for mail that aren't
delivered, since our ISP can't delegate (or even insert) information
about our IP in the in-addr.arpa tree.  So it's certainly an issue for
mail too.

Oh, and there's the nslookup issue too. :-)

---

From: Ray Plzak <[email-masked]>
Date: Tue, 15 Aug 2000 12:20:08 -0400 (EDT)

I agree with Ed in regards to BCP or Informational.  The justification
needs to be strong in either efficent performance or security.

Ray

On Tue, 15 Aug 2000, Edward Lewis wrote:

> Date: Tue, 15 Aug 2000 11:57:22 -0400
> From: Edward Lewis <[email-masked]>
> To: Daniel Senie <[email-masked]>
> Cc: Lars-Johan Liman <[email-masked]>, [email-masked]
> Subject: Re: wrt: draft-ietf-dnsop-inaddr-required-00.txt
> 
>

---

From: [email-masked]
Date: Wed, 16 Aug 2000 19:42:53 +1000

Can we kill this legend.

	
	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Aug 2000 15:21:20 +0200

> 	Nothing special w.r.t. reverse zones here.  Companies do this with
> 	forward zones all the time, s/ARIN/registrar/.

Except that if my forward delegation doesn't work, nobody can come to 
my web pages.  Even the CEO will notice that (well, after his secretary 
points it out to him).  From the end user point of view, if forward 
delegation doesn't work, the host isn't on the Internet (whatever "the 
Internet" is).

Given the severity of the problem, the solution is going to be quickly 
forthcoming.  In the IN-ADDR.ARPA case, the solution may never come, 
which is what we're talking about here, I thought.

> 	Note: I qualified my comments w/ "unless there is a bad
> 	delegation" which is what you are describing.

Sorry about that.  Would it be a good idea do you think to do some spot 
checking on the number of timeouts we see from the advertised space on 
the Internet (on the theory that knowledge is better than ignorance)?  
Or do you have numbers about NXDOMAIN returns versus timeouts on the 
Internet that you can share?

Shane

---

From: Daniel Senie <[email-masked]>
Date: Wed, 16 Aug 2000 10:04:52 -0400

> which is what we're talking about here, I thought.

As this discussion progresses, I'd like to suggest the following: We
either work toward a BCP document which says:

1. IN-ADDR mappings are required, MUST be properly configured, and
explains why.

or.

2. IN-ADDR mappings are entirely optional, MUST NOT be used for
authentication under any circumstances (i.e not even if the IN-ADDR PTR
result is then looked up to verify), and explains why.

EITHER of these is an outcome I'd support. If there's no overriding
reasons identified as to why there MUST be a mapping, then perhaps it's
time to stop trying to get people to do them. If that is the ultimate
result of this draft, then we at least need the application developers
know we don't think it'll ever be workable.

Right now, at least 15% of the end-user stations are not covered by
pointer records (data from some very active websites I host). This
covers dialups, corporate networks, DSL subnets, etc.

---

From: [email-masked]
Date: Wed, 16 Aug 2000 23:02:44 +1000

Mark

---

From: Jerry Scharf <[email-masked]>
Date: Wed, 16 Aug 2000 08:34:59 -0700

I completely agree with Daniel's last pos with one addition. For the BCP to be 
effective, we should give the operator "some" guidance on how as well as why. 
They are free to ignore this guidance, but it will point up the issues to be 
considered in choosing the PTR names.

jerry

---

From: Peter Koch <[email-masked]>
Date: Thu, 17 Aug 2000 17:33:10 +0200

> voices saying that my demands are too high, so please speak up,

I agree that the BCP should motivate, not just demand reverse mapping.
Two issues I mentioned in a private comment on an earlier version of this draft:

o One reason for not providing reverse mapping is lack of knowledge of the
  ``classless delegation'' technique, which should be referenced in the
  document. In addition, some DNS server software does or did make this
  job harder.

o Not providing reverse mapping increases the amount of DNS traffic and
  load on DNS servers, because negative responses are either not cached or
  cached for a shorter time than PTR answers. We're serving the reverse
  mapping for several /16 address ranges and see several peaks for non
  rev'mapped areas. Of course, this is not primarily a problem for end
  customers.

-Peter

---

From: Bill Manning <[email-masked]>
Date: Thu, 17 Aug 2000 23:19:46 -0700 (PDT)

% > Except that if my forward delegation doesn't work, nobody can come to
% > my web pages.  Even the CEO will notice that (well, after his secretary
% > points it out to him).  From the end user point of view, if forward
% > delegation doesn't work, the host isn't on the Internet (whatever "the
% > Internet" is).

	Based on applications use of the name->address mapping
	Few (if any) existing applications use the address-name mapping.
	
	Some applications try to strengthen the integrity check by
	verifying that the name-address & address-name pairs are
	consistant. Thats -one- step up on the authenication ladder
	and in the absence of any other methods is useful.
	
% As this discussion progresses, I'd like to suggest the following: We
% either work toward a BCP document which says:

	"... work toward a BCP..." is just plain wrong. One documents
	BCPs, not create them on the fly.

% 1. IN-ADDR mappings are required, MUST be properly configured, and
% explains why.
% 
% or.
% 
% 2. IN-ADDR mappings are entirely optional, MUST NOT be used for
% authentication under any circumstances (i.e not even if the IN-ADDR PTR
% result is then looked up to verify), and explains why.

	What applications could be enabled by accurate address-name
	maps?  How can we help enable this?  #1 is closer than #2.

% Right now, at least 15% of the end-user stations are not covered by
% pointer records (data from some very active websites I host). This
% covers dialups, corporate networks, DSL subnets, etc.

	Some preliminary data indicates that the accuracy of 
	the forward database (TLDs et.al.) has dropped below
	the accuracy of the inverse database (in-addr.arpa)

% -----------------------------------------------------------------
% Daniel Senie                                        [email-masked]
% Amaranth Networks Inc.                    http://www.amaranth.com
% 

-- 
--bill