[MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet

[Sam Trenholme]

Thank you so much for this information.  Since Deadwood also, by
default, drops replies with RFC1918 addresses in it, when I add a FAQ
about RFC1918 addresses to Deadwood later on this week or this
weekend, I will add a link to your ServerFault posting telling people
that routers sometimes also drop RFC1918 addresses.

- Sam

On Mon, Jun 17, 2013 at 1:53 PM, Dave Owens <dave at teamunify.com> wrote:
> Hi Sam et. al,
>
> Wanted to share how this turned out:
>
> http://serverfault.com/questions/513608/maradns-does-not-respond-to-a-record-queries-of-locally-connected-rfc1918-addres/516464#516464
>
> Moral of the story is:  "Capture traffic early, capture traffic often."
>  Especially when NAT is involved :-)
>
> Thanks to everyone for listening.  Very happy to learn that MaraDNS is not
> the culprit.
>
> Dave Owens
> TeamUnify, LLC
>
>
>
>
>
> On Fri, Jun 14, 2013 at 2:12 PM, Dave Owens <dave at teamunify.com> wrote:
>
>> Hi Sam,
>>
>> I tried this with your lightweight DNS server, on a different machine
>> (same route), still no luck.  Testing a non-connected rfc1918 returns a
>> response, testing a connected rfc1918 address does not work.
>>
>> An enhanced packet capture shows that when the reply for the 'special' A
>> record is sent to the router, the router replies with an
>> icmp-host-unreachable packet indicating the that the destination IP is
>> unreachable.... I must be hitting a bug or possibly hidden configuration in
>> the router OS.
>>
>> Attached is a .pcapng file that illustrates the behavior... first request
>> succeeds, subsequent three requests fail.
>>
>>  Dave Owens
>> TeamUnify, LLC
>>
>>
>>
>>
>>
>> On Fri, Jun 14, 2013 at 11:13 AM, Sam Trenholme <maradns at gmail.com> wrote:
>>
>>> > Yesterday I ran captures both on our DNS node (it indeed sends the
>>> reply)
>>> > and on the other side of our edge router (no reply is seen).  Our colo
>>> > provider says they aren't doing any deep packet inspection around
>>> this...
>>>
>>> I want to know how this gets resolved--so I can add this information
>>> to the MaraDNS FAQ (which is horribly outdated and needs a serious
>>> revamp).  There is a small chance it’s a case of “MaraDNS makes a
>>> weird DNS packet which this route doesn’t like”. One way to normalize
>>> against that is to have another computer whose packets go through the
>>> same route use a different DNS server to send out the 192.168.50.141
>>> DNS reply.
>>>
>>> For example, here’s a DNS server I wrote a few years ago:
>>>
>>> $ cat > nanodns.c
>>> /*Placed in the public domain by Sam Trenholme*/
>>> #include <arpa/inet.h>
>>> #include <string.h>
>>> #include <stdint.h>
>>> #define Z struct sockaddr
>>> #define Y sizeof(d)
>>> int main(int a,char **b){uint32_t i;char q[512]
>>> ,p[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>
>>> 1){struct sockaddr_in d;socklen_t f=511;bzero(&
>>> d,Y);a=socket(AF_INET,SOCK_DGRAM,0);*((uint32_t
>>> *)(p+12))=inet_addr(b[1]);d.sin_family=AF_INET;
>>> d.sin_port=htons(53);bind(a,(Z*)&d,Y);for(;;){i
>>> =recvfrom(a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0)
>>> {q[2]|=128;q[11]?q[3]|=4:1;q[7]++;memcpy(q+i,p,
>>> 16);sendto(a,q,i+16,0,(Z*)&d,Y);}}}return 0;}
>>> // Hit control-D to end this file here
>>> $ gcc -g -O nanodns nanodns.c
>>> $ su
>>> Password:
>>> # ./nanodns 192.168.50.141
>>>
>>> At this point, the machine is running a tiny little DNS server which
>>> will reply to all DNS queries with the IP 192.168.50.141.
>>>
>>> I have a more readable version of that DNS server here:
>>>
>>> http://samiam.org/software/microdns.html
>>>
>>> - Sam
>>>
>>
>>