spf ent txt records.

[hugo hugoo]

Dear all,
 
I received the following question and I am not able to aswer as spf records are 
still mysterious to me.
We are using BIND 9.7.
 
Thanks in advance for your answers,
 
Hugo,
 
 
 
Does our DNS-server support SPF-type records? Or do we put SPF-info in a 
TXT-record?
 
Ref. : 
Early implementations used TXT records for implementation before the new record 
type was commonly available in DNS software. Use of TXT records for SPF was 
intended as a transitional mechanism. However, according to the current RFC, 
RFC 4408, section 3.1.1, "An SPF-compliant domain name SHOULD have SPF records 
of both RR types. A compliant domain name MUST have a record of at least one 
type," and as such, TXT record use is not deprecated.[2]
  ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Leonardo Santagostini]

Hello Hugo,

You can try looking at your zone files for SPF records and/or TXT
containing spf stuff.

You con implement SPF records as you wish.

Maybe you can take a look at: http://www.zytrax.com/books/dns/ch9/spf.html

Saludos / Regards
Leonardo Santagostini







2013/3/13 hugo hugoo 

> Dear all,
>
>
>
> I received the following question and I am not able to aswer as spf
> records are still mysterious to me.
>
> We are using BIND 9.7.
>
>
>
> Thanks in advance for your answers,
>
>
>
> Hugo,
>
>
>
>
>
>
>
> Does our DNS-server support SPF-type records? Or do we put SPF-info in a
> TXT-record?**
>
> ** **
>
> *Ref. :
> *Early implementations used TXT 
> recordsfor implementation before the 
> new record type was commonly available in DNS
> software. Use of TXT records for SPF was intended as a transitional
> mechanism. However, according to the current RFC, RFC 
> 4408,
> section 3.1.1, "An SPF-compliant domain name SHOULD have SPF records of
> both RR types. A compliant domain name MUST have a record of at least one
> type," and as such, TXT record use is not 
> deprecated.[2]
> 
>
> ** **
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Jan-Piet Mens]

> Does our DNS-server support SPF-type records? Or do we put SPF-info in a 
> TXT-record?

BIND has supported SPF records since 9.4 I think, so yes. Their
functionality is identical (i.e. define both if you want/need both)

name  ttl  class   TXT text
name  ttl  class   SPF text

Regards,

-JP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Sten Carlsen]

I used both types with Bind 9.2.1, so both types should work for you.
As I recall the only difference was txt -> spf as RR type.


hugo hugoo  wrote:

>Dear all,
> 
>I received the following question and I am not able to aswer as spf
>records are still mysterious to me.
>We are using BIND 9.7.
> 
>Thanks in advance for your answers,
> 
>Hugo,
> 
> 
> 
>Does our DNS-server support SPF-type records? Or do we put SPF-info in
>a TXT-record?
> 
>Ref. : 
>Early implementations used TXT records for implementation before the
>new record type was commonly available in DNS software. Use of TXT
>records for SPF was intended as a transitional mechanism. However,
>according to the current RFC, RFC 4408, section 3.1.1, "An
>SPF-compliant domain name SHOULD have SPF records of both RR types. A
>compliant domain name MUST have a record of at least one type," and as
>such, TXT record use is not deprecated.[2]
> 
>
>
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[G.W. Haywood]

Hi there,

On Wed, 13 Mar 2013, hugo hugoo wrote:


I received the following question and I am not able to aswer as spf
records are still mysterious to me.  We are using BIND 9.7.


Does our DNS-server support SPF-type records? Or do we put SPF-info in a 
TXT-record?


My answers would be "Yes" and "Yes".

Ref. : Early implementations used TXT records for implementation before the 
new record type was commonly available in DNS software. Use of TXT records 
for SPF was intended
as a transitional mechanism. However, according to the current RFC, RFC 4408, 
section 3.1.1, "An SPF-compliant domain name SHOULD have SPF records of both 
RR types. A
compliant domain name MUST have a record of at least one type," and as such, 
TXT record use is not deprecated.[2]


