Subject: [spfbis] draft-ietf-spfbis-4408bis-20 review

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Sep 2013 14:39:40 -0700

Dear SPFbis WG,

The section on DNS Lookup Limits is much better.  Well done.

However a few errors remain.  I will attempt to explain this in a friendly way.  Any failure in this regard is not intentional.

The last paragraph in 3.4.  Record Size:
,---
Note that when computing the sizes for replies to queries of the TXT
format, one has to take into account any other TXT records published
at the domain name. Similarly, the sizes for replies to all queries
related to SPF have to be evaluated to fit in a single 512 octet UDP
packet (i.e. DNS message size limited to 450 octects).
'--

It is wrong to refer to limiting the UDP packet to 512 octets.  There has never been a 512 octet packet MTU limitation.  As I understand the issue, this is to avoid CPE enforcement of DNS Message size.  This limit predates IPv6 which changed the minimum MTU from 576 to 1280 octets.  EDNS0 makes the limit explicit at 1280 octets or more.  Please remove the term 512 octet UDP packet.  The evaluation should be to ensure the generated response fits within a 512 octet DNS message and perhaps recommend that this should be less than 450 octets (note the misspelling of octets).  Is this additional reduction to ensure 567 octet MTU compliance with IPv6 headers (which seems unlikely necessary) or is this to handle unexpected additional information included in a DNS response?  Either way, there has never been a 512 octet packet size constraint.

It would also be better to ensure the recent change to "void" response gets noticed.  The last paragraph of section
5. Mechanism Definitions should make a reference to the last paragraph in 4.6.4. DNS Lookup Limits.

It is unfortunate there is still no mention of a macro's ability to modulate what might be queried based upon message content rather than information from DNS which greatly impacts network amplification assessments.  Since SPF uses neither a dedicated resource record type or a standardized naming convention, mitigation efforts within DNS operations are less assured.  

If there is any interchange concern, some effort should be made to determine whether SPF records containing macros suffer from similar interchange issues as those related to SPF RR types.  The extremely infrequent use of macros should suggest an underlying reason.  I am not free to make any specific disclosures.  Since this issue will impact interchange, it seems this should be reviewed to benefit those deploying SPF.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Fri, 13 Sep 2013 15:36:01 -0700

Hi Scott,
At 14:39 13-09-2013, Douglas Otis wrote:
>It is wrong to refer to limiting the UDP packet to 512 
>octets.  There has never been a 512 octet packet MTU limitation.  As 
>I understand the issue, this is to avoid CPE enforcement of DNS 
>Message size.  This limit predates IPv6 which changed the minimum 
>MTU from 576 to 1280 octets.  EDNS0 makes the limit explicit at 1280 
>octets or more.  Please remove the term 512 octet UDP packet.  The 
>evaluation should be to ensure the generated response fits within a 
>512 octet DNS message and perhaps recommend that this should be less 
>than 450 octets (note the misspelling of octets).  Is this 
>additional reduction to ensure 567 octet MTU compliance with IPv6 
>headers (which seems unlikely necessary) or is this to handle 
>unexpected additional information included in a DNS 
>response?  Either way, there has never been a 512 octet packet size constraint.

As a note to Doug, I am responding to the above only.  Please note 
that I am not ignoring the other comments.

In my opinion this proposed change is about an editorial issue.  The 
issue is about the term "UDP packet" as used in the first and second 
paragraphs of Section 3.4 of draft-ietf-spfbis-4408bis-20.

Could you please propose text to address this?

Thanks,
S. Moonesamy (as document shepherd)

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Sep 2013 16:30:42 -0700

On Sep 13, 2013, at 3:36 PM, S Moonesamy <[email-masked]> wrote:

> As a note to Doug, I am responding to the above only.  Please note that I am not ignoring the other comments.
> 
> In my opinion this proposed change is about an editorial issue.  The issue is about the term "UDP packet" as used in the first and second paragraphs of Section 3.4 of draft-ietf-spfbis-4408bis-20.
Dear SM, 

Season to taste. ;^)

Was:
,---
'---

Change to:
,---
Note that when computing the sizes for replies to queries of the TXT
format, one has to take into account any other TXT records published
at the domain name.  Similarly, the sizes for replies to all queries
related to SPF have to be evaluated to fit in a 512 octet DNS 
Message.  Limiting responses to less than a 450 octet DNS Message
may accommodate additional information added automatically.
'---

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Fri, 13 Sep 2013 17:01:24 -0700

