[SOLVED] My Exchange server is now able to send email to httpd.apache.org domain after I added SPF TXT record to my DNS server
Good morning from Singapore, Previously the mail server at httpd.apache.org domain rejected all of my emails. I have solved the problem by adding the following Sender Policy Framework (SPF) text (TXT) record to my DNS server: teo-en-ming.com. IN TXT "v=spf1 mx -all" Now my Exchange server is finally able to send emails to the httpd.apache.org domain. Am I an excellent troubleshooter? However, the mail server at freebsd.org is still rejecting my emails. Adding SPF TXT record did not solve the problem for this domain (freebsd.org). Perhaps I need to configure DKIM as well? I have no idea what is DKIM. Please help me to troubleshoot email delivery failure for the freebsd.org domain. Thank you very much. ===BEGIN SIGNATURE=== Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 [1] https://tdtemcerts.wordpress.com/ [2] http://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming ===END SIGNATURE=== ___ 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: Need help on RPZ sever, bit urgent
I don't know what else to check. If possible, I would avoid forwarding by
putting both functions on the same server. You could turn on BIND
debugging - Cricket's "DNS and BIND" book has a chapter on debugging - but
that could be a lot of work.
--
Bob Harold
On Mon, Aug 13, 2018 at 10:58 AM Blason R wrote:
> Its there!!!
>
> On Mon, Aug 13, 2018 at 6:58 PM Bob Harold wrote:
>
>>
>>
>> --
>> Bob Harold
>> hostmaster, UMnet, ITcom
>> Information and Technology Services (ITS)
>> rharo...@umich.edu
>> 734-647-6524 desk
>>
>>
>> On Sun, Aug 12, 2018 at 2:38 AM Blason R wrote:
>>
>>> Hi Bob,
>>>
>>> I guess my scenario is not exactly understood I believe. Before that if
>>> I have set forwarder in Global option then ideally BIND should forward all
>>> queries to the forwarder, right?
>>>
>>> Lets say 192.168.3.15 is client
>>> 192.168.3.42 is BIND Server
>>> 192.168.3.78 is RPZ server
>>>
>>> I have one zone on 192.168.3.42 by name test.com and have all the
>>> entries on 192.168.3.42, so on users desktop 192.168.3.15 I have DNS
>>> configured as 192.168.3.42.
>>>
>>
>> Make sure 3.42 has in the global options:
>> forward only;
>> forwarders { 192.168.3.78; };
>>
>> If you are missing the "forward only;" then bind will try to forward, but
>> if it does not get a quick answer it will try to resolve itself.
>>
>> --
>> Bob Harold
>>
>>
>>> So,
>>>
>>> When query goes for ftp.test.com it will be resolved by 192.168.3.42
>>> When query goes for bad.malware.com. it will be forwarded 192.168.3.78
>>> where it will be wall-gardened.
>>>
>>> Now what I noticed is certain RPZ entries on 3.78 are not getting
>>> resolved from 192.168.3.15. And then I observed that certain .com entries
>>> 3.42 is trying resolve on his own even though he is not authoritative
>>> server and supposedly those ALL queries should have been forwarded to
>>> 192.168.3.78.
>>>
>>> PS: I guess there are certain folks are on list from commercial RPZ
>>> services, are they facing same issue?
>>>
>>> On Sun, Aug 12, 2018 at 10:12 AM Bob Harold wrote:
>>>
On Fri, Aug 10, 2018 at 10:53 PM Blason R wrote:
> Infact what I observed that the intermediate DNS servers are not
> forwarding he queries for .com and .net servers to my RPZ servers and it
> tries resolves directly on his own from TLD servers
>
You need to work on the intermediate server to get it to forward. If
it is running Microsoft DNS, then I don't know enough to help you with
that.
I would suggest that you have the RPZ server be a 'slave' for the '
test.com' zone (and all the zones that the AUTH server has). Then
point users directly at the RPZ server.
--
Bob Harold
> 192.168.3.72 End User
> 192.168.3.15 [AUTH Server for test.com] and has forwarder to
> 192.168.3.44 [RPZ]
>
> So, 3.15 should only resolve for test.com else all queries should be
> forwarded to 192.168.3.44
>
> *Which is not happening.*
>
> dig 003bbhq9.com
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;003bbhq9.com. IN A
>
> *;; AUTHORITY SECTION:*
> *com.530 IN SOA a.gtld-servers.net
> . nstld.verisign-grs.com
> . 1533954938 1800 900 604800 86400*
>
> ;; Query time: 0 msec
> ;; SERVER: 192.168.3.15#53(192.168.3.15)
> ;; WHEN: Sat Aug 11 08:12:17 IST 2018
> ;; MSG SIZE rcvd: 114
>
>
> On Sat, Aug 11, 2018 at 7:57 AM Blason R wrote:
>
>> Ok - Now I added like this and it disappeared.
>>
>> response-policy { zone "whitelist.allow" policy passthru;
>> zone "malware.trap";
>> zone "ransomwareips.block"; }
>> qname-wait-recurse no break-dnssec no;
>>
>>
>> On Sat, Aug 11, 2018 at 7:51 AM Blason R wrote:
>>
>>> This is not accepting and giving my syntax error.
>>>
>>> named-checkconf /etc/bind/named.conf
>>> /etc/bind/named.conf.options:29: syntax error near '}'
>>>
>>>
>>> And here is I added
>>>
>>> response-policy { zone "whitelist.allow" policy passthru;
>>> zone "malware.trap";
>>> zone "ransomwareips.block"; }
>>> qname-wait-recurse no break-dnssec no; };
>>>
>>>
>>>
>>> On Sat, Aug 11, 2018 at 1:17 AM Carl Byington
>>> wrote:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2018-08-10 at 13:17 +0530, Blason R wrote:
>>
Re: Need help on RPZ sever, bit urgent
Its there!!!
On Mon, Aug 13, 2018 at 6:58 PM Bob Harold wrote:
>
>
> --
> Bob Harold
> hostmaster, UMnet, ITcom
> Information and Technology Services (ITS)
> rharo...@umich.edu
> 734-647-6524 desk
>
>
> On Sun, Aug 12, 2018 at 2:38 AM Blason R wrote:
>
>> Hi Bob,
>>
>> I guess my scenario is not exactly understood I believe. Before that if I
>> have set forwarder in Global option then ideally BIND should forward all
>> queries to the forwarder, right?
>>
>> Lets say 192.168.3.15 is client
>> 192.168.3.42 is BIND Server
>> 192.168.3.78 is RPZ server
>>
>> I have one zone on 192.168.3.42 by name test.com and have all the
>> entries on 192.168.3.42, so on users desktop 192.168.3.15 I have DNS
>> configured as 192.168.3.42.
>>
>
> Make sure 3.42 has in the global options:
> forward only;
> forwarders { 192.168.3.78; };
>
> If you are missing the "forward only;" then bind will try to forward, but
> if it does not get a quick answer it will try to resolve itself.
>
> --
> Bob Harold
>
>
>> So,
>>
>> When query goes for ftp.test.com it will be resolved by 192.168.3.42
>> When query goes for bad.malware.com. it will be forwarded 192.168.3.78
>> where it will be wall-gardened.
>>
>> Now what I noticed is certain RPZ entries on 3.78 are not getting
>> resolved from 192.168.3.15. And then I observed that certain .com entries
>> 3.42 is trying resolve on his own even though he is not authoritative
>> server and supposedly those ALL queries should have been forwarded to
>> 192.168.3.78.
>>
>> PS: I guess there are certain folks are on list from commercial RPZ
>> services, are they facing same issue?
>>
>> On Sun, Aug 12, 2018 at 10:12 AM Bob Harold wrote:
>>
>>>
>>> On Fri, Aug 10, 2018 at 10:53 PM Blason R wrote:
>>>
Infact what I observed that the intermediate DNS servers are not
forwarding he queries for .com and .net servers to my RPZ servers and it
tries resolves directly on his own from TLD servers
>>>
>>> You need to work on the intermediate server to get it to forward. If it
>>> is running Microsoft DNS, then I don't know enough to help you with that.
>>>
>>> I would suggest that you have the RPZ server be a 'slave' for the '
>>> test.com' zone (and all the zones that the AUTH server has). Then
>>> point users directly at the RPZ server.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>>
192.168.3.72 End User
192.168.3.15 [AUTH Server for test.com] and has forwarder to
192.168.3.44 [RPZ]
So, 3.15 should only resolve for test.com else all queries should be
forwarded to 192.168.3.44
*Which is not happening.*
dig 003bbhq9.com
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;003bbhq9.com. IN A
*;; AUTHORITY SECTION:*
*com.530 IN SOA a.gtld-servers.net
. nstld.verisign-grs.com
. 1533954938 1800 900 604800 86400*
;; Query time: 0 msec
;; SERVER: 192.168.3.15#53(192.168.3.15)
;; WHEN: Sat Aug 11 08:12:17 IST 2018
;; MSG SIZE rcvd: 114
On Sat, Aug 11, 2018 at 7:57 AM Blason R wrote:
> Ok - Now I added like this and it disappeared.
>
> response-policy { zone "whitelist.allow" policy passthru;
> zone "malware.trap";
> zone "ransomwareips.block"; }
> qname-wait-recurse no break-dnssec no;
>
>
> On Sat, Aug 11, 2018 at 7:51 AM Blason R wrote:
>
>> This is not accepting and giving my syntax error.
>>
>> named-checkconf /etc/bind/named.conf
>> /etc/bind/named.conf.options:29: syntax error near '}'
>>
>>
>> And here is I added
>>
>> response-policy { zone "whitelist.allow" policy passthru;
>> zone "malware.trap";
>> zone "ransomwareips.block"; }
>> qname-wait-recurse no break-dnssec no; };
>>
>>
>>
>> On Sat, Aug 11, 2018 at 1:17 AM Carl Byington
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On Fri, 2018-08-10 at 13:17 +0530, Blason R wrote:
>>> > Nah I dont think that is the answer since you need a termination
>>> after
>>> > clause.
>>>
>>> Did you actually try the answer below?
>>>
>>>
>>> > On Fri, Aug 10, 2018 at 12:58 PM Vadim Pavlov
>>> wrote:
>>>
>>> > Should be:
>>>
>>>
>>> > response-policy {zone "whitelist.allow" policy passthru;
>>> > zone "malware.trap";
>>> >
Re: Need help on RPZ sever, bit urgent
--
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharo...@umich.edu
734-647-6524 desk
On Sun, Aug 12, 2018 at 2:38 AM Blason R wrote:
> Hi Bob,
>
> I guess my scenario is not exactly understood I believe. Before that if I
> have set forwarder in Global option then ideally BIND should forward all
> queries to the forwarder, right?
>
> Lets say 192.168.3.15 is client
> 192.168.3.42 is BIND Server
> 192.168.3.78 is RPZ server
>
> I have one zone on 192.168.3.42 by name test.com and have all the entries
> on 192.168.3.42, so on users desktop 192.168.3.15 I have DNS configured as
> 192.168.3.42.
>
Make sure 3.42 has in the global options:
forward only;
forwarders { 192.168.3.78; };
If you are missing the "forward only;" then bind will try to forward, but
if it does not get a quick answer it will try to resolve itself.
--
Bob Harold
> So,
>
> When query goes for ftp.test.com it will be resolved by 192.168.3.42
> When query goes for bad.malware.com. it will be forwarded 192.168.3.78
> where it will be wall-gardened.
>
> Now what I noticed is certain RPZ entries on 3.78 are not getting resolved
> from 192.168.3.15. And then I observed that certain .com entries 3.42 is
> trying resolve on his own even though he is not authoritative server and
> supposedly those ALL queries should have been forwarded to 192.168.3.78.
>
> PS: I guess there are certain folks are on list from commercial RPZ
> services, are they facing same issue?
>
> On Sun, Aug 12, 2018 at 10:12 AM Bob Harold wrote:
>
>>
>> On Fri, Aug 10, 2018 at 10:53 PM Blason R wrote:
>>
>>> Infact what I observed that the intermediate DNS servers are not
>>> forwarding he queries for .com and .net servers to my RPZ servers and it
>>> tries resolves directly on his own from TLD servers
>>>
>>
>> You need to work on the intermediate server to get it to forward. If it
>> is running Microsoft DNS, then I don't know enough to help you with that.
>>
>> I would suggest that you have the RPZ server be a 'slave' for the '
>> test.com' zone (and all the zones that the AUTH server has). Then point
>> users directly at the RPZ server.
>>
>> --
>> Bob Harold
>>
>>
>>
>>> 192.168.3.72 End User
>>> 192.168.3.15 [AUTH Server for test.com] and has forwarder to
>>> 192.168.3.44 [RPZ]
>>>
>>> So, 3.15 should only resolve for test.com else all queries should be
>>> forwarded to 192.168.3.44
>>>
>>> *Which is not happening.*
>>>
>>> dig 003bbhq9.com
>>>
>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;003bbhq9.com. IN A
>>>
>>> *;; AUTHORITY SECTION:*
>>> *com.530 IN SOA a.gtld-servers.net
>>> . nstld.verisign-grs.com
>>> . 1533954938 1800 900 604800 86400*
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: 192.168.3.15#53(192.168.3.15)
>>> ;; WHEN: Sat Aug 11 08:12:17 IST 2018
>>> ;; MSG SIZE rcvd: 114
>>>
>>>
>>> On Sat, Aug 11, 2018 at 7:57 AM Blason R wrote:
>>>
Ok - Now I added like this and it disappeared.
response-policy { zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block"; }
qname-wait-recurse no break-dnssec no;
On Sat, Aug 11, 2018 at 7:51 AM Blason R wrote:
> This is not accepting and giving my syntax error.
>
> named-checkconf /etc/bind/named.conf
> /etc/bind/named.conf.options:29: syntax error near '}'
>
>
> And here is I added
>
> response-policy { zone "whitelist.allow" policy passthru;
> zone "malware.trap";
> zone "ransomwareips.block"; }
> qname-wait-recurse no break-dnssec no; };
>
>
>
> On Sat, Aug 11, 2018 at 1:17 AM Carl Byington
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On Fri, 2018-08-10 at 13:17 +0530, Blason R wrote:
>> > Nah I dont think that is the answer since you need a termination
>> after
>> > clause.
>>
>> Did you actually try the answer below?
>>
>>
>> > On Fri, Aug 10, 2018 at 12:58 PM Vadim Pavlov
>> wrote:
>>
>> > Should be:
>>
>>
>> > response-policy {zone "whitelist.allow" policy passthru;
>> > zone "malware.trap";
>> > zone "ransomwareips.block";
>> > } qname-wait-recurse no break-dnssec no;
>>
>>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this li