The SPF type RR seems to me to be dying.  Hardly anyone uses it.

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Shane Kerr]

Hugo,

On Wednesday, 2013-03-13 11:33:35 +, 
hugo hugoo  wrote:
> Dear all,
>  
> I received the following question and I am not able to aswer as spf
> records are still mysterious to me. We are using BIND 9.7.
>  
> Thanks in advance for your answers,
>  
> Hugo,
>  
>  
>  
> Does our DNS-server support SPF-type records? Or do we put SPF-info
> in a TXT-record? 
> Ref. : 
> Early implementations used TXT records for implementation before the
> new record type was commonly available in DNS software. Use of TXT
> records for SPF was intended as a transitional mechanism. However,
> according to the current RFC, RFC 4408, section 3.1.1, "An
> SPF-compliant domain name SHOULD have SPF records of both RR types. A
> compliant domain name MUST have a record of at least one type," and
> as such, TXT record use is not deprecated.[2] 

BIND does support the SPF type. Note however that the latest draft
version of SPF actually deprecates SPF, and recommends using TXT
records:

3.1.  DNS Resource Records

   SPF records MUST be published as a DNS TXT (type 16) Resource Record
   (RR) [RFC1035] only.  The character content of the record is encoded
   as [US-ASCII].  Use of alternate DNS RR types was supported in SPF's
   experimental phase, but has been discontinued.  See Appendix A of
   [RFC6686] for further information.

http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?include_text=1

--
Shane
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[SM]

At 04:40 AM 3/13/2013, Jan-Piet Mens wrote:

BIND has supported SPF records since 9.4 I think, so yes. Their
functionality is identical (i.e. define both if you want/need both)

name  ttl  class   TXT text
name  ttl  class   SPF text


The DNS query will likely be for TXT RRs only in future (see RFC 6686).

Regards,
-sm 


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Dave Warren]

On 3/13/2013 05:09, G.W. Haywood wrote:


Ref. : Early implementations used TXT records for implementation 
before the new record type was commonly available in DNS software. 
Use of TXT records for SPF was intended
as a transitional mechanism. However, according to the current RFC, 
RFC 4408, section 3.1.1, "An SPF-compliant domain name SHOULD have 
SPF records of both RR types. A
compliant domain name MUST have a record of at least one type," and 
as such, TXT record use is not deprecated.[2]


The SPF type RR seems to me to be dying.  Hardly anyone uses it.


This is very true. I updated my management interface to encourage "SPF" 
records, and to automatically create matching TXT records, but only 
because it's easier to sanity check when I know the intent is SPF.


I almost wouldn't bother with SPF records these days though, except that 
the code was already written.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Noel Butler]

On Wed, 2013-03-13 at 14:43 -0700, Dave Warren wrote:

> 
> I almost wouldn't bother with SPF records these days though, except that 
> the code was already written.
> 

# grep SPF maillog |grep -c '\-all'
2438

# grep SPF maillog |grep -c '\~all'
7509

since midnight Sunday... 

looks like its worth bothering with to me.



signature.asc
Description: This is a digitally signed message part
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Dave Warren]

On 3/13/2013 17:11, Noel Butler wrote:

On Wed, 2013-03-13 at 14:43 -0700, Dave Warren wrote:

I almost wouldn't bother with SPF records these days though, except that
the code was already written.


# grep SPF maillog |grep -c '\-all'
2438

# grep SPF maillog |grep -c '\~all'
7509


Can you compare that against queries to TXT style SPF records?

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Noel Butler]

On Wed, 2013-03-13 at 19:33 -0700, Dave Warren wrote:
> On 3/13/2013 17:11, Noel Butler wrote:
> 
> > 
> > On Wed, 2013-03-13 at 14:43 -0700, Dave Warren wrote: 
> > 
> > > I almost wouldn't bother with SPF records these days though, except that 
> > > the code was already written.
> > > 
> > 
> > # grep SPF maillog |grep -c '\-all'
> > 2438
> > 
> > # grep SPF maillog |grep -c '\~all'
> > 7509
> 
> 
> Can you compare that against queries to TXT style SPF records?


