Re: 9.2 DNS Confusion

[Pascal Hambourg]

Le 26/11/2017 à 16:17, Simon Slaytor a écrit :


Gai.conf, didn't suggest this did disable IPv6 I just replied to a 
suggestion by another.


I did not say you suggested this. I replied below Dan's Ritter quote, 
meaning that I replied to it and to him, not you. Juste as I am now 
replying the the above quote. This is called interleaved quoting.


I've used various ways to disable IPv6 the GRUB 
amendment you mention is one, resolver issue appeared to still exist for 
me but I will check.


Adding ipv6.disable=1 to the kernel command line should prevent the 
resolver to send DNS queries for  records. I just tested it.
Check that the parameter is properly applied, both in /proc/cmdline and 
/sys/module/ipv6/parameters/disable.


Did you also try the resolv.conf tricks I also suggested ? If one works, 
it would be less invasive than disabling IPv6. However if your 
resolv.conf is dynamically created by dhclient or NetworkManager, you 
may need the help of resolvconf to make the setting persistent.


Forcing IPv4 is all well and good but not a workable solution on an app 
by app basis


Right. I suspected that ping was not the only affected program.

Re[2]: 9.2 DNS Confusion

[Simon Slaytor]

Hi Pascal,

Surprised, no not really.

Broken DNS, yes as I say not assigning blame anywhere but yes it's the 
Juniper and given I can do squat about that lets move on to another 
solution :)


Gai.conf, didn't suggest this did disable IPv6 I just replied to a 
suggestion by another. I've used various ways to disable IPv6 the GRUB 
amendment you mention is one, resolver issue appeared to still exist for 
me but I will check.


Forcing IPv4 is all well and good but not a workable solution on an app 
by app basis, docker is being a pita for example.


I'm chasing the juniper bunch for a solution in-case there's a magic 
button, but I doubt it.


Centos 7 does not exhibit this behaviour so it does seem to be Debian 
specific


Cheers for the respone

Simon


-- Original Message --
From: "Pascal Hambourg" <pas...@plouf.fr.eu.org>
To: debian-user@lists.debian.org
Sent: 26/11/2017 15:07:52
Subject: Re: 9.2 DNS Confusion


Le 26/11/2017 à 14:23, Simon Slaytor a écrit :


Today I Wiresharked the network and I can what's happening now.

When I don a plain ping www.apple.com the resolver is sending 2x 
requests to the FW's DNS proxy the first for an IPv4 A record and the 
2nd for an IPv6  record!


You sound surprised. That was obvious though.

Note : In previous versions up to Jessie, ping was IPv4 only and there 
was a separate ping6 executable for IPv6. Since Stretch, ping and ping6 
are now the same executable which is able to do both IPv4 and IPv6. 
When invoked as ping4 or with -4, it does IPv4 only. By default, it 
behaves as most IPv6-capable programs do, asking the resolver for IPv4 
and IPv6 addresses of the target name.


When I specify the -4 flag in PING the resolver sends only 1x request 
which is for the IPv4 A record.


It would seem that the DNS Proxy on my SSG's (SSG140 ScOS 6.3r24) 
doesn't like the  request (rightly so I guess as IPv6 is not 
enabled anywhere!) and returns nothing at all when this request is 
made.


Not rightly. Your DNS proxy is broken. The ability to properly process 
DNS queries for  records has nothing to do with IPv6 connectivity.


So my question changes to 'How do I get the resolver to NOT send the 
 request, simply disabling IPv6 on the box does not prevent this 
behaviour?'


How did you disable IPv6 on the box ?
I did so by appending ipv6.disable=1 to the kernel command line, and it 
actually prevented the resolver to send DNS queries for  records.


This setting totally disables IPv6 features in the kernel and is not 
recommended because it can break some programs which rely on the kernel 
IPv6 features, even though IPv6 connectivity is not available. The 
recommended setting is ipv6.disable_ipv6=1 which disable IPv6 on 
network interfaces but still enables IPv6 features in the kernel. 
However, according to my tests, it does not prevent the resolver to 
send DNS queries for  records.


I have not tested it because I do not have a broken DNS server, but 
there are a couple of options in /etc/resolv.conf which may help 
workaround your DNS proxy brokenness.

See man resolv.conf about single-request and single-request-reopen.

Or you can just use ping -4 or ping4 as you know you don't have any 
IPv6 connectivity.



From: "Dan Ritter" <d...@randomstring.org>
To: "Simon Slaytor" <si...@slaytor.com>
Cc: debian-user@lists.debian.org
Sent: 17/11/2017 16:39:57
Subject: Re: 9.2 DNS Confusion


You can effectively disable IPv6 on a Debian box by editing
/etc/gai.conf and uncommenting the line:

precedence :::0:0/96  100


No, this is far from disabling IPv6. It just gives precedence to IPv4 
addresses over IPv6 addresses. But the resolver still does  record 
lookups and IPv6 addresses are used when no IPv4 address is returned.

Re: 9.2 DNS Confusion

[Pascal Hambourg]

Le 26/11/2017 à 14:23, Simon Slaytor a écrit :


Today I Wiresharked the network and I can what's happening now.

When I don a plain ping www.apple.com the resolver is sending 2x 
requests to the FW's DNS proxy the first for an IPv4 A record and the 
2nd for an IPv6  record!


You sound surprised. That was obvious though.

Note : In previous versions up to Jessie, ping was IPv4 only and there 
was a separate ping6 executable for IPv6. Since Stretch, ping and ping6 
are now the same executable which is able to do both IPv4 and IPv6. When 
invoked as ping4 or with -4, it does IPv4 only. By default, it behaves 
as most IPv6-capable programs do, asking the resolver for IPv4 and IPv6 
addresses of the target name.


When I specify the -4 flag in PING the resolver sends only 1x request 
which is for the IPv4 A record.


It would seem that the DNS Proxy on my SSG's (SSG140 ScOS 6.3r24) 
doesn't like the  request (rightly so I guess as IPv6 is not enabled 
anywhere!) and returns nothing at all when this request is made.


Not rightly. Your DNS proxy is broken. The ability to properly process 
DNS queries for  records has nothing to do with IPv6 connectivity.


So my question changes to 'How do I get the resolver to NOT send the 
 request, simply disabling IPv6 on the box does not prevent this 
behaviour?'


How did you disable IPv6 on the box ?
I did so by appending ipv6.disable=1 to the kernel command line, and it 
actually prevented the resolver to send DNS queries for  records.


This setting totally disables IPv6 features in the kernel and is not 
recommended because it can break some programs which rely on the kernel 
IPv6 features, even though IPv6 connectivity is not available. The 
recommended setting is ipv6.disable_ipv6=1 which disable IPv6 on network 
interfaces but still enables IPv6 features in the kernel. However, 
according to my tests, it does not prevent the resolver to send DNS 
queries for  records.


I have not tested it because I do not have a broken DNS server, but 
there are a couple of options in /etc/resolv.conf which may help 
workaround your DNS proxy brokenness.

See man resolv.conf about single-request and single-request-reopen.

Or you can just use ping -4 or ping4 as you know you don't have any IPv6 
connectivity.



From: "Dan Ritter" <d...@randomstring.org>
To: "Simon Slaytor" <si...@slaytor.com>
Cc: debian-user@lists.debian.org
Sent: 17/11/2017 16:39:57
Subject: Re: 9.2 DNS Confusion


You can effectively disable IPv6 on a Debian box by editing
/etc/gai.conf and uncommenting the line:

precedence :::0:0/96  100


No, this is far from disabling IPv6. It just gives precedence to IPv4 
addresses over IPv6 addresses. But the resolver still does  record 
lookups and IPv6 addresses are used when no IPv4 address is returned.

Re[3]: 9.2 DNS Confusion

[Simon Slaytor]

Ok a small update on this which might help sort my problem.

Today I Wiresharked the network and I can what's happening now.

When I don a plain ping www.apple.com the resolver is sending 2x 
requests to the FW's DNS proxy the first for an IPv4 A record and the 
2nd for an IPv6  record!


When I specify the -4 flag in PING the resolver sends only 1x request 
which is for the IPv4 A record.


It would seem that the DNS Proxy on my SSG's (SSG140 ScOS 6.3r24) 
doesn't like the  request (rightly so I guess as IPv6 is not enabled 
anywhere!) and returns nothing at all when this request is made.


So my question changes to 'How do I get the resolver to NOT send the 
 request, simply disabling IPv6 on the box does not prevent this 
behaviour?'


Cheers

-- Original Message --
From: "Simon Slaytor" <si...@slaytor.com>
To: "Dan Ritter" <d...@randomstring.org>
Cc: debian-user@lists.debian.org
Sent: 18/11/2017 07:39:59
Subject: Re[2]: 9.2 DNS Confusion


Hi Dan,

Yes my thoughts exactly I've tried numerous ways including the gai.conf 
mod to 'disable' IPv6 on 9.2 none seem all that successful in 9.2. e.g.


root@backup:/home/# cat /etc/gai.conf
# Configuration for getaddrinfo(3).
#
...
...
...
#
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence :::0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
precedence :::0:0/96 100

#
# scopev4  
# Add another rule to the RFC 6724 scope table for IPv4 addresses.
...
...
...
#scopev4 :::127.0.0.0/104 2
#scopev4 :::0.0.0.0/96 14

root@backup:/home/# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP 
group default qlen 1000

link/ether ca:57:82:c2:51:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.11.22/24 brd 172.16.11.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::c857:82ff:fec2:51ad/64 scope link
   valid_lft forever preferred_lft forever
root@backup:/home/#

root@backup:/home/# ping www.google.com
ping: www.google.com: Temporary failure in name resolution
root@backup:/home/# ping -4 www.google.com
PING www.google.com (216.58.206.36) 56(84) bytes of data.
64 bytes from 216.58.206.36: icmp_seq=1 ttl=54 time=11.2 ms
64 bytes from 216.58.206.36: icmp_seq=2 ttl=54 time=11.2 ms
64 bytes from 216.58.206.36: icmp_seq=3 ttl=54 time=11.5 ms
64 bytes from 216.58.206.36: icmp_seq=4 ttl=54 time=11.3 ms
64 bytes from 216.58.206.36: icmp_seq=5 ttl=54 time=11.3 ms
^C
--- www.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 11.2

-- Original Message --
From: "Dan Ritter" <d...@randomstring.org>
To: "Simon Slaytor" <si...@slaytor.com>
Cc: debian-user@lists.debian.org
Sent: 17/11/2017 16:39:57
Subject: Re: 9.2 DNS Confusion


On Thu, Nov 16, 2017 at 07:55:18PM +, Simon Slaytor wrote:

Hi Folks,

Long time Debian user and up until now I've not had to reach out for 
help as

I've always found the answer after a short Google.

I've recently made the move from 8.x to 9.2 for my production boxes 
and I'm

having the mother of all DNS issues. My network is simple:

My network
2 x Juniper SSG-140 (Active/Passive) HA 1xTrust 1xDMZ 1xUntrust 
interfaces

IPv4 only IPv6 is not enabled.
2 x Netgear GSM724 Switches

The Junipers do DNS proxying for the Trust and DMZ networks. Junipers 
are in

NAT/Route mode.

Sitting onthe Trust network (172.16.11.0/24) are Debian 8.8 / 9.2 and
Windoze 10 devices.
Sitting in the DMZ network (192.168.102.0/24) are Debian 9.2 and 
Centos 7

devices

My problem is this, after a vanilla 9.2 AMD 64 install DNS resolution 
99

times out of 100 fails unless I force IPv4 for example:

@backup:~$ su
Password:
root@backup:/home/# cat /etc/resolv.conf
domain abc.com
search abc.com.
nameserver 172.16.11.1
root@backup:/home/# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group

default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP 
group

default qlen 1000
link/ether ca:57:82:c2:51:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.11.22/24 brd 172.16.11.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::c857:82ff:fec2:51ad/64 scope link
   valid_lft forever preferred_lft forever
root@backup:/home/# 

Re[2]: 9.2 DNS Confusion

[Simon Slaytor]

Hi Dan,

Yes my thoughts exactly I've tried numerous ways including the gai.conf 
mod to 'disable' IPv6 on 9.2 none seem all that successful in 9.2. e.g.


root@backup:/home/# cat /etc/gai.conf
# Configuration for getaddrinfo(3).
#
...
...
...
#
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence :::0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
precedence :::0:0/96 100

#
# scopev4  
# Add another rule to the RFC 6724 scope table for IPv4 addresses.
...
...
...
#scopev4 :::127.0.0.0/104 2
#scopev4 :::0.0.0.0/96 14

root@backup:/home/# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP 
group default qlen 1000

link/ether ca:57:82:c2:51:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.11.22/24 brd 172.16.11.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::c857:82ff:fec2:51ad/64 scope link
   valid_lft forever preferred_lft forever
root@backup:/home/#

root@backup:/home/# ping www.google.com
ping: www.google.com: Temporary failure in name resolution
root@backup:/home/# ping -4 www.google.com
PING www.google.com (216.58.206.36) 56(84) bytes of data.
64 bytes from 216.58.206.36: icmp_seq=1 ttl=54 time=11.2 ms
64 bytes from 216.58.206.36: icmp_seq=2 ttl=54 time=11.2 ms
64 bytes from 216.58.206.36: icmp_seq=3 ttl=54 time=11.5 ms
64 bytes from 216.58.206.36: icmp_seq=4 ttl=54 time=11.3 ms
64 bytes from 216.58.206.36: icmp_seq=5 ttl=54 time=11.3 ms
^C
--- www.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 11.2

-- Original Message --
From: "Dan Ritter" <d...@randomstring.org>
To: "Simon Slaytor" <si...@slaytor.com>
Cc: debian-user@lists.debian.org
Sent: 17/11/2017 16:39:57
Subject: Re: 9.2 DNS Confusion


On Thu, Nov 16, 2017 at 07:55:18PM +, Simon Slaytor wrote:

Hi Folks,

Long time Debian user and up until now I've not had to reach out for 
help as

I've always found the answer after a short Google.

I've recently made the move from 8.x to 9.2 for my production boxes 
and I'm

having the mother of all DNS issues. My network is simple:

My network
2 x Juniper SSG-140 (Active/Passive) HA 1xTrust 1xDMZ 1xUntrust 
interfaces

IPv4 only IPv6 is not enabled.
2 x Netgear GSM724 Switches

The Junipers do DNS proxying for the Trust and DMZ networks. Junipers 
are in

NAT/Route mode.

Sitting onthe Trust network (172.16.11.0/24) are Debian 8.8 / 9.2 and
Windoze 10 devices.
Sitting in the DMZ network (192.168.102.0/24) are Debian 9.2 and 
Centos 7

devices

My problem is this, after a vanilla 9.2 AMD 64 install DNS resolution 
99

times out of 100 fails unless I force IPv4 for example:

@backup:~$ su
Password:
root@backup:/home/# cat /etc/resolv.conf
domain abc.com
search abc.com.
nameserver 172.16.11.1
root@backup:/home/# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group

default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP 
group

default qlen 1000
link/ether ca:57:82:c2:51:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.11.22/24 brd 172.16.11.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::c857:82ff:fec2:51ad/64 scope link
   valid_lft forever preferred_lft forever
root@backup:/home/# ping www.apple.com
ping: www.apple.com: Temporary failure in name resolution
root@backup:/home/# ping -4 www.apple.com
PING e6858.dsce9.akamaiedge.net (2.18.170.28) 56(84) bytes of data.
64 bytes from 2.18.170.28: icmp_seq=1 ttl=50 time=19.3 ms
64 bytes from 2.18.170.28: icmp_seq=2 ttl=50 time=19.7 ms
^C
--- e6858.dsce9.akamaiedge.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 19.311/19.508/19.705/0.197 ms
root@backup:/home/#

The above box is in the Trust network however the same result occurs 
if I

use a host in the DMZ.

If I however use a Centos 7 box everything works as expected e.g.

[root@loadbalancer ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.102.1
[root@loadbalancer ~]# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft

Re: 9.2 DNS Confusion

[Dan Ritter]

On Thu, Nov 16, 2017 at 07:55:18PM +, Simon Slaytor wrote:
> Hi Folks,
> 
> Long time Debian user and up until now I've not had to reach out for help as
> I've always found the answer after a short Google.
> 
> I've recently made the move from 8.x to 9.2 for my production boxes and I'm
> having the mother of all DNS issues. My network is simple:
> 
> My network
> 2 x Juniper SSG-140 (Active/Passive) HA 1xTrust 1xDMZ 1xUntrust interfaces
> IPv4 only IPv6 is not enabled.
> 2 x Netgear GSM724 Switches
> 
> The Junipers do DNS proxying for the Trust and DMZ networks. Junipers are in
> NAT/Route mode.
> 
> Sitting onthe Trust network (172.16.11.0/24) are Debian 8.8 / 9.2 and
> Windoze 10 devices.
> Sitting in the DMZ network (192.168.102.0/24) are Debian 9.2 and Centos 7
> devices
> 
> My problem is this, after a vanilla 9.2 AMD 64 install DNS resolution 99
> times out of 100 fails unless I force IPv4 for example:
> 
> @backup:~$ su
> Password:
> root@backup:/home/# cat /etc/resolv.conf
> domain abc.com
> search abc.com.
> nameserver 172.16.11.1
> root@backup:/home/# ip ad
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc mq state UP group
> default qlen 1000
> link/ether ca:57:82:c2:51:ad brd ff:ff:ff:ff:ff:ff
> inet 172.16.11.22/24 brd 172.16.11.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::c857:82ff:fec2:51ad/64 scope link
>valid_lft forever preferred_lft forever
> root@backup:/home/# ping www.apple.com
> ping: www.apple.com: Temporary failure in name resolution
> root@backup:/home/# ping -4 www.apple.com
> PING e6858.dsce9.akamaiedge.net (2.18.170.28) 56(84) bytes of data.
> 64 bytes from 2.18.170.28: icmp_seq=1 ttl=50 time=19.3 ms
> 64 bytes from 2.18.170.28: icmp_seq=2 ttl=50 time=19.7 ms
> ^C
> --- e6858.dsce9.akamaiedge.net ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 19.311/19.508/19.705/0.197 ms
> root@backup:/home/#
> 
> The above box is in the Trust network however the same result occurs if I
> use a host in the DMZ.
> 
> If I however use a Centos 7 box everything works as expected e.g.
> 
> [root@loadbalancer ~]# cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 192.168.102.1
> [root@loadbalancer ~]# ip ad
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc mq state UP qlen
> 1000
> link/ether 22:e7:41:55:a6:9c brd ff:ff:ff:ff:ff:ff
> inet 192.168.102.10/24 brd 192.168.102.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::20e7:41ff:fe55:a69c/64 scope link
>valid_lft forever preferred_lft forever
> [root@loadbalancer ~]# ping www.apple.com
> PING e6858.dsce9.akamaiedge.net (2.20.214.243) 56(84) bytes of data.
> 64 bytes from 2.20.214.243 (2.20.214.243): icmp_seq=1 ttl=55 time=28.4 ms
> 64 bytes from 2.20.214.243 (2.20.214.243): icmp_seq=2 ttl=55 time=28.4 ms
> ^C
> --- e6858.dsce9.akamaiedge.net ping statistics ---
> 3 packets transmitted, 2 received, 33% packet loss, time 2002ms
> rtt min/avg/max/mdev = 28.453/28.456/28.459/0.003 ms
> [root@loadbalancer ~]
> 
> Also Windoze 10 boxes running on the Trust network and Debian 8 boxes on
> both have no issues its purely the 9.2 boxes.
> 
> Any help would be much appreciated.

You can effectively disable IPv6 on a Debian box by editing
/etc/gai.conf and uncommenting the line:

precedence :::0:0/96  100

Does that make a difference for you?

-dsr-

9.2 DNS Confusion

[Simon Slaytor]

Hi Folks,

Long time Debian user and up until now I've not had to reach out for 
help as I've always found the answer after a short Google.


I've recently made the move from 8.x to 9.2 for my production boxes and 
I'm having the mother of all DNS issues. My network is simple:


My network
2 x Juniper SSG-140 (Active/Passive) HA 1xTrust 1xDMZ 1xUntrust 
interfaces IPv4 only IPv6 is not enabled.

2 x Netgear GSM724 Switches

The Junipers do DNS proxying for the Trust and DMZ networks. Junipers 
are in NAT/Route mode.


Sitting onthe Trust network (172.16.11.0/24) are Debian 8.8 / 9.2 and 
Windoze 10 devices.
Sitting in the DMZ network (192.168.102.0/24) are Debian 9.2 and Centos 
7 devices


My problem is this, after a vanilla 9.2 AMD 64 install DNS resolution 99 
times out of 100 fails unless I force IPv4 for example:


@backup:~$ su
Password:
root@backup:/home/# cat /etc/resolv.conf
domain abc.com
search abc.com.
nameserver 172.16.11.1
root@backup:/home/# ip ad
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP 
group default qlen 1000

link/ether ca:57:82:c2:51:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.11.22/24 brd 172.16.11.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::c857:82ff:fec2:51ad/64 scope link
   valid_lft forever preferred_lft forever
root@backup:/home/# ping www.apple.com
ping: www.apple.com: Temporary failure in name resolution
root@backup:/home/# ping -4 www.apple.com
PING e6858.dsce9.akamaiedge.net (2.18.170.28) 56(84) bytes of data.
64 bytes from 2.18.170.28: icmp_seq=1 ttl=50 time=19.3 ms
64 bytes from 2.18.170.28: icmp_seq=2 ttl=50 time=19.7 ms
^C
--- e6858.dsce9.akamaiedge.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 19.311/19.508/19.705/0.197 ms
root@backup:/home/#

The above box is in the Trust network however the same result occurs if 
I use a host in the DMZ.


If I however use a Centos 7 box everything works as expected e.g.

[root@loadbalancer ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.102.1
[root@loadbalancer ~]# ip ad
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 
1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP 
qlen 1000

link/ether 22:e7:41:55:a6:9c brd ff:ff:ff:ff:ff:ff
inet 192.168.102.10/24 brd 192.168.102.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::20e7:41ff:fe55:a69c/64 scope link
   valid_lft forever preferred_lft forever
[root@loadbalancer ~]# ping www.apple.com
PING e6858.dsce9.akamaiedge.net (2.20.214.243) 56(84) bytes of data.
64 bytes from 2.20.214.243 (2.20.214.243): icmp_seq=1 ttl=55 time=28.4 
ms
64 bytes from 2.20.214.243 (2.20.214.243): icmp_seq=2 ttl=55 time=28.4 
ms

^C
--- e6858.dsce9.akamaiedge.net ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2002ms
rtt min/avg/max/mdev = 28.453/28.456/28.459/0.003 ms
[root@loadbalancer ~]

Also Windoze 10 boxes running on the Trust network and Debian 8 boxes on 
both have no issues its purely the 9.2 boxes.


Any help would be much appreciated.

Simon