Subject: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Dec 2015 10:09:06 -0500 (EST)

Hi,

Section 6.2 of 4034 talks about canonicalization of the RR Form

Item 3 states:

3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
        HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
        SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
        the DNS names contained within the RDATA are replaced by the
        corresponding lowercase US-ASCII letters;

My questions:

a) What was the purpose of listening these and not all RRtypes?
    (It seems perhaps it wanted to say "All except A/AAAA")
b) What should be done with new RRtypes like OPENPGPKEY or SMIMA?
c) Why the hell - hardcoded lists and not IANA registry?
d) Does this need updating or an errata?

Paul

---

From: P Vixie <[email-masked]>
Date: Tue, 08 Dec 2015 15:17:34 +0000

Existing signers and validators won't know the internal format of future rr types.

On December 8, 2015 10:09:06 AM EST, Paul Wouters <[email-masked]> wrote:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 8 Dec 2015 10:18:06 -0500

The reasoning is in https://tools.ietf.org/html/rfc3597

>    (It seems perhaps it wanted to say "All except A/AAAA")
All these types contain "domain names" as a field, and name compression is
allowed in the RDATA.
After the publication of RFC3597 no name compression is allowed in new
types.

> c) Why the hell - hardcoded lists and not IANA registry?

Finite list as 3597 outlawed name-compression in new types

> d) Does this need updating or an errata?
HINFO and TXT is a mistake and there is errata on that
https://www.rfc-editor.org/errata_search.php?rfc=3597

Olafur

---

From: "Roy Arends" <[email-masked]>
Date: Tue, 08 Dec 2015 15:33:16 +0000

>  (It seems perhaps it wanted to say "All except A/AAAA")

These specific RR types contain a DNS name in the RDATA. Up until 
RFC3597 they might have been subject to name compression.

> b) What should be done with new RRtypes like OPENPGPKEY or SMIMA?

Nothing.

> c) Why the hell - hardcoded lists and not IANA registry?

Calm down. This is a complete set. Not to be expanded, ever. Exceptions 
to the RFC3597 rules (where the list originates) because they predate 
it.

> d) Does this need updating or an errata?

Not that I know.

Roy

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 8 Dec 2015 14:39:11 -0500

> d) Does this need updating or an errata?

It was already updated, in RFC 6840 §5.1.

-- 
Robert Edmonds

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Dec 2015 14:41:10 -0500 (EST)

> Subject: Re: [DNSOP] Question on RRtypes in RFC 4034 Section 6.2

Thanks everyone for the useful comments. It's all clear to me now.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Dec 2015 07:37:36 +1100

In message <[email-masked]>, Paul Wouters wr
> Thanks everyone for the useful comments. It's all clear to me now.

Additionally if we ever wanted to enable compression for new types
we could use EDNS to signal that the client understands a expand
set of types and one could use case sensitive compression to preserve
the original case of the name in the rdata which would allow DNSSEC
to work to work on the expanded names without having to update every
client in the world first.

e.g.
	EDNS(1) could indicate the client understands the rdata
	for all the types allocated as of 12:00 Dec 8, 2016.

	EDNS(2) could indicate the client understands the rdata
        for all the types allocated as of 12:00 Dec 8, 2020.

We all should be doing case sensitive compression already as that
really is part and parcel of preserving the original case as required
by RFC 103[45].

I'm actually tempted to say we should do this just to get rid of
the stupid firewalls that think that it is a good idea to drop EDNS
!= EDNS(0) requests.

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

---

From: 🔒Roy Arends <[email-masked]>
Date: Wed, 9 Dec 2015 07:31:02 +0000

We'd end up adding stuff to a response in order to make it shorter. 

Is there a clear benefit (shorter responses)? Can you show me a few real world examples?

Thanks

Roy

> On 8 Dec 2015, at 20:37, Mark Andrews <[email-masked]> wrote:
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Dec 2015 21:50:49 +1100

> We'd end up adding stuff to a response in order to make it shorter.

We'd end up changing a 0x00 to a 0x01 in the OPT record.

> Is there a clear benefit (shorter responses)? Can you show me a few real

Every DNSSEC answer would be potentially shorter.  The signer field
can be compressed as can the domain names in all these types.

hip ipseckey key lp nsec nxt rrsig sig talink nsap-ptr
dnskey cdnskey

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 9 Dec 2015 15:27:31 -0500

> hip ipseckey key lp nsec nxt rrsig sig talink nsap-ptr

DNSSEC signer name fields are going to be fairly small for typical
domains (barring outliers under .ip6.arpa).  Isn't this a pretty trivial
savings compared to the size of 1024 or 2048 bit RSA signatures?

E.g., the response to "dig +norec +dnssec @sfba.sns-pb.isc.org
www.isc.org -t A" returns a 1623 byte response (for me) containing 8
RRSIGs, and replacing the uncompressed instances of "isc.org" (9 bytes)
in each RRSIG signer field with a two byte compression pointer saves
(8*9 - 8*2) = 56 bytes.  So that saves you ~3.5% off a 1.6 KB response.
Why bother?  You will get a far larger savings by just turning on
minimal-responses and replacing RSA with ECDSA, no code changes required
:-)

-- 
Robert Edmonds