I'll see what I can do in the morning, its 30 past beer o'clock now




signature.asc
Description: This is a digitally signed message part
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Noel Butler]

On Thu, 2013-03-14 at 17:29 +1000, Noel Butler wrote:

> On Wed, 2013-03-13 at 19:33 -0700, Dave Warren wrote: 
> 
> > On 3/13/2013 17:11, Noel Butler wrote:
> > 
> > 
> > > On Wed, 2013-03-13 at 14:43 -0700, Dave Warren wrote: 
> > > 
> > > > I almost wouldn't bother with SPF records these days though, except 
> > > > that 
> > > > the code was already written.
> > > > 
> > > 
> > > # grep SPF maillog |grep -c '\-all'
> > > 2438
> > > 
> > > # grep SPF maillog |grep -c '\~all'
> > > 7509
> > 
> > 
> > Can you compare that against queries to TXT style SPF records?
> 
> 
> I'll see what I can do in the morning, its 30 past beer o'clock now
> 
> 



20741,  so direct SPF RR hits is about one third of those using TXT RR,
small, but, insignificant? I wouldn't really say so, but some might.  I
suspect the SPF wanting to be deprecated is because of the lack of
take-up, due to lazy admins, there are some resolvers in use from
ancient debian boxes that are so old, they dont understand the SPF RR,
yes I know, they have bigger problems than that, but, again, comes down
to laziness, DNS is not rocket science, I'm sure given ARM and access to
google, a 13yo kid could get at least the "basics" right.



signature.asc
Description: This is a digitally signed message part
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Vernon Schryver]

> 20741,  so direct SPF RR hits is about one third of those using TXT RR,
> small, but, insignificant? I wouldn't really say so, but some might.  I
> suspect the SPF wanting to be deprecated is because of the lack of
> take-up, due to lazy admins, there are some resolvers in use from
> ancient debian boxes that are so old, they dont understand the SPF RR,
> yes I know, they have bigger problems than that, but, again, comes down
> to laziness, DNS is not rocket science, I'm sure given ARM and access to
> google, a 13yo kid could get at least the "basics" right.

Laziness?--nonsense.  Postel's Law and simple logic predict the
deprecating of the SPF type as well as the continued practice of
publishing only TXT records by those with rational reasons to publish
SPF data.

 1. SMTP servers (mail receivers) that have wanted to honor SPF -all
   been forced to look for for SPF data in TXT records since the
   beginning.  There have been far more TXT records with SPF data
   than SPF records.  Therefore, the best course for SMTP servers
   has been to request TXT and only request SPF if the TXT request
   gives NODATA.  Requesting both SPF and TXT types would cost extra
   bandwidth and raise questions about what to do if both are present
   and differ.  Occassional differences between SPF and TXT are
   inevitable due to caching in recursive resolvers even when the
   authoritative server always changes both simultaneously.

 2. Rational operators of SMTP clients (mail senders) know that well
   maintained SMTP servers understand #1 and so request TXT first or
   request neither SPF nor TXT.
   Publishing only SPF type records would double an SMTP client's
   DNS costs.
   Pubishing both SPF and TXT would not help well mantained SMTP
   servers, but cost maintenance complexity and so potential errors.
   Therefore, it is best to publish only TXT for well maintained
   SMTP servers.
   Badly maintained SMTP servers are likely to only check TXT records.

Unlike the situations with IPv6 and DNSSEC, there are only costs
and no benefits for rational operators SMTP clients or servers to
change those two tactics.

Those interested in wider perspectives about SPF and TXT RRs than any
single domain or the perceptions of SPF enthusiasts might consider the
tables reporting surveys in RFC 6686.  One can ignore everything
specifically about SenderID and read only about popularity of SPF and
TXT records.  https://www.rfc-editor.org/rfc/rfc6686.txt


Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Mark Andrews]

In message <201303180038.r2i0cwet026...@calcite.rhyolite.com>, Vernon Schryver 
writes:
> > 20741,  so direct SPF RR hits is about one third of those using TXT RR,
> > small, but, insignificant? I wouldn't really say so, but some might.  I
> > suspect the SPF wanting to be deprecated is because of the lack of
> > take-up, due to lazy admins, there are some resolvers in use from
> > ancient debian boxes that are so old, they dont understand the SPF RR,
> > yes I know, they have bigger problems than that, but, again, comes down
> > to laziness, DNS is not rocket science, I'm sure given ARM and access to
> > google, a 13yo kid could get at least the "basics" right.
> 
> Laziness?--nonsense.  Postel's Law and simple logic predict the
> deprecating of the SPF type as well as the continued practice of
> publishing only TXT records by those with rational reasons to publish
> SPF data.
> 
>  1. SMTP servers (mail receivers) that have wanted to honor SPF -all
>been forced to look for for SPF data in TXT records since the
>beginning.  There have been far more TXT records with SPF data
>than SPF records.  Therefore, the best course for SMTP servers
>has been to request TXT and only request SPF if the TXT request
>gives NODATA.  Requesting both SPF and TXT types would cost extra
>bandwidth and raise questions about what to do if both are present
>and differ.  Occassional differences between SPF and TXT are
>inevitable due to caching in recursive resolvers even when the
>authoritative server always changes both simultaneously.

Yet libspf2 requests SPF records and falls back to TXT on NODATA.
It does not do a TXT query if it gets a SPF response.
 
>  2. Rational operators of SMTP clients (mail senders) know that well
>maintained SMTP servers understand #1 and so request TXT first or
>request neither SPF nor TXT.
>Publishing only SPF type records would double an SMTP client's
>DNS costs.
>Pubishing both SPF and TXT would not help well mantained SMTP
>servers, but cost maintenance complexity and so potential errors.
>Therefore, it is best to publish only TXT for well maintained
>SMTP servers.
>Badly maintained SMTP servers are likely to only check TXT records.

The rational course would be to set a sunset date on TXT style spf
records.  April 2016 looks like a good date.  10 years after RFC
4408 was published.

> Unlike the situations with IPv6 and DNSSEC, there are only costs
> and no benefits for rational operators SMTP clients or servers to
> change those two tactics.
> 
> Those interested in wider perspectives about SPF and TXT RRs than any
> single domain or the perceptions of SPF enthusiasts might consider the
> tables reporting surveys in RFC 6686.  One can ignore everything
> specifically about SenderID and read only about popularity of SPF and
> TXT records.  https://www.rfc-editor.org/rfc/rfc6686.txt
> 
> 
> Vernon Schryverv...@rhyolite.com
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Noel Butler]

> Vernon Schryver writes:

> > > to laziness, DNS is not rocket science, I'm sure given ARM and
> access to
> > > google, a 13yo kid could get at least the "basics" right.
> > 
> > Laziness?--nonsense.  Postel's Law and simple logic predict the



truth hurts eh.

Didn't see your original post, viewed and had to reply via Marks.
Seems your original scored 17 and was discarded


Mark said:
>
>The rational course would be to set a sunset date on TXT style spf
>records.  April 2016 looks like a good date.  10 years after RFC
>4408 was published.

I'd go along with that, if they can't get their act together within 3
years, then that IS pure laziness.



signature.asc
Description: This is a digitally signed message part
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Vernon Schryver]

> From: Mark Andrews 

> Yet libspf2 requests SPF records and falls back to TXT on NODATA.
> It does not do a TXT query if it gets a SPF response.

Even if my option of SPF is insane, compare the 2008 dates on
http://www.libspf2.org/ and the 2012 date on the surveys in RFC 6686.
It's clear that for whatever real world reasons, libspf2 was not
dispositive and that draft-ietf-spfbis-4408bis-12 is right to
deprecate the SPF type in section 3.1.


> The rational course would be to set a sunset date on TXT style spf
> records.  April 2016 looks like a good date.  10 years after RFC
> 4408 was published.

The rational course usually starts with accepting reality as it is.

In the real world, flag days are ignored by most people until there
is clear profit in honoring them or loss in ignoring them.  A loss can
be "We've stopped updating the hosts file so if you want your stuff
to work, you better get busy with the DNS."  Wasting a round trip to
get NODATA for the SPF RR for google.com or hotmail.com before requesting
the TXT RR is not a profit.  There is no real world profit in "It is
esthetically pleasing to put SPF data into its own RR type."

Your flag day for turning off IPv4 in the core must be soon, because
IPv6 has already been baking for a lot longer than 10 years.  Besides,
unlike TXT for SPF, IPv4 has real problems in the real world.


Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Mark Andrews]

In message <201303180329.r2i3tycx025...@calcite.rhyolite.com>, Vernon Schryver 
writes:
> > From: Mark Andrews 
>
> > Yet libspf2 requests SPF records and falls back to TXT on NODATA.
> > It does not do a TXT query if it gets a SPF response.
>
> Even if my option of SPF is insane, compare the 2008 dates on
> http://www.libspf2.org/ and the 2012 date on the surveys in RFC 6686.
> It's clear that for whatever real world reasons, libspf2 was not
> dispositive and that draft-ietf-spfbis-4408bis-12 is right to
> deprecate the SPF type in section 3.1.

MX records took over a decade before one could have a MX only domain
safely.  Changes in the DNS just take a long time.  4 years is less
than 1 depreciation cycle on equipement and they give up.  RFC 4408
failed to set a sunset date.

> > The rational course would be to set a sunset date on TXT style spf
> > records.  April 2016 looks like a good date.  10 years after RFC
> > 4408 was published.
>
> The rational course usually starts with accepting reality as it is.
>
> In the real world, flag days are ignored by most people until there
> is clear profit in honoring them or loss in ignoring them.  A loss can
> be "We've stopped updating the hosts file so if you want your stuff
> to work, you better get busy with the DNS."  Wasting a round trip to
> get NODATA for the SPF RR for google.com or hotmail.com before requesting
> the TXT RR is not a profit.  There is no real world profit in "It is
> esthetically pleasing to put SPF data into its own RR type."

It's not that is is esthetically pleasing to put SPF data into its
own RR type.  It's that TXT has been hijacked and contining to add
more uses to TXT does not scale.  TXT is a reasonable record for
proof of concept.  It isn't and never has been a good long term
choice.

> Your flag day for turning off IPv4 in the core must be soon, because
> IPv6 has already been baking for a lot longer than 10 years.  Besides,
> unlike TXT for SPF, IPv4 has real problems in the real world.

Turning off lookup for TXT record lookup for SPF would have very
little negative impact.  You would have some additional spoofed
email getting through and some additional blow back (which could
be eliminated by publish SPF records).

> Vernon Schryverv...@rhyolite.com
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Doug Barton]

On 3/17/2013 5:59 PM, Mark Andrews wrote:

The rational course would be to set a sunset date on TXT style spf
records.  April 2016 looks like a good date.  10 years after RFC
4408 was published.


+1
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[nudge dread]

On Mon, Mar 18, 2013, at 03:19 AM, Noel Butler wrote:
> 
> > Vernon Schryver writes:
> 
> > > > to laziness, DNS is not rocket science, I'm sure given ARM and
> > access to
> > > > google, a 13yo kid could get at least the "basics" right.
> > > 
> > > Laziness?--nonsense.  Postel's Law and simple logic predict the
> 
> 
> 
> truth hurts eh.
> 
> Didn't see your original post, viewed and had to reply via Marks.
> Seems your original scored 17 and was discarded
> 
> 
> Mark said:
> >
> >The rational course would be to set a sunset date on TXT style spf
> >records.  April 2016 looks like a good date.  10 years after RFC
> >4408 was published.
> 
> I'd go along with that, if they can't get their act together within 3
> years, then that IS pure laziness.


