Re: SPF records and DKIM signatures on ubuntu/postfix/mailman

On 15/10/11 00:46, Volker Kuhlmann wrote:
> On Fri 14 Oct 2011 20:27:09 NZDT +1300, Mark Foster wrote:
>
>> As far as the world is concerned the IP you're on does _not_ have a
>> valid forward/reverse pair, based on the headers of the last message you
>> sent to the list anyway.
> Yes, so I figured. TCL is going steadily downhill. Beats me how they
> manage to be ISP of the year all the time.

+1. Was glad to move away from them to be honest. I had cable when I was
in Wellington for a while.


>
>> The fact it works inside of TCL only is actually broken, and I'd suggest
>> that you raise it with TCL.
> Do they still care? I'd put more effort in if it had a tangible benefit
> for me, but sending email directly without relaying through the ISP
> stopped working years ago.

If you raise it with them, it's their job to care.  Failure to have a
matching pair can make connections to FTP and SSH servers take a while
to validate you as they try to verify your DNS, for example.

>
>> Checking your DNS works outside of the authoritive/hosting server is
>> something that you should always do anyway, if the means presents.  Many
>> ISPs are now blocking external lookups for security reasons, 
> For servers that send mail - certainly, for domestic cable Internet use
> it's not so critical. What do you mean by "blocking external lookups"?
> External DNS lookups? Blocked, or redirected to their own DNS resolver?
> I have no indication that that is the case with TCL. Web cache yes to
> varying levels of transparency, but DNS?
>

Think of it like SMTP.
There's essentially two types of DNS servers

1) Resolvers of ISP X that're set up so that clients of ISP X can point
DNS lookups at them; they then reach out to the world for information on
the domains you wish to connect to.

2) Authoritive DNS servers which host domain names.

Best practise is not to have 1) and 2) on the same machines, but it's
been known to happen.

As an ISP it's quite appropriate for you to set up the configuration of
1) above so that if the DNS lookup comes from outside of your own
local/trusted IP space, the lookup fails.  This was commonly done when
the major DNS response vulnerability came up a coupla years ago[1], to
reduce the threat vector.  It also reduces the load on ISP DNS servers
from people who aren't paying customers. (How many people hardcoded
Xtra's DNS servers into their workstations, then changed ISP's and
continued to use Xtra's machines for lookups?)

Obviously you can't restrict the Authoritive DNS servers - as then
people wont be able to look up DNS for stuff you host.  But there's no
reason that an ISP needs to operate resolvers that're open to folks
other than their own customers.

I mentioned this because these policies can make it hard to externally
test DNS.  For example I know Orcon's DNS platform rejects queries from
outside:

blakjak@hawkeye:~$ dig blakjak.net mx @ns1.orcon.net.nz

; <<>> DiG 9.7.1-P2 <<>> blakjak.net mx @ns1.orcon.net.nz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 50276
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

(i'm not an Orcon customer).

Mark.

[1]
http://www.secureworks.com/research/articles/other_articles/dns-cache-poisoning/

_______________________________________________
NZLUG mailing list [email protected]
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug