Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #189044 > unrolled thread

9.2 DNS Confusion

Back to article view | Back to linux.debian.user

Contents

  9.2 DNS Confusion "Simon Slaytor" <simon@slaytor.com> - 2017-11-16 21:10 +0100
    Re: 9.2 DNS Confusion Dan Ritter <dsr@randomstring.org> - 2017-11-17 17:50 +0100
      Re[2]: 9.2 DNS Confusion "Simon Slaytor" <simon@slaytor.com> - 2017-11-18 08:50 +0100
        Re[3]: 9.2 DNS Confusion "Simon Slaytor" <simon@slaytor.com> - 2017-11-26 14:30 +0100
          Re: 9.2 DNS Confusion Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-11-26 16:10 +0100
            Re[2]: 9.2 DNS Confusion "Simon Slaytor" <simon@slaytor.com> - 2017-11-26 16:20 +0100
              Re: 9.2 DNS Confusion Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-11-26 16:50 +0100

#189044 — 9.2 DNS Confusion

[Multipart message — attachments visible in raw view] — view raw

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:

xxxx@backup:~$ su
Password:
root@backup:/home/xxxx# cat /etc/resolv.conf
domain abc.com
search abc.com.
nameserver 172.16.11.1
root@backup:/home/xxxx# 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/xxxx# ping www.apple.com
ping: www.apple.com: Temporary failure in name resolution
root@backup:/home/xxxx# 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/xxxx#

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 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 
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

[toc] | [next] | [standalone]

#189080

On Thu, Nov 16, 2017 at 07:55:18PM +0000, 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:
> 
> xxxx@backup:~$ su
> Password:
> root@backup:/home/xxxx# cat /etc/resolv.conf
> domain abc.com
> search abc.com.
> nameserver 172.16.11.1
> root@backup:/home/xxxx# 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/xxxx# ping www.apple.com
> ping: www.apple.com: Temporary failure in name resolution
> root@backup:/home/xxxx# 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/xxxx#
> 
> 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 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 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 ::ffff:0:0/96  100

Does that make a difference for you?

-dsr-

[toc] | [prev] | [next] | [standalone]

#189103

[Multipart message — attachments visible in raw view] — view raw

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/xxxx# cat /etc/gai.conf
# Configuration for getaddrinfo(3).
#
...
...
...
#
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence ::ffff:0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96 100

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

root@backup:/home/xxxx# 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/xxxx#

root@backup:/home/xxxx# ping www.google.com
ping: www.google.com: Temporary failure in name resolution
root@backup:/home/xxxx# 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" <dsr@randomstring.org>
To: "Simon Slaytor" <simon@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 +0000, 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:
>>
>>xxxx@backup:~$ su
>>Password:
>>root@backup:/home/xxxx# cat /etc/resolv.conf
>>domain abc.com
>>search abc.com.
>>nameserver 172.16.11.1
>>root@backup:/home/xxxx# 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/xxxx# ping www.apple.com
>>ping: www.apple.com: Temporary failure in name resolution
>>root@backup:/home/xxxx# 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/xxxx#
>>
>>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 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 
>>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 ::ffff:0:0/96  100
>
>Does that make a difference for you?
>
>-dsr-
>
>

[toc] | [prev] | [next] | [standalone]

#189301

[Multipart message — attachments visible in raw view] — view raw

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 AAAA 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 AAAA 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 
AAAA request, simply disabling IPv6 on the box does not prevent this 
behaviour?'

Cheers

------ Original Message ------
From: "Simon Slaytor" <simon@slaytor.com>
To: "Dan Ritter" <dsr@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/xxxx# cat /etc/gai.conf
># Configuration for getaddrinfo(3).
>#
>...
>...
>...
>#
>#precedence ::1/128 50
>#precedence ::/0 40
>#precedence 2002::/16 30
>#precedence ::/96 20
>#precedence ::ffff:0:0/96 10
>#
># For sites which prefer IPv4 connections change the last line to
>#
>precedence ::ffff:0:0/96 100
>
>#
># scopev4 <mask> <value>
># Add another rule to the RFC 6724 scope table for IPv4 addresses.
>...
>...
>...
>#scopev4 ::ffff:127.0.0.0/104 2
>#scopev4 ::ffff:0.0.0.0/96 14
>
>root@backup:/home/xxxx# 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/xxxx#
>
>root@backup:/home/xxxx# ping www.google.com
>ping: www.google.com: Temporary failure in name resolution
>root@backup:/home/xxxx# 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" <dsr@randomstring.org>
>To: "Simon Slaytor" <simon@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 +0000, 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:
>>>
>>>xxxx@backup:~$ su
>>>Password:
>>>root@backup:/home/xxxx# cat /etc/resolv.conf
>>>domain abc.com
>>>search abc.com.
>>>nameserver 172.16.11.1
>>>root@backup:/home/xxxx# 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/xxxx# ping www.apple.com
>>>ping: www.apple.com: Temporary failure in name resolution
>>>root@backup:/home/xxxx# 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/xxxx#
>>>
>>>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 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 
>>>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 ::ffff:0:0/96  100
>>
>>Does that make a difference for you?
>>
>>-dsr-
>>
>>

[toc] | [prev] | [next] | [standalone]

#189306

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 AAAA 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 AAAA 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 AAAA records has nothing to do with IPv6 connectivity.

> So my question changes to 'How do I get the resolver to NOT send the 
> AAAA 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 AAAA 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 AAAA 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" <dsr@randomstring.org>
>> To: "Simon Slaytor" <simon@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 ::ffff: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 AAAA record 
lookups and IPv6 addresses are used when no IPv4 address is returned.

[toc] | [prev] | [next] | [standalone]

#189307

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" <pascal@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 AAAA 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 AAAA 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 AAAA records has nothing to do with IPv6 connectivity.
>
>>So my question changes to 'How do I get the resolver to NOT send the 
>>AAAA 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 AAAA 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 AAAA 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" <dsr@randomstring.org>
>>>To: "Simon Slaytor" <simon@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 ::ffff: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 AAAA record 
>lookups and IPv6 addresses are used when no IPv4 address is returned.
>

[toc] | [prev] | [next] | [standalone]

#189311

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 AAAA 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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web