Laziness can be not reading RFC6686 Appendix A: about how it is not
rational to keep SPF RRTYPE99 and how things got confusing in part
because of pressure from some DNS experts.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Vernon Schryver]

> > I'd go along with that, if they can't get their act together within 3
> > years, then that IS pure laziness.

I think "laziness" better fits answering port 443 with HTTP/TLS-SSL
and not publishing DANE RRs with existing certs or fingerprints.
The contrib/dane directory in current versions of BIND has a shell
script that I think makes doing that easy.

Also, those who are not lazy, who think RFC 4408bis is wrong, and want
to use type 99 without violating RFC 4408bis will go to the IEFF.


> Laziness can be not reading RFC6686 Appendix A: about how it is not
> rational to keep SPF RRTYPE99 and how things got confusing in part
> because of pressure from some DNS experts.

I agree that laziness can be pontificating without bothering to read,
but that text mostly blames SPF enthusiasts in points #1-#4.  The
complaints about DNS experts concern future RRTYPE problems.



} From: Mark Andrews 

} MX records took over a decade before one could have a MX only domain
} safely.

MX records have significantly benefits.  Switching from TXT to type
99 has no foreseeable operational benefit.  There never has been and
never will be flag day for MXs.

}RFC 4408
} failed to set a sunset date.

It would be the same if RFC 4408 had a sunset date, because RFC 4408
came too late.  In hindsight today, the relevant error among many far
worse and always obvious errors was not using a label like _spf.
Regardless of all of that, RFC 4408 did not set a sunset date,
and RFC 4408bis does deprecate type 99.


} It's not that is is esthetically pleasing to put SPF data into its
} own RR type.  It's that TXT has been hijacked and contining to add
} more uses to TXT does not scale.  TXT is a reasonable record for
} proof of concept.  It isn't and never has been a good long term
} choice.

I can't argue with that, but reality is that switching from TXT to
type 99 has costs and no benefits other than what most people see
as mere esthetics.  There are many features in the DDN Protocol
Suite that could have been better including scaling better, but
even 25 years ago was too late for flag days for anything in use.
All that can be done is designing something better with very low
transition costs and/or significant practical benefits and hoping
people won't be too lazy.  (e.g. DANE again)


} Turning off lookup for TXT record lookup for SPF would have very
} little negative impact.  You would have some additional spoofed
} email getting through and some additional blow back (which could
} be eliminated by publish SPF records).

I agree with this translation of that statement:

  Google, Hotmail, AOL, and the other large inbox providers could
  agree with the ESPs to ignore RFC 4408bis and switch to type 99.
  They are already violating RFC 4408 and RFC 4408bis with DMARC
  with far more operational significance.

However, my bet is that Google et al will do as many others have done.
They will care about the costs that you label "very little negative
impact" and ignore those hypothetical TXT abuse scaling problems...not
to mention complying with RFC 4408bis.
Whatever is done by vanity domains and by domains that publish ~all
or ?all without _dmarc will remain irrelevant.


Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Dave Warren]

On 2013-03-17 22:35, Doug Barton wrote:

On 3/17/2013 5:59 PM, Mark Andrews wrote:

The rational course would be to set a sunset date on TXT style spf
records.  April 2016 looks like a good date.  10 years after RFC
4408 was published.


+1


Unfortunately there's really no need to change behaviour even if we have 
a sunset date. As a server operator, I'd still check both (because it 
doesn't cost anything) and I'd still publish both because it simply 
doesn't matter.


Sure, some might eventually move away from TXT records, and this would 
(IMO) be a good thing, but still...


Perhaps DK/DKIM got it right here, _spf.example.com. TXT records would 
be a lot more flexible, wouldn't overload a zone/host's TXT records and 
wouldn't require everyone to upgrade DNS infrastructure to add support. 
But water under the bridge, it's not like inventing another standard for 
the majority to ignore would help at this point.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Mark Andrews]