Hi Doug,
>Season to taste. ;^)

:-)

>may accommodate additional information added automatically.

The above looks okay to me.  The last sentence could be dropped.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Sep 2013 20:12:04 -0400

> may accommodate additional information added automatically.

I must have missed it before, given the changes that are flying fast
and furious, but where in the world did 450 octets come from?  That's
not a "DNS magic number" anywhere of which I am aware.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Sep 2013 17:34:41 -0700

Dear Andrew,

I did not recommend this value, but I did say it sounded like reasonable advice.   I have been burnt a number of times by "helpful" DNS servers that decide to add some additional information.   I also wondered if this was about a IPv6 related issue, which may require a reduction of 40 for the IP header assuming a goal was to retain a 576 octet MTU.  But this does not sound reasonable either. 

Regard,
Douglas Otis

On Sep 13, 2013, at 5:12 PM, Andrew Sullivan <[email-masked]> wrote:

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Sep 2013 23:32:05 -0400

> not a "DNS magic number" anywhere of which I am aware.

It's from RFC 4408:

   3.1.4. Record Size

   The published SPF record for a given domain name SHOULD remain small
   enough that the results of a query for it will fit within 512 octets.
   This will keep even older DNS implementations from falling over to
   TCP.  Since the answer size is dependent on many things outside the
   scope of this document, it is only possible to give this guideline:
   If the combined length of the DNS name and the text of all the
   records of a given type (TXT or SPF) is under 450 characters, then
   DNS answers should fit in UDP packets.  Note that when computing the
   sizes for queries of the TXT format, one must take into account any
   other TXT records published at the domain name.  Records that are too
   long to fit in a single UDP packet MAY be silently ignored by SPF
   clients.

It's meant to provide record publishers with a rule of thumb to use on how 
large an SPF record can be without risk of needing EDNS0 or TCP.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Sep 2013 00:25:23 -0400

On Friday, September 13, 2013 17:01:24 S Moonesamy wrote:
> :

No.

The point is you can't use the entire 512 [insert term here] for the SPF 
record due to potentially other TXT records and DNS message overhead.  The 450 
number is a rule of thumb that was developed to provide a ~safe SPF record 
size in the absence of other TXT records.  The propose language uses the term 
"DNS message" both for the UDP packet size and for the part of that packet 
that can be used for an SPF record.

I strongly object to dropping the 450 recommendation based on no data that 
says it's bad (it is in RFC 4408 and no case to remove it has been 
recommended).

All the rambling about IPv6, EDNS0, etc is irrelevant.  The point is to keep 
the record small enough to make it reliable.

Even if there was a point in the the change, the language is definitely a 
regression from what was there before because it uses the same term for two 
different things.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 13 Sep 2013 23:01:37 -0700

Hi Scott,
>regression from what was there before because it uses the same term for two

There is a message of Joe Abley at 
http://www.ietf.org/mail-archive/web/ietf/current/msg81862.html  Joe 
was correct in saying that my usage of "UDP message" is incorrect.

I did not suggest dropping the "450 recommendation".  The text 
suggested by Douglas Otis was for the second paragraph of Section 
3.4.  This is not related to IPv6 or EDNS0.

The language that was there before is incorrect (see message from Joe Abley).

Could you please propose text to address the terminology issue in Section 3.4?

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Sep 2013 02:20:39 -0400

On Friday, September 13, 2013 23:01:37 S Moonesamy wrote:
> >size in the absence of other TXT records.  The propose language uses the
> >term "DNS message" both for the UDP packet size and for the part of that
> >packet that can be used for an SPF record.
> >
> >All the rambling about IPv6, EDNS0, etc is irrelevant.  The point is to
> >keep the record small enough to make it reliable.
> >

OK.

OLD:

3.4.  Record Size

   The published SPF record for a given domain name SHOULD remain small
   enough that the results of a query for it will fit within 512 octets.
   This UDP limit is defined in [RFC1035] section 2.3.4, although it was
   raised by [RFC2671].  Staying below 512 octets ought to prevent older
   DNS implementations from failing over to TCP,and will work with UDP
   in the absence of EDNS0 [RFC6891] support.  Since the answer size is
   dependent on many things outside the scope of this document, it is
   only possible to give this guideline: If the size of the DNS message,
   the combined length of the DNS name and the text of all the records
   of a given type is under 450 octets, then DNS answers ought to fit in
   UDP packets.  Records that are too long to fit in a single UDP packet
   could be silently ignored by SPF verifiers due to firewall and other
   issues that interfere with the operation of DNS over TCP or using
   ENDS0.

NEW:

3.4.  Record Size

   TXT records is under 450 characters, then DNS answers should fit in UDP
   packets.

   Note that when computing the sizes for queries of the TXT format, one must
   take into account any other TXT records published at the domain name. 
   Records that are too long to fit in a single UDP packet MAY be silently
   ignored by SPF clients.

Note: The proposed "NEW" text is largely a reversion to what was in RFC 4408.  
I think it's shorter, clearer, and resolves the question at hand.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sat, 14 Sep 2013 00:18:42 -0700

Hi Scott,
>I think it's shorter, clearer, and resolves the question at hand.

My recollection of the working group discussion about the RFC 4408 
text is that the usage of "characters" in the text is 
incorrect.  There was also a discussion (if I recall correctly) about 
RFC 2119 key words which led to the "MAY" being dropped.  The 
discussion which led to EDNS0 being included is related to issue #24.

The reversion might be a substantive change.  I would prefer to avoid 
that as it can raise process questions.  The issue is about the 
incorrect usage of technical terms.  I suggest addressing that 
instead of having a substantive change.  What I have taken into 
consideration is not to revisit issues which have been resolved and 
not to open the way for new issues at this stage when it is likely 
that the work is nearly complete.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 15 Sep 2013 17:36:04 -0400

No hat.

On Fri, Sep 13, 2013 at 05:34:41PM -0700, Douglas Otis wrote:
> 
> I did not recommend this value, but I did say it sounded like reasonable advice. 

There is exactly one historic built-in limit to the DNS for UDP
packets, and that is 512 octets.  Lots of middleboxes drop UDP packets
on port 53 larger than 512 octets.  Many equipment manufacturers have
shipped equipment that, by default, drops packets over 512 octets on
port 53.  The 512 octets does not apply to TCP.  If it did, zone
transfers would be impossible.

Everything else -- all the noise about MTUs and so on -- is rank
speculation.  There's _all kinds_ of breakage out there with large MTU
sizes.  Heck, some of the CGNs appear to end up with real MTUs across
the network way below any threshold we're discussing.  But this
document should not be a general purpose document about all the
possible ways this protocol could interact with everything else
everywhere on the Internet.  This is a protocol document.

As I have said several times, if someone wants to write an operational
guidance document, I have no objection.  But the protocol document
shouldn't be providing that, at least in detail.  It is arguably
already too heavy in that direction.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 15 Sep 2013 17:38:20 -0400

>    TXT records is under 450 characters, then DNS answers should fit in UDP

s/characters/octets, or even "ASCII characters" if you must.
"Characters" in the UTF-8 era is just too loaded a word.

Otherwise, no objection here.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Sep 2013 09:33:51 -0700

On Sep 15, 2013, at 2:36 PM, Andrew Sullivan <[email-masked]> wrote:

> packets, and that is 512 octets.

Dear Andrew,

You have made the same mistake made in SPFbis.  There has never been a UDP limit imposed by DNS.  There is however a DNS Message limit imposed at 512 octets.  In addition to the DNS Message, is the UDP and IP header.  The size of the IP and UDP header depends upon IP version. 

>  Lots of middleboxes drop UDP packets
> on port 53 larger than 512 octets.

They are likely dropping DNS Messages larger than 512 octets.  They might be dropping packets larger than 576 octets, but that seems unlikely. 

> Many equipment manufacturers have

This would be a correct statement only in regard to that of the DNS Message size.

> everywhere on the Internet.  This is a protocol document.

The MTU size MUST be increased to support DNSSEC.  IPv6 also changes the minimum MTU.  Since SPFbis does not have purview over whether IPv6 or DNSSEC is used, these environments MUST be considered with SPFbis's incredibly complex macro expanded protocol able to emit hundreds of UDP packet into DNS all on behalf of unknown entities where targets can be modulated by message elements rather than DNS content.   What might seem like a subtle difference can lead to significant increase in network amplification.

> already too heavy in that direction.

What type of operational guide? There is no operational defense able to mitigate SPFbis macro use that I am aware of except for email providers ignoring SPF records containing macros.  What did you have in mind? 

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 26 Sep 2013 00:07:50 -0400

> Otherwise, no objection here.

It looks like I had fixed this already.  It says octets.

Scott K