Subject: [DNSOP] Name decompression strictness

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 9 Jan 2016 11:26:16 +0530

Hi all

RFC3597 says this:

> Receiving servers MUST decompress domain names in RRs of well-known
> type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
> NXT, NAPTR, and SRV (although the current specification of the SRV RR
> in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
> servers following that earlier specification are still in use).
>
> Future specifications for new RR types that contain domain names
> within their RDATA MUST NOT allow the use of name compression for
> those names, and SHOULD explicitly state that the embedded domain
> names MUST NOT be compressed.

If a DNS message is received on the wire, that has a compressed name in
some RR's RDATA which it should not have (going by its type), is it fair
to still accept it as a valid message and process it if the
implementation is able to do so? i.e., can Postel's law be followed
here, or must the implementation strictly reject such messages?

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Jan 2016 22:28:22 -0800

> here, or must the implementation strictly reject such messages?

i followed postel's law with regard to receipt of compressed names anywhere in any RDATA that i knew the format of, in both BIND4 and BIND8. the result was that implementations who wrongly compressed non-well-known RDATA's (including BIND4 and BIND8) were able to break that rule without pain.

it's my strongly held belief that postel's law is wrong for RDATA interpretation, and that the first implementation to compress something they should not have compressed, should feel pain.

-- 
P. Vixie

---

From: Robert Edmonds <[email-masked]>
Date: Sat, 9 Jan 2016 01:38:59 -0500

> it's my strongly held belief that postel's law is wrong for RDATA interpretation, and that the first implementation to compress something they should not have compressed, should feel pain.

There is an analogous case with compression pointers themselves, which
1035 requires point to a "prior occurance [sic] of the same name".  But
BIND allowed pointers to point to later occurrences, and later
implementations had to make the same allowance for compatibility
reasons.

-- 
Robert Edmonds

---

From: Andreas Gustafsson <[email-masked]>
Date: Sat, 9 Jan 2016 13:34:00 +0200

Paul Vixie wrote:
> i followed postel's law with regard to receipt of compressed names
> anywhere in any RDATA that i knew the format of, in both BIND4 and
> BIND8. the result was that implementations who wrongly compressed
> non-well-known RDATA's (including BIND4 and BIND8) were able to
> break that rule without pain.
> 
> it's my strongly held belief that postel's law is wrong for RDATA
> interpretation, and that the first implementation to compress
> something they should not have compressed, should feel pain.

That would be good, yes, and it is allowed by 3597, but not required.
-- 
Andreas Gustafsson, [email-masked]

---

From: Andreas Gustafsson <[email-masked]>
Date: Sat, 9 Jan 2016 13:55:00 +0200

> implementations had to make the same allowance for compatibility

Maybe such allowances had to be made at one point, but they are not
needed today.  BIND 9 has been rejecting compression pointers to
"later occurrences" for 15 years now, so any implementation sending
them has surely been weeded out by now.
-- 
Andreas Gustafsson, [email-masked]