In message <201303181535.r2ifz8ga017...@calcite.rhyolite.com>, Vernon Schryver 
writes:
> } Turning off lookup for TXT record lookup for SPF would have very
> } little negative impact.  You would have some additional spoofed
> } email getting through and some additional blow back (which could
> } be eliminated by publish SPF records).
> 
> I agree with this translation of that statement:
> 
>   Google, Hotmail, AOL, and the other large inbox providers could
>   agree with the ESPs to ignore RFC 4408bis and switch to type 99.
>   They are already violating RFC 4408 and RFC 4408bis with DMARC
>   with far more operational significance.
> 
> However, my bet is that Google et al will do as many others have done.
> They will care about the costs that you label "very little negative
> impact" and ignore those hypothetical TXT abuse scaling problems...not
> to mention complying with RFC 4408bis.
> Whatever is done by vanity domains and by domains that publish ~all
> or ?all without _dmarc will remain irrelevant.

It is or would have been, very little cost to publish SPF records.
The flag day was for publishers to publish SPF records by.  Once
you have clients not looking for TXT records there is a incentive
to publish SPF records.

Now we have the "fun" of deprecating SPF records.  When do we start
breaking zones that contain SPF records?  How long before we can
re-use the type code?  Deprecating SPF records rather than completing
the transition was a bad decision.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[SM]

At 08:35 18-03-2013, Vernon Schryver wrote:

Also, those who are not lazy, who think RFC 4408bis is wrong, and want
to use type 99 without violating RFC 4408bis will go to the IEFF.


I suggest reading the messages with a subject line of "#9: RFC 4408 
SPF RR type" in the mail archive at 
http://www.ietf.org/mail-archive/web/spfbis/current/


Regards,
-sm 


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Noel Butler]

On Mon, 2013-03-18 at 16:52 -0700, SM wrote:

> SPF RR type



Had a bit of a read of that thread, and the most noise comes from a guy
who should know better, but doesn't, Mr Kitterman repeatedly says  "If
it's all so obvious that it makes sense to publish SPF records, why
aren't more people doing it? "

The answer is simple, and he knows it, very few system admins know or
care about which specific RFC covers what, they hear things, it gains
momentum, like googling for anti spam, stop spoofing, stuff like that,
Ohhh they say, 'nice, I'll check that out' they load google"create
an SPF record"
Now google shows me as of 60 seconds ago,  first five entries using only
TXT RR's as examples
(at lucky number 6 it shows me someone saying to use SPF RR)   So, new
-to-spf adminy type, fires up vi, pico, whatever... adds it, it works!
yay they say, they spread the word, " adminy2 says" nice how did you do
it" adminy1 shows adminy2 copies, and its just like life, the cycle
repeats over and over and...


Secondly, Mr Kitterman, as a debian packager, would be highly aware of
how many "deprecated" versions of debian are out there running resolvers
that do not understand SPF and have not been supported by any upstream
in ten years, and, I'm sure that is also probably true of early RHEL's
as well.


Back in the dark ages, I learned about SPF from word-of-mouth too, like
most here I'm sure, and if WOM shows you one way, thats the way you do
it, lets face it, you discover a new method, you dont go rushing to rfc
website to read all about it, I have only been doing SPF RR's since
hrmm, maybe 4 years back? not sure, too long ago, but have used TXT
since, it started to get bandied around the sendmail newsgroup some
ancient time ago.

I found out about the existence of SPF RR type, from this very list,
how many subscribers to this list? 1500 odd, how many sys admins world
wide? hundred thousand plus maybe, how many are even aware of the SPF
RR? probably not that many, I recently discovered that a 'drinks
session' out of 9 sys admins, myself and ONE other were even aware of
the SRV RR type. Not all corporations/SP's/ASP's or ISP's,  have
dedicated DNS admins who can concentrate full time on all things DNS,
I'm not a full time DNS admin, since it works nicely and doesnt occupy
all my time :)

Many of the domain parking organisations are just as guilty, even up
until two years ago, I used zoneedit for my personal DNS, and they did
not have an option for SPF, I hounded them for a couple of months before
they eventually replied saying, no intentions, so how many others also
did not offer it.

So, there are a myriad of reasons as to why the SPF RR type 99 never
"took of"

<>

signature.asc
Description: This is a digitally signed message part
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[John Wobus]

On Mar 18, 2013, at 12:00 AM, Mark Andrews wrote:

It's not that is is esthetically pleasing to put SPF data into its
own RR type.  It's that TXT has been hijacked and contining to add
more uses to TXT does not scale.  TXT is a reasonable record for
proof of concept.  It isn't and never has been a good long term
choice.


Absolutely.  What we should be pushing for is a spec such that if
followed, is sufficient to work, for SPF and for other users of TXT.
We should be on that track even if it is necessary to allow a lot
of time to accommodate the effort.  Ways I can see to get
back there:

1) An RFC (or RFCs) that specifies a set of specific TXT record content
formats that are specified to have particular meanings, e.g. 'don't do  
the

following unless it's an SPF record'.

2) Going even further, layer another protocol (and registry) on top
of TXT records specifying the meaning of various prefixes.

3) Transition widely-used systems that are prototyped with TXT
to an RR type specified for the purpose.

The last could even be a new TXT-like RR type invented specifically for
supporting for layering more protocols, along with a registry of  
prefixes.

I'm not enamored of that, but at least it gives the world the means to
avoid tripping over each other's feet.

It's natural that folks whose primary interest is SPF should find
all this to be busy-work of little value to themselves or
their customer base.  The benefit is for future efforts of
the SPF-sort, and it's been fortunate for the
SPF effort that TXT records were available to them without
a lot of earlier-established complicated rules of use, so they
could use TXT records to jump-start their efforts.

John Wobus
Cornell U
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[Vernon Schryver]

> From: John Wobus 

> 1) An RFC (or RFCs) that specifies a set of specific TXT record content
> formats that are specified to have particular meanings, e.g. 'don't do  
> the
> following unless it's an SPF record'.

I've not been keeping up with the IETF; is there a document that
describes what looks like a de facto standard of using _pname labels
with TXT RRs that is being followed by at least DMARC and DANE in
*._tcp.example.com, *._smimecert.example.com, and _dmarc.example.com
https://tools.ietf.org/html/rfc6698
https://tools.ietf.org/html/draft-fanf-dane-smtp-04
https://tools.ietf.org/html/draft-hoffman-dane-smime-04
http://www.dmarc.org/draft-dmarc-base-00-02.txt

Is SRV the precedent being followed?


Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[John Levine]

>I've not been keeping up with the IETF; is there a document that
>describes what looks like a de facto standard of using _pname labels
>with TXT RRs that is being followed by at least DMARC and DANE in
>*._tcp.example.com, *._smimecert.example.com, and _dmarc.example.com

No, but Dave Crocker is working on one.

>Is SRV the precedent being followed?

Yes.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: spf ent txt records.

[John Levine]

>It is or would have been, very little cost to publish SPF records.

Not until we fix the provisioning problem.  (News flash: in 99.9% of
the Internet, people do not edit master files with vi.)

In the early days of SPF, it was remarkably hard to get TXT records
provisioned, even though TXT records have been part of the DNS since
the beginning.  People had to go to their hosting companies, and the
places that produce the web software they use, and persuade them to
handle TXT, since in most cases it's just A, MX, and maybe CNAME.

Having gone through that pain, nobody has any interest in going
through it again for new rrtypes.  I can assure you that the vast
majority of the provisioning software that people use handles only a
small subset of existing defined rrtypes.

I have a draft about a DNS master file extension language with the
goal being that DNS servers and particularly provisioning software can
be updated by adding lines to configuration files rather than by
rewriting code.  Vixie (now a co-author) had the clever idea of
publishing the config info in a well known place in the DNS so the
configuration can be automatic.

https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users