Subject: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Apr 2007 06:31:00 +0200

After having read 5 mails from Frank on the issue, I still am not sure 
whether Frank supports adding it as a tracked issue or not.
But we might as well get on with it.

The issue concerns the following text in USEPRO-07:

   The <path-identity> used by an agent may be chosen via one of the
   following methods (in decreasing order of preference):

   1.  The fully-qualified domain name (FQDN) of the system on which the
       agent is running.

   2.  A fully-qualified domain name (FQDN) within a domain affiliated
       with the administrators of the agent and guaranteed to be unique
       by the administrators of that domain.  For example, the
       uniqueness of server.example.org could be guaranteed by the
       administrator of example.org even if there is no DNS record for
       server.example.org itself.

   3.  Some other (arbitrary) name in the form <path-nodot> believed to
       be unique and registered at least with all the other news servers
       to which that relaying agent or injecting agent sends articles.
       This option SHOULD NOT be used unless the earlier options are
       unavailable or unless the name is of longstanding usage.

As far as I can tell, Charles is proposing that the second option should 
have a "SHOULD NOT be used" attached to it, just like the third.
As far as I can tell, Frank does not see a benefit to such a change.
No other people have contributed to this thread.

The discussion of mail addresses to reach sites remains #1093, and is not 
part of this issue#.

                 Harald (in role as issue tracker)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 04 Apr 2007 08:21:35 +0200

My technical opinion (chair hat OFF):

The requirement on a path-identity is uniqueness only. Option 2 
guarantees uniqueness as well as option 1 does. Resolvability gives no 
extra value for the uniqueness requirement.

I support "no change required" as the resolution of this issue.

Harald

Harald Tveit Alvestrand wrote:
> As far as I can tell, Charles is proposing that the second option 
> should have a "SHOULD NOT be used" attached to it, just like the third.
> The discussion of mail addresses to reach sites remains #1093, and is 
> not part of this issue#.
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 4 Apr 2007 10:34:49 GMT

>No other people have contributed to this thread.

More or less. I think I would rather combine #1 and #2 by saying that it
SHOULD be a fully-qualified domain name (FQDN) resolvable, to
MX/A/AAAA/CNAME, in the DNS, which amounts to much the same thing.

That still leaves a chink for someone who convinces himself that his case
is extra special to violate that SHOULD.

>The discussion of mail addresses to reach sites remains #1093, and is not 

I accept that we are not going to make any normative statement regarding
mail addresses to reach sites, but I would still like to see a NOTE
pointing out the existence of RFC 2142, which implementors than then decide
for themselves whether to follow. Something like:

   NOTE: According to [RFC 2142], the forms "usenet@<path-identity>" and
   "news@<path-identity>" are common addresses for a news server
   administrator.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 04 Apr 2007 08:06:04 -0400

I support no change required.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 4 Apr 2007 13:46:20 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>>No other people have contributed to this thread.

