Subject: XPTR Drafts

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 29 Jun 2007 11:40:40 -0700

As previously proposed on this list and elsewhere, the attached is a proposal for XPTR, a pointer record which allows for wildcard processing to be defined for prefix records.

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 02 Jul 2007 10:58:46 +0100

On 29 Jun 2007, at 19:40, Hallam-Baker, Phillip wrote:
> the attached is a proposal for XPTR

	in which:

>    If this search fails the requestor looks for a PREPTR record at the
>    query node and if this is found:

	s/PRE/X/ or am I missing comething?

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 05:45:12 -0700

Yes, changed the name, did not fully do the substitution it appears. 

> -----Original Message-----
> From: Niall O'Reilly [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 5:59 AM
> To: Hallam-Baker, Phillip
> Cc: Niall O'Reilly; [email-masked]
> Subject: Re: XPTR Drafts
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Jul 2007 15:26:34 +0200

* Phillip Hallam-Baker:

>    Record BasicPrefixResolve (
>                      String node, String prefix, RecordType  record)
>       1.   Record F1 =  Lookup (prefix + "." + node, record)

Nit: You don't want string concatenation, but domain name
concatenation.

>          If  (F1 <> NIL) Return F1

You should explicitly address error code and no data behavior, instead
of just looking at the data section.  The resolution algorithm should
only proceed if there is an RCODE=0, no data response.  You should
also reference the wildcard-clarify RFC (sorry, forgot its number),
which is said to specify that the query does not return NXDOMAIN when
there is the XPTR record there which is queried below.

>       2.   Record F2 = Lookup (node, PREPTR)
>          If (F2 = NIL) Return NIL

The error code should be passed on to the application.

>       3.   Record F3 = Lookup (prefix + "." + F2.domain)
>          Return F3

>    In such situations the service discovery process MAY specify the use
>    of the Reverse DNS.  The reverse DNS is an area of the DNS space (in-
>    addr.arpa, ipv6.arpa).  A PTR record in the reverse DNS maps an IPv4

I think it's ip6.arpa.  And your proposal might also apply to
e164.arpa in some way, so this whole section should probably be
generalized.

>    Depending on the requirements of the service it MAY be desirable for
>    discovery to process XPTR records in the reverse DNS directly or to
>    first attempt to follow a PTR record to obtain a DNS node where basic
>    prefix resolution is to be performed.

Hmm, hmm.  Is this really necessary?  It's less clear to me what
should happen if the reversed DNS name already has got a NAPTR or SRV
entry.

The document should specifiy that the LHS of XPTR MUST NOT be subject
to label compression.  Name servers SHOULD NOT perform additional
section processing, and resolvers and applications MUST NOT rely on
it.

Apart from that, I like your approach better than the dynamic record
type extension I described some time ago.  It seems to address a
similar set of issues, and the XPTR records are much easier to write
down and maintain manually.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 5 Jul 2007 11:56:11 -0700

Thank you very much for the comments. I will attempt to get another draft in before the cutoff but I am having much trouble at the moment with windows...

..as in the glazing kind. Having to repair an antique bay window that has suffered from not having had new putty for a century or so. 

> From: Florian Weimer [mailto:[email-masked]] 
> Sent: Thursday, July 05, 2007 9:27 AM
> Cc: [email-masked]
> Subject: Re: XPTR Drafts
> 
> * Phillip Hallam-Baker:
> 
> You should explicitly address error code and no data 
> behavior, instead of just looking at the data section.  The 
> resolution algorithm should only proceed if there is an 
> RCODE=0, no data response.  You should also reference the 
> wildcard-clarify RFC (sorry, forgot its number), which is 
> said to specify that the query does not return NXDOMAIN when 
> e164.arpa in some way, so this whole section should probably 
> be generalized.
> 
> Hmm, hmm.  Is this really necessary?  It's less clear to me 
> what should happen if the reversed DNS name already has got a 
> NAPTR or SRV entry.
> 
> 
> The document should specifiy that the LHS of XPTR MUST NOT be 
> subject to label compression.  Name servers SHOULD NOT 
> perform additional section processing, and resolvers and 
> applications MUST NOT rely on it.
> 
> 
> Apart from that, I like your approach better than the dynamic 
> record type extension I described some time ago.  It seems to 
> address a similar set of issues, and the XPTR records are 
> much easier to write down and maintain manually.
>