Subject: [dbound] draft-brotman-rdbd

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 09 May 2019 15:22:37 +0100

Hi.

At Stephen Farrell's suggestion, and after an inexcusable delay, I've 
taken a look at this draft.

My first reaction is that the PTR record (RFC1035, 1987) seems to fit 
the intended use case.

/Niall

---

From: "John Levine" <[email-masked]>
Date: 9 May 2019 12:42:40 -0400

>My first reaction is that the PTR record (RFC1035, 1987) seems to fit 

For over 30 years the only place anyone has used PTR records has been
in the rDNS trees under in-addr.arpa and ip6.arpa.  I think that if
you try to use them anywhere else, you'll find way too much software
that has baked in assumptions that they don't belong there.

Note that RFC 1035 says they "are used in special domains".

R's,
John

---

From: Peter Koch <[email-masked]>
Date: Thu, 9 May 2019 18:51:07 +0200

> in the rDNS trees under in-addr.arpa and ip6.arpa.  I think that if

kinda close: RFC 1101 was published in April 1989.

-Peter

---

From: "John Levine" <[email-masked]>
Date: 9 May 2019 13:10:09 -0400

>kinda close: RFC 1101 was published in April 1989.

I know, but I've never seen anyone use the network number PTRs it
proposes.  This is definitely a practical concern, not one of whether
you could publish the bits.

It wouldn't work now anyway since it depends on classful addressing to
guess how many bits are in the network number.

R's,
John

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 09 May 2019 20:06:02 +0100

On 9 May 2019, at 17:42, John Levine wrote:

> in the rDNS trees under in-addr.arpa and ip6.arpa.

Catalog zones are much more recent, and specifically use PTR records.
I'm aware that support for these is a BIND-specific feature,
and utterly unaware of how much it's being used.

> I think that if

I'm not sure what kind of software might have such assumptions
baked in.  The very small sample that my provisioning chain includes
(Emacs, dnssec-signzone, nsd, unbound, zonemaster) shows no problem
of this kind.

One significant counterexample is enough, of course.

I have a strong suspicion that any provisioning chain needing
modification to accommodate innovative uses of PTR would also need
work to add support for the new RRtypes proposed in the draft, and
that the effort involved in either case might be roughly commensurate.

> Note that RFC 1035 says they "are used in special domains".

A domain that has a special relationship with another domain is
arguably "special".  IIUC, advertising such a relationship is the
purpose of the new RRtypes proposed in the draft.

I'm still coloured "unconvinced".

/Niall

---

From: "John Levine" <[email-masked]>
Date: 9 May 2019 15:42:30 -0400

>(Emacs, dnssec-signzone, nsd, unbound, zonemaster) shows no problem

The usual problem is middleboxes.

>that the effort involved in either case might be roughly commensurate.

Commensurate but different.  Adding new rrtypes is a well known misery
with the problem being primarily in the provisioning crudware that
people use to manage their zones.  Finding unhelpful middleboxes is a
more distributed problem.

---

From: Grant Taylor <[email-masked]>
Date: Thu, 9 May 2019 15:22:59 -0600

> in the rDNS trees under in-addr.arpa and ip6.arpa.

I've seen PTRs used outside of in-addr.arpa and ip6.arpa.  Particularly 
with RFC 2317 Classless IN-ADDR.ARPA delegation with CNAMEs pointing to 
names outside of in-addr.arpa / ip6.arpa.  Even RFC 2317 has examples 
reconstructing the in-addr sub-domain structure in other domains in § 5.2.

> I think that if you try to use them anywhere else, you'll find way too 
> much software that has baked in assumptions that they don't belong there.

I've not suffered through that misfortune myself.

I seem to recall an intriguing use of PTR records for other information. 
  I think it had to do with translating service names to the host 
running said service name without actually altering resolution like a 
CNAME would.

smtp.example.net.   IN   A     192.0.2.34
smtp.example.net.   IN   PTR   host.example.net.
host.example.net.   IN   A     198.51.100.69

-- 
Grant. . . .
unix || die