I reread 2142, and see that it expects either #1 or the top level FQDN
for the organisation (which #2 covers)

>MX/A/AAAA/CNAME, in the DNS, which amounts to much the same thing.

only the desperate look at the path ... everyone else looks at the
injection info to find out who to talk to

        X-Complaints-To: [email-masked]

because what people complain about is the injection of an article not
the fact that it has propagated.

Although there seems to be some feeling that people regularly want to
write to news servers in the middle of propagation paths in order to
discuss the mangling of articles (or some other wickedness), that
doesn't sound like the real world to me.  Those who chase down such
obscure things are probably capable of driving search engines,
corresponding with other Usenet administrators, and finding out who to
talk to by out-of-band techniques [which probably eschew role addresses
because getting things done means getting another specific sysadmin to
own the problem for you]

As Harald say, it's only uniqueness that matters to the protocol, and
being non-unique only damages you and your clone -- except in corner
cases where servers are downstream of a single major server...

>   "news@<path-identity>" are common addresses for a news server

X-Trace and X-Complaints-To  arrived in INN pretty much the same time as
2142 came out...   which will be why 2142 documented the only method
widely available at that time...

bottom line: I don't see a need for the SHOULD NOT, and I'm not deeply
in favour of giving 2142 a plug.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Dan Schlitt <[email-masked]>
Date: Wed, 4 Apr 2007 11:48:22 -0400

I agree with Harald. In my experience running a news server only the
uniqueness of the names on the path was useful.

/dan

-- 

Dan Schlitt
[email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 5 Apr 2007 11:32:56 GMT

>for the organisation (which #2 covers)

I don't think #2 covers 2142, because if it is neither an MX nor an A
record, then there is no way to send email to
abuse/news/postmaster/whatever @ it.

My main objection to #2 is that I regard it as a sloppy practice which I
don't want to legitimize (thus a guy who wants to do it has to bear the
stigma of breaking a SHOULD NOT - that does not mean the sky will fall
in).

>injection info to find out who to talk to

Sure. You only want to mail someone in the middle of the Path is you want
to draw his attention to some technical problem at his site

>in favour of giving 2142 a plug.

I would only give it the mildest of plugs. For sure it would be
informative and not normative.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 11 Apr 2007 17:24:05 GMT

>The issue concerns the following text in USEPRO-07:

I have had some further thoughts on this.

>   following methods (in decreasing order of preference):

Maybe s/may/SHOULD/

>   1.  The fully-qualified domain name (FQDN) of the system on which the

That seems to be only half the story. AIUI, normal current practice is to
provide either

a. An FQDN with an A or AAAA record that identifies the system like you
say, or

b. An FQDN with an MX record enabling email contact, but not identifying
the system, or even

c. An FQDN with both an A (or AAAA) -and- and MX (best of both worlds).

I don't think we want to express any preference between these, but
currently we don't seem to recognize case b at all. May I therefore
suggest:

    1.  A fully-qualified domain name (FQDN) resolving to either (or both)
        of
	   . an A or AAAA record identifying the system on which the agent
             is running;
           . an MX record enabling email contact with the administrators
             of that agent (e.g. using one of the role names suggested in
             [RFC 2142]).

{where "suggested" is about the weakest or various possible terms that
might be used there, and the reference to RFC 2142 is clearly just
informational}

>       server.example.org itself.

Well, you know I am not happy about that. But would it not be clearer (and
more accurate) to say that the FQDN must be within a zone whose SOA record
clearly identifies, or belongs to, the administrators of that domain (who
are then responsible for ensuring its uniqueness). I.e., if you start with
the FQDN and chop off components from the left, then you must assuredly
arrive eventually at an FQDN with an SOA record (and presumably also some
NS records and quite likely others records as well). For example:

    2.  A fully-qualified domain name (FQDN) within a zone affiliated (by
        some SOA record) with the administrators of the agent (who could
        then guarantee its uniqueness). For example, "server.example.org",
        even if it had no DNS record of its own, would be covered by the
        SOA record for "example.org".

>       unavailable or unless the name is of longstanding usage.

And the wording of case #3 is fine as it stands.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Apr 2007 09:39:31 +0200

As far as I can see, there is no support for your contention that we 
need to do extra work to make a path-identity mailable.

That means no support for extra text for recognizing the MX case either.

I am certainly against it.
 
>         SOA record for "example.org".
I don't see an improvement. If A runs a news server, and for some reason 
has an unlisted name in the B.com domain, by agreement with the B.com 
administrators, there is absolutely no reason why our standards should 
specify that he can't, even though the SOA records for B.com mention 
nothing about A.

It's reasonable to ask that if you ask the administrators of B.com about 
the name "AsNewsServer.B.com", they recognize the name as something 
they've allowed to be used. (I'm not sure "affiliated" means exactly 
that, but it can be stretched to that meaning, I think). But I don't see 
a reason to ask them to put that in the SOA record.

                   Harald

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 12 Apr 2007 08:31:53 -0400

> specify that he can't, even though the SOA records for B.com mention 

Charles, we already understand your points.  Did you really think rewording 
would help?

If you want a real life case to show your wording is not an improvement, 
consider what happens in a corporate merger.  The administrators of A could now 
be responsible for keeping news.B.com running, but have no control over the DNS, 
nor should they have to force all the peers to change to recognize a
renamed news.B.com.  (If you still can't see the problem, know that in the real 
word there is a difference between "administrators of the agent" and 
"administrators of that domain.")

And, (not that it matters) "who could then guarantee its uniqueness" is a 
particularly bad wording, Charles.  It doesn't mean what you intended.
"could" is a statement of possibility, not a requirement in a standard.

But don't bother correcting it.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Apr 2007 16:26:50 +0200

Harald Alvestrand wrote:

>> A fully-qualified domain name (FQDN) within a zone affiliated (by

> I don't see an improvement. If A runs a news server, and for some
> reason has an unlisted name in the B.com domain, by agreement with
> the B.com administrators, there is absolutely no reason why our
> standards should specify that he can't, even though the SOA records
> for B.com mention nothing about A.

Maybe that's not what Charles is talking about, and he simply wants
"unique within the relevant zone".  Or "below the relevant SoA", if
that's clearer.  As an example, I can't use news.xyzzy.claranet.de
just because I think it's cute.  In theory there could be a real
user "news.xyzzy" different from user "xyzzy", and in practice the
A and MX for news.xyzzy.claranet.de have nothing to do with me, it's
a wildcard.  

And it's an example why Charles' A, AAAA, or MX proposal would not 
always do what he hopes.  It would also miss RP records.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 13 Apr 2007 16:37:50 GMT

>that's clearer.

Exactly. In particular, I want some assured method whereby, if a domain
name is used in a <path-identity>, you can use the DNS to identify someone
with responsibility for it. An SOA record is probably the last resort
(usually, by chopping off components from the left, you will probably find
something more convenient before you get that far).

>  As an example, I can't use news.xyzzy.claranet.de

In theory yes, but I think you would be entitled to take a very dim view
if Claranet tried to create an A record for news.xyzzy.claranet.de without
some request from you beforehand.

>always do what he hopes.  It would also miss RP records.

What is an RP record?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 13 Apr 2007 16:22:06 GMT

>Charles, we already understand your points.  Did you really think rewording 

No, it is evident you do not understand them.

>renamed news.B.com.

In that case (I am assuming A.com is the new name of the company, but it
is too much hassle to tell all their peers to recognize news.A.com), then
the proper course of action is for A to retain ownership of the domain
B.com (with at least an SOA record in place, even if nothing else).

Otherwise, some other body could now register the name B.com, and would
then expect to be able to use news.B.com for any purpose they saw fit. My
wording would disallow that.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 13 Apr 2007 16:13:52 GMT

>That means no support for extra text for recognizing the MX case either.

The conclusion of Issue "1093 was:

The USEPRO document will not say MUST or SHOULD about any of the addresses
"abuse@identity", "usefor@identity" or "news@identity".

That is a long way from saying "The USEPRO Document will actively prevent,
or hinder, the use of addresses such as "news@identity" etc." If you
list, as allowed <path-identity>s, only those domain names which resolve to
the IP address of a host, or do not resolve to anything but might be
"affiliated" to some higher domain (i.e. the present cases #1 and #2),
then you have outlawed the possibility of using a domain name that
resolves to just an MX, and which might then have been used to try to send
email to news@identity.

I have just examined some 1571 articles in which I found 565 distinct
<path-identity>s. Of these:

73 were <path-nodot>s (though that includes some <tail-entry>s)
492 were distinct domain-names (after following all CNAME pointers)

Of these 492 domain-names

   258 resolved to an A record only
   23  resolved to an MX record only
   135 resolved to both an A and an MX
   4   resolved just to an NS (not very useful)
   57  failed to resolve, but looked like an SOA record could be found (I
       didn't check)
   15  had apparently bogus TLDs

So it seems that MX records are in fairly widespread current use within
<path-identity>s and hence it would not be proper to exclude them, which
is what the present wording does. I am not asking for "extra work to make
a path-identity mailable" - I am just asking for existing practice to be
recognized.

>specify that he can't, even though the SOA records for B.com mention 

But my wording does not "specify that he can't"; it merely requires that
the adminitrators of B.com take some responsibility for allowing A to use
their namespace.

>a reason to ask them to put that in the SOA record.

Nobody is asking them to put anything different in the SOA record (in
fact, there is no mechanism whereby that could be done). In fact, my
wording does exactly what you suggest, but it also makes it absolutely
clear that those 15 bogus TLDs are out of order.

And s/affiliated/associated/ might be clearer in cases such as the one you
mentioned.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 13 Apr 2007 21:39:17 -0700

Sorry to reply to this issue when I know that it's more important that I
reply to other open issues, but I'm doing the bit of work I had a moment
to do.  I'm hoping to find time to do the more extensive work needed on
other fronts fairly soon, since I'm almost done with post-etch Debian
work.

My continued objection to being more explicit in various directions about
the path hosts (either the proposal to be more specific about what FQDN
means or to be more restrictive or explicit about how to set up DNS
records) is three-fold:

 * It doesn't match existing practice.  In existing practice, it is common
   for the Path header to be the FQDN of the news server (which is why
   that's explicitly stated to be the preferred option in the current
   draft), but failing that, there are a wide variety of practices.  I
   think Charles's analysis supports that as well.  Discounting the bogus
   TLDs (which would not be acceptable under the new draft and I think
   rightfully so), over 11% of the <path-identity>s analyzed do not
   resolve.  I think that makes it fairly clear that requiring the Path
   identity to be a resolvable DNS entry is not existing practice.

 * Being more specific requires diving into DNS RRs to a degree that
   quickly makes me uncomfortable.  We get into A records vs. AAAA records
   vs. whatever someone comes up with later, discussion of the content of
   SOA records (I'd be hard-pressed to name any other protocol that cares
   about the contents of an SOA record outside of DNS itself), questions
   over whether MX records are okay (thereby potentially leading into
   questions about SRV records), etc.  All the proposed wording I've seen
   so far doesn't deal directly with the question of CNAMEs.  I think this
   is both complex and picky to specify and far outside the scope of the
   target audience of this specification, particularly given the third
   objection...

 * ...which is that, as pointed out by others, I'm hard-pressed to see how
   this matters enough to spend complexity and detailed specification on.
   I don't believe that it is frequently necessary to try to construct
   contact addresses from Path headers to reach intermediate sites, or
   that when it is necessary it's particularly difficult under existing
   practice (which doesn't require anything, really).  Mapping a news
   server to an organization is generally more than sufficient, and we're
   indicating a preference for putting the FQDN of the news server in the
   Path header.

I would prefer to stick with the simple language in the current draft,
which represents existing practice except for stating that you can't just
make up any random name you want, and you can't use an invalid TLD.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 14 Apr 2007 12:54:15 +0200

> What is an RP record?

"Responsible Person", RFC 1183 (2.2).  I'm puzzled by another
article in this thread about newsAexample.B.example, where
an A.example server uses for historic reasons a path identity
newsAexample.B.example

If it's not 100% clear (99.99% would be far too less) that 
A.example MUST immediately cease and desist to abuse names
below B.example as soon as B.example wishes that, and I mean
immediately, not tommorrow, then I second to add MUSTard to
the USEPRO or any other draft stating this as normative fact.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 17 Apr 2007 11:14:00 GMT

>   draft), but failing that, there are a wide variety of practices.

Yes, though we might want tp prioritize them in some way (as indeed the
present wording does to a small extent).

>   quickly makes me uncomfortable.... All the proposed wording I've seen
>   so far doesn't deal directly with the question of CNAMEs.

I tend to assume that you just follow CNAMEs and then deal with whatever
they lead you to. Some past USEPRO drafts have said that explicitly, and
it could be put back in if wanted.

> * ...I don't believe that it is frequently necessary to try to construct
>   practice (which doesn't require anything, really).

I think it needs to be done often enough that the facility needs to be
there. I agree that people familiar with the way things work can usually
figure out how to make contact with a given domain-name (and if you are
not familiar enough to do that, then you probably ought not to be trying
in the first place). RFC 2142 tried to provide a mechanism (and even has
pretensions to being a standard), but the trouble from a News POV is that
it was a bit TOO prescriptive of how Paths should look, which is why we
decided not to mention it normatively.

>make up any random name you want, and you can't use an invalid TLD.

I think the problem with the present draft is that it is too specific
about some things, and too vague about others (though I am happy with the
clear distinction between FQDNs and <path-nodots> as covered with the
wording of #3). The more you say about what IS allowed, the more you
imply that possibilities not mentioned are NOT allowed.

So either the wording needs to be tightened up (the FQDNs MUST/SHOULD/MAY
resolve, in defined ways, to various desirable entities - hosts, servers,
administrators, responsible persons, whatever);

or else it needs to be loosened (it must be possible, by some means not
specified in detail, to derive pointers to various desirable entities -
hosts, servers, administrators, responsible persons, whatever).

I think we are agreed that what we do NOT want is some jumbled collection
of stuff that just happens for fit the syntax of a domain-name (like those
15 bogus tlds, for example).

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 18 Apr 2007 11:54:38 +0200

I'm closing this item as "no change needed".

Apart from Charles, there seems to be nobody asking for a change, and 
several people have said that they are OK with the current wording.

                 Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 20 Apr 2007 13:09:50 GMT

>several people have said that they are OK with the current wording.

On the contrary, Russ has agreed, more or less, with the list of existing
practices thst we need to accomodate, but clearly the present wording does
not allow all of them (in particular, it seems not to allow MX records in
any shape or form).

Moreover, Russ also agrees that mention needs to be made that will exclude
bogus TLDs.

I suggest we give Russ tiem to come back on some of these points.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 20 Apr 2007 10:09:09 -0700

Charles Lindsey <[email-masked]> writes:

> On the contrary, Russ has agreed, more or less, with the list of
> existing practices thst we need to accomodate, but clearly the present
> wording does not allow all of them (in particular, it seems not to allow
> MX records in any shape or form).

Sure it does.  Point 2 allows any DNS record or none at all.

> Moreover, Russ also agrees that mention needs to be made that will
> exclude bogus TLDs.

> I suggest we give Russ tiem to come back on some of these points.

I think the current wording is fine and already excludes bogus TLDs.  No
change required is my preferred resolution.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 23 Apr 2007 12:21:27 GMT

>Sure it does.  Point 2 allows any DNS record or none at all.

We seem to have reached the point now where it is agreed by the WG that we
want to allow various things (including MX records and also things that do
not resolve at all in the DNS, even though a 'stub' does resolve, but
excluding things that are totally unrelated to the DNS, such as bogus
TLDs). The question now is whether the present wording is the best way to
describe what we want to allow.

And if you say that Point 2 allows "any DNS record or none at all", then
what is the purpose of Point 1? Remember that we are trying to give some
rough "decreasing order of preference".

Essentially, we want the <path-identity>s that are used to be "helpful" to
both software and humans that have occasion to use them. Suppose we award
marks for "helpfulness" (note, I am not suggesting we write the document
in these terms).

In the following, "bogus" means a component that fails to resolve,
"example" means a component that resolves to an IP or MX, or even an SOA,
possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk" etc.

example.example.com yields the IP of the relaying host - score 60 marks.
example.example.com yields a useful MX                 - score 40 marks
   (i.e. it works with some suitable RFC 2142 identity
   such as news@/postmaster@/whatever)
bogus.example.com where example.com yields a useful MX - score 20 marks
bogus.example.com where example.com yields just an SOA - score 10 marks
bogus.bogus.com                                        - score  0 marks
bogus.bogus                                            - score  0 marks
a <path-nodot>                                         - score 15 marks

So an ideal site could score 100 marks;
60 marks and even 40 marks could be normal and acceptable;
But below 40 is getting a bit dodgy, though allowable;
And zero is quite unacceptable.

So it those marks reflect our gut feeling of what we want to see, then the
question is what wording would best convey that gut feeling (though not
with such a fine-grained level of detail)?

My concern is that the present wording gets no way near it. We should be
able to do much better.

>I think the current wording is fine and already excludes bogus TLDs.

Only in a very half-hearted sort of way.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 23 Apr 2007 10:51:43 -0700

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

> We seem to have reached the point now where it is agreed by the WG that
> we want to allow various things (including MX records and also things
> that do not resolve at all in the DNS, even though a 'stub' does
> resolve, but excluding things that are totally unrelated to the DNS,
> such as bogus TLDs). The question now is whether the present wording is
> the best way to describe what we want to allow.

> rough "decreasing order of preference".

Point 1 says "use the actual name of your system in the Path."  I think
that's pretty clearly the best option and the one that provides the
maximum amount of useful trace information.  Does anyone really disagree
with that?

> "example" means a component that resolves to an IP or MX, or even an
> SOA, possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk"
> etc.

>    such as news@/postmaster@/whatever)

I think the main place we disagree is over the usefulness of an MX record.
If I have the FQDN of the host, I can figure out somewhere reasonable to
mail.  An MX may save me a small amount of time, but usually it's pretty
obvious.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 24 Apr 2007 12:13:56 +0200

> a <path-nodot>                                         - score 15 marks

s/15/5/

> Only in a very half-hearted sort of way.

We can't have a DNS tutorial in the NetNews protocol spec.  Folks
interested in the merits of MX or DDDS or RP and so on need to
look elsewhere.  And I hope they don't find 2142 as it is today,
for cases when they're interested in something that's not abuse@.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 24 Apr 2007 13:26:36 +0200

Charles,

which part of RESOLVED didn't you understand?

> bogus.bogus.com                                        - score  0 marks
This is where you get confused.
bogus.bogus.com WILL yield a SOA - the SOA of .com.

So you cannot programmatically tell the difference between 
"bogus.bogus.com" and "bogus.example.com" without giving special 
treatment to ".com".

One example of such a situation is where "bogus.com" is registered with 
Verisign, but no DNS service has been established yet. (Verisign allows 
that; others, such as .no, don't).

The current text covers that situation.
There has been no support for changing it.

Unless you have NEW TECHNICAL ARGUMENTS - which means something 
DIFFERENT from "I like" or "I think the group should like", your harping 
on the issue is OUT OF ORDER.

                      Harald

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 24 Apr 2007 13:42:05 +0200

> bogus.bogus.com WILL yield a SOA - the SOA of .com.

`nslookup -q=soa bogus.bogus.com` results in an error
with my version of nslookup, it gives up for NXDOMAIN.

> NEW TECHNICAL ARGUMENTS

Just an off topic technical observation, the question
of "zone cuts" is quite interesting, but admittedlly
not here.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 26 Apr 2007 07:13:24 +0200

> with my version of nslookup, it gives up for NXDOMAIN.
I was talking about Charles' tree-climbing exercise; if you cut off 
labels until you find something, you will eventually look up ".com".

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 27 Apr 2007 19:26:00 GMT

>maximum amount of useful trace information.  Does anyone really disagree

I think the WG previously took the view that the actual name of the system
and an MX to reach its admins were equally suitable. But if the WG now
wants to say that the actual address is Point 1 and an MX is Point 2, then
I would not argue too hard against it. Actually, the really REALLY best
practice is to provide both an A/AAAA _and_ an MX, and that might be worth
pointing out

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 27 Apr 2007 19:35:14 GMT

>s/15/5/

:-)

>We can't have a DNS tutorial in the NetNews protocol spec.

Sure. We can use wording which indicates how the <path-identity> is to be
interpreted without going into DNS technicalities. "The domain in the
<path-identity> MUST/SHOULD/MAY be chosen so that it is possible to
identify the host-concerned/the admine-concerned/whatever-else ...".

>  And I hope they don't find 2142 as it is today,

I think we have made a deliberate choice not to _endorse_ 2142, but that
is not to say that it is wrong to follow it (though not at the level of
detail that it tries to insist on). USEAGE could try to pick up the
pieces.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 27 Apr 2007 19:45:15 GMT

>which part of RESOLVED didn't you understand?

We may have resolved what we are going to say, but not necessarily how we
are going to say it.

For example, I find the text that you yourself wrote when you first
proposed the idea that names which did not immediately resolve in the DNS
should be allowed (and which can still be found as '2nd alternative' in
Usepro-06) is superior to the present text.

>bogus.bogus.com WILL yield a SOA - the SOA of .com.

Indeed, which is why simply looking for SOA is not enough. For sure we do
not want to allow bogus.bogus.com.

Interestingly, the DKIM WG has been looking at this, and to do it properly
you really need some widely publicised and maintained list of TLDs/zones.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 27 Apr 2007 21:19:40 -0700

>> maximum amount of useful trace information.  Does anyone really
>> disagree with that?

> I think the WG previously took the view that the actual name of the
> system and an MX to reach its admins were equally suitable. But if the
> WG now wants to say that the actual address is Point 1 and an MX is
> Point 2, then I would not argue too hard against it. Actually, the
> really REALLY best practice is to provide both an A/AAAA _and_ an MX,
> and that might be worth pointing out

It's a minor point, and somewhat off-topic, but I feel obligated to point
out whenever it seems appropriate that hosts running SMTP daemons with A
records do not need MX records.  A remarkable number of people (which I
expect does *not* include you -- this was just a rant trigger) seem to be
confused about this these days and write stupid spam filtering software
under the assumption that A records are not sufficient for delivering
e-mail.