DNS over IPV6 Transport does not work on bind9 1:9.10.3.dfsg.P4-12.3+deb9u5
Summary
DNS REPLY IS NOT PROCESSED WHEN IPV6 ADDRESS OF DNS SERVER IS USED TO RESOLVE NAME. [ONLY UDP has problem, TCP works fine.]
BIND version used
1.) Kernel and BIND9 version information.
pchaudha@dut:~$ dpkg -l | grep 1:9.10.3
ii bind9-host 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 Version of 'host' bundled with BIND 9.X
ii libbind9-140:amd64 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 BIND9 Shared Library used by BIND
ii libdns-export162 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 Exported DNS Shared Library
ii libdns162:amd64 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 DNS Shared Library used by BIND
ii libisc-export160 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 Exported ISC Shared Library
ii libisc160:amd64 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 ISC Shared Library used by BIND
ii libisccc140:amd64 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 Command Channel Library used by BIND
ii libisccfg140:amd64 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 Config File Handling Library used by BIND
ii liblwres141:amd64 1:9.10.3.dfsg.P4-12.3+deb9u5 amd64 Lightweight Resolver Library used by BIND
pchaudha@dut:~$ uname -a
Linux dut 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2015-12-19) x86_64 GNU/Linux
Steps to reproduce
1.) Using IPV6 Address of DNS server, send a DNS query. Result: Request times out.
pchaudha@dut:~$ host vsnl.com 2aXX:xxxx:xx:1::c216
;; connection timed out; no servers could be reached
2.) TCPDUMP shows reply is coming back to DUT. But dut sends request again after 5 secs because reply is not processed properly.
Note: infra01.corp.NK.com has ip 2xxx:xxxx:32:1::c216.
pchaudha@dut:~$ sudo tcpdump -i any host 2xxx:xxxx:32:1::c216 -vvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:43:15.287589 IP6 (flowlabel 0x05a84, hlim 64, next-header UDP (17) payload length: 34) dut.nw.NK.com.44773 > infra01.corp.NK.com.domain: [udp sum ok] 63325+ A? vsnl.com. (26)
18:43:15.288003 IP6 (hlim 57, next-header UDP (17) payload length: 165) infra01.corp.NK.com.domain > dut.nw.NK.com.44773: [udp sum ok] 63325 q: A? vsnl.com. 1/2/2 vsnl.com. [7m34s] A 54.254.156.226 ns: vsnl.com. [1d23h57m34s] NS inpudiidnsprprd01.tatacommunications.com., vsnl.com. [1d23h57m34s] NS inchvsidnsseprd01.tatacommunications.com. ar: inchvsidnsseprd01.tatacommunications.com. [11h18m10s] A 14.141.1.26, inpudiidnsprprd01.tatacommunications.com. [1h17m15s] A 14.140.80.178 (157)
18:43:20.271249 IP6 (flowlabel 0x05a84, hlim 64, next-header UDP (17) payload length: 34) dut.nw.NK.com.44773 > infra01.corp.NK.com.domain: [udp sum ok] 63325+ A? vsnl.com. (26)
*18:43:20.271773 I*P6 (hlim 57, next-header UDP (17) payload length: 165) infra01.corp.NK.com.domain > dut.nw.NK.com.44773: [udp sum ok] 63325 q: A? vsnl.com. 1/2/2 vsnl.com. [7m29s] A 54.254.156.226 ns: vsnl.com. [1d23h57m29s] NS inpudiidnsprprd01.tatacommunications.com., vsnl.com. [1d23h57m29s] NS inchvsidnsseprd01.tatacommunications.com. ar: inchvsidnsseprd01.tatacommunications.com. [11h18m5s] A 14.141.1.26, inpudiidnsprprd01.tatacommunications.com. [1h17m10s] A 14.140.80.178 (157)
3.) By using a kernel tracer, I could verify that packet is written to socket by kernel:
Jun 27 00:32:34.818880 dut NOTICE kernel: [1897123.685474] lnos ip6 udp src: 2xxx:xxxx:0032:0001:0000:0000:0000:c216 port: 53 <<<<<<<<<
Jun 27 00:32:34.818993 dut WARNING kernel: [1897123.758496] [<ffffffff9b5312b4>] ? dump_stack+0x5c/0x78
Jun 27 00:32:34.818998 dut WARNING kernel: [1897123.764644] [<ffffffffc0267108>] ? lnos_probe5_handler+0x28/0x40 [dns_debug]
Jun 27 00:32:34.819003 dut WARNING kernel: [1897123.772825] [<ffffffff9b7d7c26>] ? __udpv6_queue_rcv_skb+0x46/0xc0
Jun 27 00:32:34.819008 dut WARNING kernel: [1897123.780030] [<ffffffff9b7da4df>] ? udpv6_queue_rcv_skb+0x1cf/0x4e0
Jun 27 00:32:34.819013 dut WARNING kernel: [1897123.787234] [<ffffffff9b7dac07>] ? __udp6_lib_rcv+0x417/0x850
Jun 27 00:32:34.819018 dut WARNING kernel: [1897123.793957] [<ffffffff9b7bda8a>] ? ip6_input_finish+0xea/0x430
Jun 27 00:32:34.819023 dut WARNING kernel: [1897123.800772] [<ffffffff9b7bde0b>] ? ip6_input+0x3b/0xc0
Jun 27 00:32:34.819028 dut WARNING kernel: [1897123.806809] [<ffffffff9b7bd9a0>] ? ip6_rcv_finish+0xf0/0xf0
Jun 27 00:32:34.819033 dut WARNING kernel: [1897123.813333] [<ffffffff9b7be1b6>] ? ipv6_rcv+0x326/0x4e0
Jun 27 00:32:34.819038 dut WARNING kernel: [1897123.819467] [<ffffffff9b7bd8b0>] ? ip6_make_skb+0x200/0x200
Jun 27 00:32:34.819042 dut WARNING kernel: [1897123.825992] [<ffffffff9b70d2fd>] ? __netif_receive_skb_core+0x51d/0xa40
Jun 27 00:32:34.819047 dut WARNING kernel: [1897123.833683] [<ffffffff9b2baf1f>] ? __wake_up_common+0x4f/0x90
Jun 27 00:32:34.819052 dut WARNING kernel: [1897123.840401] [<ffffffff9b70e958>] ? process_backlog+0x88/0x130
Jun 27 00:32:34.819077 dut WARNING kernel: [1897123.847120] [<ffffffff9b70e0e6>] ? net_rx_action+0x246/0x380
Jun 27 00:32:34.819085 dut WARNING kernel: [1897123.853742] [<ffffffff9b81974d>] ? __do_softirq+0x10d/0x2a5
Jun 27 00:32:34.819092 dut WARNING kernel: [1897123.860266] [<ffffffff9b27ee40>] ? irq_exit+0xb0/0xc0
Jun 27 00:32:34.819097 dut WARNING kernel: [1897123.866207] [<ffffffff9b8187e7>] ? do_IRQ+0x57/0xe0
Jun 27 00:32:34.819102 dut WARNING kernel: [1897123.871954] [<ffffffff9b816556>] ? common_interrupt+0x96/0x96
What is the current bug behavior?
pchaudha@dut:~$ host vsnl.com 2aXX:xxxx:xx:1::c216 ;; connection timed out; no servers could be reached
What is the expected correct behavior?
pchaudha@dut:~$ host vsnl.com 2axx:xxxx:255:1::aff:2035
Using domain server:
Name: 2axx:xxxx:255:1::aff:2035
Address: 2axx:xxxx:255:1::aff:2035#53
Aliases:
vsnl.com has address 54.254.156.226
vsnl.com mail is handled by 100 in.mx2.mailhostbox.com.
vsnl.com mail is handled by 100 in.mx3.mailhostbox.com.
vsnl.com mail is handled by 100 in.mx1.mailhostbox.com.
Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
named-checkconf -px
.)
Relevant logs and/or screenshots
1.) Using IPV6 Address of DNS server, send a DNS query. Result: Request times out.
pchaudha@dut:~$ host vsnl.com 2aXX:xxxx:xx:1::c216
;; connection timed out; no servers could be reached
2.) TCPDUMP shows reply is coming back to DUT. But dut sends request again after 5 secs because reply is not processed properly.
Note: infra01.corp.NK.com has ip 2xxx:xxxx:32:1::c216.
pchaudha@dut:~$ sudo tcpdump -i any host 2xxx:xxxx:32:1::c216 -vvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:43:15.287589 IP6 (flowlabel 0x05a84, hlim 64, next-header UDP (17) payload length: 34) dut.nw.NK.com.44773 > infra01.corp.NK.com.domain: [udp sum ok] 63325+ A? vsnl.com. (26)
18:43:15.288003 IP6 (hlim 57, next-header UDP (17) payload length: 165) infra01.corp.NK.com.domain > dut.nw.NK.com.44773: [udp sum ok] 63325 q: A? vsnl.com. 1/2/2 vsnl.com. [7m34s] A 54.254.156.226 ns: vsnl.com. [1d23h57m34s] NS inpudiidnsprprd01.tatacommunications.com., vsnl.com. [1d23h57m34s] NS inchvsidnsseprd01.tatacommunications.com. ar: inchvsidnsseprd01.tatacommunications.com. [11h18m10s] A 14.141.1.26, inpudiidnsprprd01.tatacommunications.com. [1h17m15s] A 14.140.80.178 (157)
18:43:20.271249 IP6 (flowlabel 0x05a84, hlim 64, next-header UDP (17) payload length: 34) dut.nw.NK.com.44773 > infra01.corp.NK.com.domain: [udp sum ok] 63325+ A? vsnl.com. (26)
*18:43:20.271773 I*P6 (hlim 57, next-header UDP (17) payload length: 165) infra01.corp.NK.com.domain > dut.nw.NK.com.44773: [udp sum ok] 63325 q: A? vsnl.com. 1/2/2 vsnl.com. [7m29s] A 54.254.156.226 ns: vsnl.com. [1d23h57m29s] NS inpudiidnsprprd01.tatacommunications.com., vsnl.com. [1d23h57m29s] NS inchvsidnsseprd01.tatacommunications.com. ar: inchvsidnsseprd01.tatacommunications.com. [11h18m5s] A 14.141.1.26, inpudiidnsprprd01.tatacommunications.com. [1h17m10s] A 14.140.80.178 (157)
3.) By using a kernel tracer, I could verify that packet is written to socket by kernel:
Jun 27 00:32:34.818880 dut NOTICE kernel: [1897123.685474] lnos ip6 udp src: 2xxx:xxxx:0032:0001:0000:0000:0000:c216 port: 53 <<<<<<<<<
Jun 27 00:32:34.818993 dut WARNING kernel: [1897123.758496] [<ffffffff9b5312b4>] ? dump_stack+0x5c/0x78
Jun 27 00:32:34.818998 dut WARNING kernel: [1897123.764644] [<ffffffffc0267108>] ? lnos_probe5_handler+0x28/0x40 [dns_debug]
Jun 27 00:32:34.819003 dut WARNING kernel: [1897123.772825] [<ffffffff9b7d7c26>] ? __udpv6_queue_rcv_skb+0x46/0xc0
Jun 27 00:32:34.819008 dut WARNING kernel: [1897123.780030] [<ffffffff9b7da4df>] ? udpv6_queue_rcv_skb+0x1cf/0x4e0
Jun 27 00:32:34.819013 dut WARNING kernel: [1897123.787234] [<ffffffff9b7dac07>] ? __udp6_lib_rcv+0x417/0x850
Jun 27 00:32:34.819018 dut WARNING kernel: [1897123.793957] [<ffffffff9b7bda8a>] ? ip6_input_finish+0xea/0x430
Jun 27 00:32:34.819023 dut WARNING kernel: [1897123.800772] [<ffffffff9b7bde0b>] ? ip6_input+0x3b/0xc0
Jun 27 00:32:34.819028 dut WARNING kernel: [1897123.806809] [<ffffffff9b7bd9a0>] ? ip6_rcv_finish+0xf0/0xf0
Jun 27 00:32:34.819033 dut WARNING kernel: [1897123.813333] [<ffffffff9b7be1b6>] ? ipv6_rcv+0x326/0x4e0
Jun 27 00:32:34.819038 dut WARNING kernel: [1897123.819467] [<ffffffff9b7bd8b0>] ? ip6_make_skb+0x200/0x200
Jun 27 00:32:34.819042 dut WARNING kernel: [1897123.825992] [<ffffffff9b70d2fd>] ? __netif_receive_skb_core+0x51d/0xa40
Jun 27 00:32:34.819047 dut WARNING kernel: [1897123.833683] [<ffffffff9b2baf1f>] ? __wake_up_common+0x4f/0x90
Jun 27 00:32:34.819052 dut WARNING kernel: [1897123.840401] [<ffffffff9b70e958>] ? process_backlog+0x88/0x130
Jun 27 00:32:34.819077 dut WARNING kernel: [1897123.847120] [<ffffffff9b70e0e6>] ? net_rx_action+0x246/0x380
Jun 27 00:32:34.819085 dut WARNING kernel: [1897123.853742] [<ffffffff9b81974d>] ? __do_softirq+0x10d/0x2a5
Jun 27 00:32:34.819092 dut WARNING kernel: [1897123.860266] [<ffffffff9b27ee40>] ? irq_exit+0xb0/0xc0
Jun 27 00:32:34.819097 dut WARNING kernel: [1897123.866207] [<ffffffff9b8187e7>] ? do_IRQ+0x57/0xe0
Jun 27 00:32:34.819102 dut WARNING kernel: [1897123.871954] [<ffffffff9b816556>] ? common_interrupt+0x96/0x96
Possible fixes
(If you can, link to the line of code that might be responsible for the problem.)