Unable to browse from external network in SplitDNS

[Warren Kumari]

On Wed, Mar 18, 2020 at 11:42 PM Purva Rawan <purvar at cdac.in> wrote:
>
> There are three(3) cases as mentioned below.
>
> Case I
> Request from DMZ host(SNat to 172.28.0.2) to Internal of split DNS(172.28.0.11).
> We are able to NSLOOKUP for "registry.npmjs.org".
> We are able to wget/browse "https://registry.npmjs.org"
>
> So, No issues in this.
>
>
> Case II
> Request from DMZ host(SNat to 196.1.113.242) to Public of split DNS(196.1.113.248).
> We are able to NSLOOKUP for "registry.npmjs.org".
> We are NOT able to wget/browse "https://registry.npmjs.org"
>
> So, this we want to fix.


So, you can resolve "registry.npmjs.org" to an IP address, but you
cannot connect to that IP? This is clearly not a DNS issue...


>
> Observation: In the TCP dump on the interface with IP address "196.1.113.248", we see that the DMZ host is trying to re-transmitting SYN packets to DNS server multiple times.
> We cannot do telnet(TCP) from DMZ host to 196.1.113.248 and thats the expected behaviour.


"You are unable to telnet from DMZ host to 196.1.113.248" (expected)
or "You are unable to telnet from DMZ host to 196.1.113.248 port 53" -
this is not expected.
See https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-05
- TCP is required to make DNS work.


>
> The question is why it is switching from UDP to TCP while we try to wget/browse and not the same is happening in Case I.
>
>
> Case III
> Executed for Troubleshooting.
>
> Request from DMZ host(SNat to 196.1.113.242) to Google DNS(8.8.8.8).
> We are able to do NSLOOKUP for "registry.npmjs.org".
> We are able to wget/browse "https://registry.npmjs.org"
>
> So, No issues in this.
>
>
> Hope the above gives more insight into the issue.
>
>
>
> Regards,
>
> Purva Rawan
>
>
> On March 18, 2020 at 7:05 PM Warren Kumari <warren at kumari.net> wrote:
>
>
>
> On Wed, Mar 18, 2020 at 9:03 AM Purva Rawan < purvar at cdac.in> wrote:
>
> Hello ,
>
> We have configured splitDNS .Bind version is 9.9.2.We are able to lookup and browse to particular URL( e.g.https://registry.npmjs.org) from internal network but the same URL when we tried from external network ,it failed to browse ,but able to do nslookup.We checked tcpdump logs and observed that DNS protocol switched from udp to tcp.
>
> Tcpdump logs for reference
>
> 17:39:28.380918 ARP, Request who-has 196.1.113.242 tell 196.1.113.248, length 28
>
> 17:39:28.381205 ARP, Reply 196.1.113.242 is-at 00:09:0f:09:00:1a, length 46
>
> 17:39:30.395995 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2512104 ecr 0,nop,wscale 7], length 0
>
> 17:39:38.420575 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2520128 ecr 0,nop,wscale 7], length 0
>
> 17:39:54.451991 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2536160 ecr 0,nop,wscale 7], length 0
>
> 17:40:26.483591 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2568192 ecr 0,nop,wscale 7], length 0
>
> Kindly help to resolve the same.
>
> You appear to have network / firewall, not DNS issues -- 196.1.113.242 is sending SYN (open a connection) packets to  ns1.cdac.in, but is not getting any reply packets from it (assuming you included all of the tcpdump output) - this either means that  ns1.cdac.in was down, or, more likely, that 196.1.113.242 cannot send packets to it on port 53.
> As a quick and dirty test, can you telnet from 196.1.113.242 to port 53 on 196.1.113.248?
>
> W
>
>
>
> Regards,
>
> Purva Rawan
>
>
>
>
> ------------------------------------------------------------------------------------------------------------
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> ------------------------------------------------------------------------------------------------------------
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
>
>
>
>
>
>
> ------------------------------------------------------------------------------------------------------------
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> ------------------------------------------------------------------------------------------------------------



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf