Sorry, when I say "response", I mean a packet is received from the DNS server 
with an ID matching the query.  If the answer section is empty, spamdyke treats 
it as a negative result.  spamdyke only continues querying servers when no 
(matching) packets are received at all.

-- Sam Clippinger




> On Mar 13, 2019, at 2:39 PM, Quinn Comendant <[email protected]> wrote:
> 
> Hi Sam,
> 
> Thanks for the thorough reply. 
> 
> How does spamdyke know "If a response is received, [use it and stop]"? During 
> a NXDOMAIN and SERVFAIL, no "response" is received (the ANSWER section of the 
> DNS response is empty). If the response is empty, doesn't spamdyke then try 
> the next name server? Or, can it detect that a response was received 
> successfully, just empty?
> 
> A setting that rotates between name servers would be very helpful. 
> Spamassassin offers this already with its `dns_options rotate` option. 
> Distributing load between name servers helps them stay within the limits of 
> DNSBL query limits, (i.e., URIBL_BLOCKED).
> 
> Quinn
> 
> 
> On 13 Mar 2019 13:52:11, Sam Clippinger via spamdyke-users wrote:
>> Sorry, I missed your earlier email.  I'll try to answer both questions here.
>> 
>> Unless you're setting spamdyke's dns-level option, it should be using 
>> the primary servers in order, followed by the secondary servers in 
>> order, every time it runs.  If you're just setting the three DNS 
>> servers and not using any other dns-* options, the logic should look 
>> like this:
>>      Total DNS query time is 30 seconds (override with dns-timeout-secs)
>>      Max number of DNS queries to primary servers before using 
>> secondaries is 1 (override with dns-max-retries-primary)
>>      Max number of DNS queries total is 3 (override with 
>> dns-max-retries-total)
>>      Send query packet to 127.0.0.1, wait 10 seconds for a response 
>> (total query time divided by max number of queries)
>>      If a response is received, use it and stop.
>>      Send query packet to 10.128.0.9, wait 10 seconds for a response
>>      If a response is received, use it and stop.
>>      The number of queries to primary servers is greater than 1, start 
>> using secondaries as well
>>      Send query packet to 169.254.169.254, wait 10 seconds for a response
>>      If a response is received, use it.  Otherwise exit with no response.
>> Randomizing the order of the servers would probably be a good idea 
>> (or option).... I think I didn't do that because I was trying to 
>> imitate the behavior of the system resolver library, which uses the 
>> servers in /etc/resolv.conf in order every time.
>> 
>> Looking at the code in dns.c, spamdyke treats an empty response as 
>> "not found" and doesn't check whether it was due to SERVFAIL or 
>> NXDOMAIN.  If memory serves, I did this because there's no real 
>> difference between them as far as spamdyke is concerned.  In other 
>> words, NXDOMAIN means the domain doesn't exist at all while SERVFAIL 
>> means the domain exists but no records can be found (usually because 
>> the authoritative servers aren't responding).  Either way, the mail 
>> should be rejected with a temporary code so the sender will try again 
>> later (hoping the problem will resolve itself in the meantime).  If 
>> the problem persists long enough, the message(s) may bounce.  
>> Unfortunately there's no DNS code to indicate the server is 
>> malfunctioning and shouldn't be used -- spamdyke expects it to stop 
>> sending responses when that happens.
>> 
>> 
>> -- Sam Clippinger
>> 
>> 
>> 
>> 
>>> On Mar 11, 2019, at 6:58 PM, Quinn Comendant via spamdyke-users 
>>> <[email protected]> wrote:
>>> 
>>> We had an incident where both our local caching name servers stopped 
>>> working. They returned SERVFAIL (see example below). They were set 
>>> as the "dns-server-ip-primary" and our host-provided DNS server was 
>>> set as the "dns-server-ip". Because the primaries were failing, I 
>>> would expect spamdyke to automatically switch to resolve via the 
>>> server set under "dns-server-ip". Instead, spamdyke just rejected 
>>> all our mail for a few hours with DENIED_RDNS_MISSING. The 
>>> host-provide name server was functioning fine.
>>> 
>>> This is the config:
>>> 
>>>   dns-server-ip-primary=127.0.0.1    # Local caching name server
>>>   dns-server-ip-primary=10.128.0.9 # Another local caching name server
>>>   dns-server-ip=169.254.169.254    # Host-provided name server
>>> 
>>> This is an example response from a query to either of the primary 
>>> DNS servers:
>>> 
>>>   {q@oak3~} dig @10.128.0.9 apple.com mx
>>> 
>>>   ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 <<>> 
>>> @10.128.0.9 apple.com mx
>>>   ; (1 server found)
>>>   ;; global options: +cmd
>>>   ;; Got answer:
>>>   ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52266
>>>   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>> 
>>>   ;; QUESTION SECTION:
>>>   ;apple.com.                     IN      MX
>>> 
>>>   ;; Query time: 15 msec
>>>   ;; SERVER: 10.128.0.9#53(10.128.0.9)
>>>   ;; WHEN: Mon Mar 11 05:10:32 2019
>>>   ;; MSG SIZE  rcvd: 27
>>> 
>>> Am I wrong to expect spamdyke to fail over to the non-primary server 
>>> on a SERVFAIL?
>>> 
>>> Quinn
>>> _______________________________________________
>>> spamdyke-users mailing list
>>> [email protected]
>>> https://spamdyke.org/mailman/listinfo/spamdyke-users
>> 
>> _______________________________________________
>> spamdyke-users mailing list
>> [email protected]
>> https://spamdyke.org/mailman/listinfo/spamdyke-users

_______________________________________________
spamdyke-users mailing list
[email protected]
https://spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to