New warning message...

[SH Development]

I just started noticing these in my log:

7/21/13 11:33:13 PM named[355] 21-Jul-2013 23:33:13.646 general: warning: zone domain.com/IN: 'domain.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record

The zone does have an SPF record. I'm not sure I understand what else I'm supposed to be doing.

Jeff

[Mark Andrews]

No. It has a legacy SPF TXT record. It SHOULD have record of
type SPF as per RFC 4408. Named will complain if both types
are not present.

3.1.1. DNS Resource Record Types

This document defines a new DNS RR of type SPF, code 99. The format
of this type is identical to the TXT RR [RFC1035]. For either type,
the character content of the record is encoded as [US-ASCII].

It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose.

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. If a domain has records of both types, they MUST have
identical content. For example, instead of publishing just one
record as in Section 3.1 above, it is better to publish:

example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"

Example RRs in this document are shown with the TXT record type;
however, they could be published with the SPF type or with both
types.


> Jeff
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@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

[Noel Butler]

On Mon, 2013-07-22 at 02:51 -0400, Jason Hellenthal wrote:

It's exactly as it says...

Instead of 

... TXT "SPF ..."

You now do

... SPF "SPF ..."

Mark Andrews wrote:
No.  It has a legacy SPF TXT record.  It SHOULD have record of
type SPF as per RFC 4408.

Named will complain if both types are not present.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[G.W. Haywood]

Hi there,

On Mon, 22 Jul 2013, Jason Hellenthal wrote:

> It's exactly as it says...
>
> Instead of
> ... TXT "SPF ..."
>
> You now do
>
> ... SPF "SPF ..."

Caution! The SPF record type is near enough dead. See in particular
RFC6686 paragraph 5.6; paragraph 6.2; and Appendix A point 4.

--

73,
Ged.

[Matus UHLAR - fantomas]

>On Mon, 22 Jul 2013, Jason Hellenthal wrote:
>>It's exactly as it says...
>>
>>Instead of ... TXT "SPF ..."
>>
>>You now do
>>
>>... SPF "SPF ..."

On 22.07.13 11:26, G.W. Haywood wrote:
>Caution! The SPF record type is near enough dead. See in particular
>RFC6686 paragraph 5.6; paragraph 6.2; and Appendix A point 4.

This was discussed here already, and imho this is anti-spf bullshit like
all those "spf breaks forwarding" FUD. The SPF RR is already here and is
preferred over TXT that is generik RR type, unlike SPF.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.

[Barry S. Finkel]

> This was discussed here already, and imho this is anti-spf bullshit like
> all those "spf breaks forwarding" FUD. The SPF RR is already here and is
> preferred over TXT that is generik RR type, unlike SPF.

It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
SPF *DOES* break forwarding. I have a case I am researching right now
where forwarded mail is undeliverable due to SPF checking at the
new destination.

--Barry Finkel

[Matus UHLAR - fantomas]

>>This was discussed here already, and imho this is anti-spf bullshit like
>>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
>>preferred over TXT that is generik RR type, unlike SPF.

On 22.07.13 08:50, Barry S. Finkel wrote:
>It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
>SPF *DOES* break forwarding.

No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail. Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.

> I have a case I am researching right now
>where forwarded mail is undeliverable due to SPF checking at the
>new destination.

Rewrite the sender's address. You have more choices, SRS is one of them.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

Fucking windows! Bring Bill Gates! (Southpark the movie)

[Barry Margolin]

In article <mailman.881.1374508...@lists.isc.org>,

Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

> >>This was discussed here already, and imho this is anti-spf bullshit like
> >>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
> >>preferred over TXT that is generik RR type, unlike SPF.
>
> On 22.07.13 08:50, Barry S. Finkel wrote:
> >It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
> >SPF *DOES* break forwarding.
>
> No, it does not. If a mail gets delivered to address, which is sending it
> further ("forwarding it"), the envelope sender has to be changed, because
> it's not the original sender who sends the another mail. Forwarding without
> changing envelope address is already broken, it's just people don't care
> without SPF.
>
> > I have a case I am researching right now
> >where forwarded mail is undeliverable due to SPF checking at the
> >new destination.
>
> Rewrite the sender's address. You have more choices, SRS is one of them.

They're talking about auto-forwarding, not people resending a message
they received. For instance, mail to bar...@alum.mit.edu is
automatically forwarded by the alum.mit.edu server to my ISP email
address. Many people also have vanity domains with auto-forwarding
enabled like this.

Who should the sender be changed to? AFAIK, it has never been standard
practice to rewrite the sender when simply forwarding to an alias, which
is what this is.

--
Barry Margolin
Arlington, MA

[Barry S. Finkel]

On 7/22/2013 11:17 AM, bind-user...@lists.isc.org wrote:
>>> This was discussed here already, and imho this is anti-spf bullshit like
>>> >>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
>>> >>preferred over TXT that is generik RR type, unlike SPF.
> On 22.07.13 08:50, Barry S. Finkel wrote:
>> >It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".

>> >SPF*DOES* break forwarding.

> No, it does not. If a mail gets delivered to address, which is sending it
> further ("forwarding it"), the envelope sender has to be changed, because
> it's not the original sender who sends the another mail. Forwarding without
> changing envelope address is already broken, it's just people don't care
> without SPF.

>> > I have a case I am researching right now
>> >where forwarded mail is undeliverable due to SPF checking at the
>> >new destination.
> Rewrite the sender's address. You have more choices, SRS is one of them.
>

> -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/

I have no control over what my Mail User Agent does. And a quick reading
of section 3.6.6 of RFC 5322 does not tell me what is the correct action
on a forwarded message:

1) Change the "From:" address, or

2) Keep the "From:" address.

My MUA, Thunderbird, does 1). And I do not see any configuration
option. I am not sure which action is "correct".

I do not know what implications for forwarding SMTP (RFC 5321) has.
--Barry Finkel

[Stanley Weilnau]

I have just set up DNSSEC on bind 9.9.3. I had set up the zone and put a DS record out at the registrar. Several days later I found that I had set up the keys incorrectly using only NSEC verses NSEC3 so i changed the keys. I deleted the old keys and DS record, and had bind resign everything and put out the new DS record. I used some testing sites and things looked good. I then got a message from an administrator at a remote site running bind in strict mode stating my DNSSEC was broken. It turns out he had cached the old info and it had not updated. From this I am guessing that bind does not flush cache if there is a problem like this, it just fails to resolve.

The other question I am attempting to research is what is the best way to do the yearly rekeying and updating of the DS records at the registrar to avoid this in the future.

--
Stanley Weilnau

[Chris Buxton]

Do not be confused by the From: address shown by your mail client. That is not the envelope sender.

Chris

[Noel Butler]

On Mon, 2013-07-22 at 08:50 -0500, Barry S. Finkel wrote:

> This was discussed here already, and imho this is anti-spf bullshit like
> all those "spf breaks forwarding" FUD. The SPF RR is already here and is
> preferred over TXT that is generik RR type, unlike SPF.


It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
SPF *DOES* break forwarding.  I have a case I am researching right now
where forwarded mail is undeliverable due to SPF checking at the
new destination.

Nothing is perfect, every single gmail user coming via mailing lists also fails DKIM.
There is no magic answer, but I wish more would enforce SPF, especially banks, but cant expect them to have any clue, their only expertise is ripping people off.

[Mark Andrews]

In message <C27F9ADB-21A3-445D...@cnri.reston.va.us>, Stanley We

You have NEVER been able to change anything in the DNS instananeously.
DNSSEC just makes that more obvious as you get big breakages instead
of little breakages.

For example when you are changing nameservers the old servers should
be configured to serve the new zone content with the new nameservers
and the old nameservers only get turned off when once all the cached
NS records referring to them have expired. If you don't do that
caches can continue to query the old servers forever.

Firstly you should not use NSEC3 unless you NEED to use NSEC3, NSEC
is more than sufficient for most zones. NSEC3 is more expensive
for both servers and clients. 99.999% of zones (forward and reverse)
DO NOT need to use NSEC3. They derive NO benefit from NSEC3 compared
to using NSEC. In most case NSEC3 is actually a negative as not
only is is more computationally expensive it is harder to debug.

NSEC3 is pointless for IP6.ARPA, IN-ADDR.ARPA and any other similarly
structured zones. The structure defeats any attempt to prevent zone
walking.

For most forward zones preventing zone walking does NOTHING except
give warm fuzzy feelings. It does NOT make your machines any safer.
Yes I know that this is against all the advice you have received
in the past but really it doesn't appreciably help and you are
deluding yourself if you think it does.

Mark

[Matus UHLAR - fantomas]

>In article <mailman.881.1374508...@lists.isc.org>,
> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

>> No, it does not. If a mail gets delivered to address, which is sending it
>> further ("forwarding it"), the envelope sender has to be changed, because
>> it's not the original sender who sends the another mail. Forwarding without
>> changing envelope address is already broken, it's just people don't care
>> without SPF.

On 22.07.13 12:22, Barry Margolin wrote:
>They're talking about auto-forwarding, not people resending a message
>they received. For instance, mail to bar...@alum.mit.edu is
>automatically forwarded by the alum.mit.edu server to my ISP email
>address. Many people also have vanity domains with auto-forwarding
>enabled like this.

I'm afraid the same applies even in these cases.
How can you differ between vanity forwarder and spam/phish with fake from
address?

>> Rewrite the sender's address. You have more choices, SRS is one of them.

This would help in other ways too - at my former employer we've had to deal
with broken forwardings, therefore undeliverable mail and undeliverable
bounces. Rewriting sender and properly detecting undeliverable garbage
helps there too.

>Who should the sender be changed to? AFAIK, it has never been standard
>practice to rewrite the sender when simply forwarding to an alias, which
>is what this is.

Because they did not care. Long time ago even open relays were not an issue
until people started abusing them.


...OK this is off-topic here. However this was already discussed and the
conclusion was that the SPF record is NOT dead. We just need enough time to
deal with these issues.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

I don't have lysdexia. The Dog wouldn't allow that.

[Daniel McDonald]

On 7/23/13 7:36 AM, "Matus UHLAR - fantomas" wrote:

>> In article <mailman.881.1374508...@lists.isc.org>,

>> Matus UHLAR - fantomas wrote:
>>> No, it does not. If a mail gets delivered to address, which is sending it
>>> further ("forwarding it"), the envelope sender has to be changed, because
>>> it's not the original sender who sends the another mail. Forwarding without
>>> changing envelope address is already broken, it's just people don't care
>>> without SPF.
>
> On 22.07.13 12:22, Barry Margolin wrote:
>> They're talking about auto-forwarding, not people resending a message
>> they received. For instance, mail to bar...@alum.mit.edu is
>> automatically forwarded by the alum.mit.edu server to my ISP email
>> address. Many people also have vanity domains with auto-forwarding
>> enabled like this.
>

Ok, but in this case you are trusting alum.mit.edu as a forwarder. And it
is specific to you as the recipient, not all of the people in the world
getting your mail. So add them to trusted-hosts and apply spf before the
last trusted... Problem solved. Or add enough whitelist points to
counteract SPF problems when a /^Received.{5,40}\balum.mit.edu/ header is
found in your mail. In either case, you have to either trust your forwarder
to evaluate SPF for you and trust the SPF evaluation headers they insert, or
consider that forwarder part of your mail infrastructure and instruct your
spf evaluator to ignore those headers.

But again, that's your choice for outsourcing part of your mail solution to
another entity.

> ...OK this is off-topic here. However this was already discussed and the
> conclusion was that the SPF record is NOT dead. We just need enough time to
> deal with these issues.

--

Daniel J McDonald, CCIE # 2495, CISSP # 78281

[Lawrence K. Chen, P.Eng.]

----- Original Message -----
> I have just set up DNSSEC on bind 9.9.3. I had set up the zone and
> put a DS record out at the registrar. Several days later I found

> that I had set up the keys incorrectly using only NSEC verses NSEC3
> so i changed the keys. I deleted the old keys and DS record, and
> had bind resign everything and put out the new DS record. I used

> some testing sites and things looked good. I then got a message
> from an administrator at a remote site running bind in strict mode
> stating my DNSSEC was broken. It turns out he had cached the old

> info and it had not updated. From this I am guessing that bind does

> not flush cache if there is a problem like this, it just fails to
> resolve.
>
> The other question I am attempting to research is what is the best
> way to do the yearly rekeying and updating of the DS records at the
> registrar to avoid this in the future.
>

Maybe in preparation for the change, lower the validity period to reduce cache lifetimes. Not sure if the full procedure for Emergency Key Rollover would work in this case.

Since there's something about mixing algorithms? Because I had problems when I was switching from RSASHA1-NSEC3-SHA1 to RSASHA256... which is odd, because the registrar had apparently done it....or maybe they had problems that they didn't pass along...though I didn't follow their scheme as closely (partly because I lack the ability to instantly update my DS records.)

... EDUCAUSE is in the process of transitioning the DNSSEC signature
... for the .edu zone from RSA-NSEC3-SHA1 (algorithm 7) to
... RSA/SHA-256 (algorithm 8). Here are the steps that will occur:
...
...... The algorithm rollover will begin with pre-signing records
...... with new ZSK key, using the RSA/SHA-256 algorithm. This
...... period is expected to begin on November 19, 2011 and will
...... last for nine days.
......
...... The pre-signing period will be immediately followed by the
...... publication of the DNSKEY records for the new KSK and ZSK
...... keys in the .edu zone. Once resolvers have the new KSK’s
...... DNSKEY record cached, the DS record for the new KSK will
...... be published in the root zone and the previous DS record
...... will be removed.
......
...... The records in the .edu zone will be signed with both
...... old and new algorithms with both ZSK and KSK keys for a
...... period of 14 days. After this period, the old ZSK and the
...... old KSK will have their DNSKEY records removed from the
...... .edu zone. The old ZSK will continue signing for three
...... more days to allow time for all caching resolvers to have
...... purged the old ZSK’s DNSKEY record from their caches.
......
...... Immediately following this three-day period, the rollover
...... will conclude with a period when the signatures with the
...... old ZSK will be systematically and gradually removed
...... from the .edu zone. This period is expected to last
...... between four and seven days.

Lawrence

[Lawrence K. Chen, P.Eng.]

----- Original Message -----

> Firstly you should not use NSEC3 unless you NEED to use NSEC3, NSEC
> is more than sufficient for most zones. NSEC3 is more expensive
> for both servers and clients. 99.999% of zones (forward and reverse)
> DO NOT need to use NSEC3. They derive NO benefit from NSEC3 compared
> to using NSEC. In most case NSEC3 is actually a negative as not
> only is is more computationally expensive it is harder to debug.
>
> NSEC3 is pointless for IP6.ARPA, IN-ADDR.ARPA and any other similarly
> structured zones. The structure defeats any attempt to prevent zone
> walking.
>
> For most forward zones preventing zone walking does NOTHING except
> give warm fuzzy feelings. It does NOT make your machines any safer.
> Yes I know that this is against all the advice you have received
> in the past but really it doesn't appreciably help and you are
> deluding yourself if you think it does.
>
> Mark

I remember when I first started working on DNSSEC...on whether NSEC3 should be done or not. signing the zone was taking either forever or forever-plus..... Moving my master server from a V240 to a T2000 helped....

But, we then got some outside secondaries. And, initially they didn't support NSEC3. That would have to wait until they upgraded their server hardware/OS before they would build bind with that support? So, I thought that answered whether we would do NSEC3 or not. But, then our IT Security group weighed in....so we're doing NSEC3. We'll just hold off on having outside secondaries.

Though since then, we've only had one major interruption of our connectivity...and its was due the packet inspection appliance that IT Security runs. The log volume in it had filled up, so it stopped passing traffic. It did expose some problems with in local DNS resolution, that someday I should do something about.

T2000 was still taking what was considered to be too long....people around here expect that when I make complete their dns change request, that they can immediately look up host and see the new IP. Ignoring that they queried all the caching servers on campus before the request was done, so the old info will be there for up to 1 day. Some people will request that the TTL be lowered in advance of the change, though they don't necessarily allow a day between the two.

Later I had the choice of moving to a T5120 or an X4100, where I found that the X4100 was faster than the T5120. My master server is currently an X4170. And, later our automation includes flushing our zones from the caching servers.... Also have a script to flush other zones when needed, but that process can't tell what zones were updated...so it can't tell what zone to flush. (one is see if files associated with our signed zones changed, do signing, call rndc reload and then over time flush caching servers in some order...the other is if any file has changed, do rndc reload....)

Wonder what I'll have when we scrap some 400+ Solaris servers ... by year end?

--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library

[Stephane Bortzmeyer]

On Mon, Jul 22, 2013 at 03:01:47PM +1000,
Mark Andrews <ma...@isc.org> wrote

a message of 56 lines which said:

> It SHOULD have record of type SPF as per RFC 4408. Named will
> complain if both types are not present.

Then, named is now wrong, since RFC 6686.

[Stephane Bortzmeyer]

On Mon, Jul 22, 2013 at 12:39:53PM +0200,

Matus UHLAR - fantomas <uh...@fantomas.sk> wrote

a message of 28 lines which said:

> This was discussed here already, and imho this is anti-spf bullshit
> like all those "spf breaks forwarding" FUD. The SPF RR is already
> here and is preferred over TXT that is generik RR type, unlike SPF.

I don't see any connection with anti-SPF stances. Whether you love or
despise SPF, the facts (RFC 6686, sections 5 and 6) are that the "SPF"
record (type 99) is not used at all and that the TXT record is now the
only one recommended (if you do SPF, which probably means you did not
believe the FUD).

[McDonald, Dan]

On Jul 24, 2013, at 4:48 AM, "Stephane Bortzmeyer" <bortz...@nic.fr> wrote:

> On Mon, Jul 22, 2013 at 12:39:53PM +0200,
> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote
> a message of 28 lines which said:
>
>> This was discussed here already,

[...]

>> The SPF RR is already
>> here and is preferred over TXT that is generik RR type, unlike SPF.
>

> Whether you love or
> despise SPF, the facts (RFC 6686, sections 5 and 6) are that the "SPF"
> record (type 99) is not used at all

And so, to speed adoption of the SPF RR type, ISC is prompting admins to go back and look at their settings so that they can migrate. If a critical mass of admins publish SPF RR types, then the results of the experiment documented in rfc 6686 would be vastly different if repeated.

SPF RR types are already standards track - see RFC 6652. An informational rfc warning that the standard is not being adopted should be seen as a call to fix the admins, not discard the standard.

[Mark Andrews]

RFC 6686 does *not* update RFC 4408.

[SM]

Hi Dan,

At 03:07 24-07-2013, McDonald, Dan wrote:
>SPF RR types are already standards track - see RFC 6652. An
>informational rfc warning that the standard is not being adopted
>should be seen as a call to fix the admins, not discard the standard.

The SPF specification is not on the Standards Track. RFC 6652 is about ARF.

Regards,
-sm

[Mark Andrews]

In message <20130724094...@nic.fr>, Stephane Bortzmeyer writes:
> On Mon, Jul 22, 2013 at 12:39:53PM +0200,
> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote
> a message of 28 lines which said:
>

> > This was discussed here already, and imho this is anti-spf bullshit

> > like all those "spf breaks forwarding" FUD. The SPF RR is already

> > here and is preferred over TXT that is generik RR type, unlike SPF.
>

> I don't see any connection with anti-SPF stances. Whether you love or

> despise SPF, the facts (RFC 6686, sections 5 and 6) are that the "SPF"

> record (type 99) is not used at all and that the TXT record is now the
> only one recommended (if you do SPF, which probably means you did not
> believe the FUD).

Which was a total mis-reporting of facts at the time. The current
libraries DO lookup SPF records and fall back to TXT records. New
implementations use SPF records.

This was just a WG that was just plain impatient drawing wrong
conclusions by doing surveys. Then deciding that the was a problem
when there wasn't one at all. That over reacted and in doing so
created even more long term problems that can't correct themselves
over time. Then didn't want to hear that they were impatient and
have overreacted.

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users