Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 605
    • Issues 605
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 88
    • Merge requests 88
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #3128
Closed
Open
Issue created Feb 08, 2022 by Thomas Amgarten@ta

"dig" from BIND 9.18.0 does not recover from a isc_nm_udpconnect() failure

Summary

Using the dig-utility from BIND-9.18.0 (self-compiled), I see a curious behavior when using the "+trace"-option. The dig-tool does in most cases just queries the local resolver for the root-servers and does not follow the delegations:

$ /usr/local/bind-9.18.0/bin/dig @127.0.0.1 +trace www.isc.org 

; <<>> DiG 9.18.0 <<>> @127.0.0.1 +trace www.isc.org
; (1 server found)
;; global options: +cmd
.			514551	IN	NS	m.root-servers.net.
.			514551	IN	NS	c.root-servers.net.
.			514551	IN	NS	a.root-servers.net.
.			514551	IN	NS	i.root-servers.net.
.			514551	IN	NS	l.root-servers.net.
.			514551	IN	NS	k.root-servers.net.
.			514551	IN	NS	e.root-servers.net.
.			514551	IN	NS	d.root-servers.net.
.			514551	IN	NS	h.root-servers.net.
.			514551	IN	NS	f.root-servers.net.
.			514551	IN	NS	g.root-servers.net.
.			514551	IN	NS	b.root-servers.net.
.			514551	IN	NS	j.root-servers.net.
.			514551	IN	RRSIG	NS 8 0 518400 20220221050000 20220208040000 9799 . fa3vdWBzC56rEdTkuEVhCX2iALLBoYn2H29psjgHC5wPv0ws6wqrC8yG jKJgWRS3xS92NJy8RsrTiv/K+tRoC0AxgQ1kcFJ6UKyfuSuYEkXEOpnk cqQhEHxDVBN7eBQ6mdIuJ/rTzoBJ8PCIW75aHv+OH/3Qt/tf74nZnH0s rptFsc7/d/O56FIu2bzBojBxdi5FUA8fzffKP9eQfyN8wMAyLXfwUtDw LkyAQZMGeTTLA1qWOV0DK8sTBS+YJwOz1PPcQFyDbU9PG6hbXjvBXINg 1v1+17/3knkhICiL8FN4ylEHj8YVMrFNtzhlIipXwy/V/SEhKsHgyJHv BNAhWw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

In few tries/situations, dig (9.18.0) begins iterating through the dns-hierarchy, but in the most cases, dig stops after querying the local resolver or after iterating one or two steps. I've rarely seen, that dig-9.18.0 finished through the end (the final authoritative server).

$ /usr/local/bind-9.18.0/bin/dig @127.0.0.1 +trace www.isc.org 

; <<>> DiG 9.18.0 <<>> @127.0.0.1 +trace www.isc.org
; (1 server found)
;; global options: +cmd
.			514510	IN	NS	l.root-servers.net.
.			514510	IN	NS	h.root-servers.net.
.			514510	IN	NS	f.root-servers.net.
.			514510	IN	NS	c.root-servers.net.
.			514510	IN	NS	e.root-servers.net.
.			514510	IN	NS	b.root-servers.net.
.			514510	IN	NS	k.root-servers.net.
.			514510	IN	NS	d.root-servers.net.
.			514510	IN	NS	g.root-servers.net.
.			514510	IN	NS	a.root-servers.net.
.			514510	IN	NS	i.root-servers.net.
.			514510	IN	NS	j.root-servers.net.
.			514510	IN	NS	m.root-servers.net.
.			514510	IN	RRSIG	NS 8 0 518400 20220221050000 20220208040000 9799 . fa3vdWBzC56rEdTkuEVhCX2iALLBoYn2H29psjgHC5wPv0ws6wqrC8yG jKJgWRS3xS92NJy8RsrTiv/K+tRoC0AxgQ1kcFJ6UKyfuSuYEkXEOpnk cqQhEHxDVBN7eBQ6mdIuJ/rTzoBJ8PCIW75aHv+OH/3Qt/tf74nZnH0s rptFsc7/d/O56FIu2bzBojBxdi5FUA8fzffKP9eQfyN8wMAyLXfwUtDw LkyAQZMGeTTLA1qWOV0DK8sTBS+YJwOz1PPcQFyDbU9PG6hbXjvBXINg 1v1+17/3knkhICiL8FN4ylEHj8YVMrFNtzhlIipXwy/V/SEhKsHgyJHv BNAhWw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

org.			172800	IN	NS	a0.org.afilias-nst.info.
org.			172800	IN	NS	a2.org.afilias-nst.info.
org.			172800	IN	NS	b0.org.afilias-nst.org.
org.			172800	IN	NS	b2.org.afilias-nst.org.
org.			172800	IN	NS	c0.org.afilias-nst.info.
org.			172800	IN	NS	d0.org.afilias-nst.org.
org.			86400	IN	DS	26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org.			86400	IN	RRSIG	DS 8 1 86400 20220221050000 20220208040000 9799 . S8iG14jGn8yS3WsOFOmuRT1omQto8Lwx5mpzTe81Wr3qny2i5NcIbmIj aionGUWQwgxax6lMApHaWHDsq8l2bkodRdRrFZGcQnA2spaQVDUbGJT4 nQxHUL7L7IRw5Vflm8p1EO7EZLV7aKW69dsIDEeuYPp31J3cemjCzD3X e3bHYQKwtrvDz2TVVTaGzMZsgdH0WV+xuJRqV8p1YshbxDE8T+hvXsyF GeL0Sun6ioXfq5lWNfH/hI5hmmMoxoPPppgmNZ5l2Kl5PxzXGYaK832R Kp9Nx8yVRYbAfFhxwC6J2HMPDka+o6lYOCTBhyqkJ+33rk5NH+IGml9k 6mepog==
;; Received 777 bytes from 192.203.230.10#53(e.root-servers.net) in 2 ms

It doesn't matter which address/record I try to resolve (www.google.com, www.microsoft.com, www.switch.ch...).

Using a dig older than 9.18.0 (from version 9.11.26 in that case) on the same server and using initially the same server (@127.0.0.1), then this version always iterates to the final authoritative server:

$ /usr/bin/dig @127.0.0.1 +trace www.isc.org

; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> @127.0.0.1 +trace www.isc.org
; (1 server found)
;; global options: +cmd
.			514368	IN	NS	g.root-servers.net.
.			514368	IN	NS	h.root-servers.net.
.			514368	IN	NS	l.root-servers.net.
.			514368	IN	NS	b.root-servers.net.
.			514368	IN	NS	e.root-servers.net.
.			514368	IN	NS	d.root-servers.net.
.			514368	IN	NS	k.root-servers.net.
.			514368	IN	NS	f.root-servers.net.
.			514368	IN	NS	m.root-servers.net.
.			514368	IN	NS	c.root-servers.net.
.			514368	IN	NS	a.root-servers.net.
.			514368	IN	NS	j.root-servers.net.
.			514368	IN	NS	i.root-servers.net.
.			514368	IN	RRSIG	NS 8 0 518400 20220221050000 20220208040000 9799 . fa3vdWBzC56rEdTkuEVhCX2iALLBoYn2H29psjgHC5wPv0ws6wqrC8yG jKJgWRS3xS92NJy8RsrTiv/K+tRoC0AxgQ1kcFJ6UKyfuSuYEkXEOpnk cqQhEHxDVBN7eBQ6mdIuJ/rTzoBJ8PCIW75aHv+OH/3Qt/tf74nZnH0s rptFsc7/d/O56FIu2bzBojBxdi5FUA8fzffKP9eQfyN8wMAyLXfwUtDw LkyAQZMGeTTLA1qWOV0DK8sTBS+YJwOz1PPcQFyDbU9PG6hbXjvBXINg 1v1+17/3knkhICiL8FN4ylEHj8YVMrFNtzhlIipXwy/V/SEhKsHgyJHv BNAhWw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

org.			172800	IN	NS	b2.org.afilias-nst.org.
org.			172800	IN	NS	a2.org.afilias-nst.info.
org.			172800	IN	NS	a0.org.afilias-nst.info.
org.			172800	IN	NS	b0.org.afilias-nst.org.
org.			172800	IN	NS	d0.org.afilias-nst.org.
org.			172800	IN	NS	c0.org.afilias-nst.info.
org.			86400	IN	DS	26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org.			86400	IN	RRSIG	DS 8 1 86400 20220221050000 20220208040000 9799 . S8iG14jGn8yS3WsOFOmuRT1omQto8Lwx5mpzTe81Wr3qny2i5NcIbmIj aionGUWQwgxax6lMApHaWHDsq8l2bkodRdRrFZGcQnA2spaQVDUbGJT4 nQxHUL7L7IRw5Vflm8p1EO7EZLV7aKW69dsIDEeuYPp31J3cemjCzD3X e3bHYQKwtrvDz2TVVTaGzMZsgdH0WV+xuJRqV8p1YshbxDE8T+hvXsyF GeL0Sun6ioXfq5lWNfH/hI5hmmMoxoPPppgmNZ5l2Kl5PxzXGYaK832R Kp9Nx8yVRYbAfFhxwC6J2HMPDka+o6lYOCTBhyqkJ+33rk5NH+IGml9k 6mepog==
;; Received 811 bytes from 192.36.148.17#53(i.root-servers.net) in 11 ms

isc.org.		86400	IN	NS	ns2.isc.org.
isc.org.		86400	IN	NS	ns.isc.afilias-nst.info.
isc.org.		86400	IN	NS	ns1.isc.org.
isc.org.		86400	IN	NS	ns3.isc.org.
isc.org.		86400	IN	DS	7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
isc.org.		86400	IN	RRSIG	DS 8 2 86400 20220222152200 20220201142200 7986 org. cFxS3wGUhe85mBa6JNo7T0Z1KdpKoi9KeWEJtp8EKGfQp0PGBGWWrWwf oz+hH34L8ttXY5n+54VBo2C8O3cp/g95totmdQezCyoZYDCvRqaGEplp yjJCWY/KaRJ4KcHlkZ6LIt1JOs+eoH4njTfV9l8XYBpVIqYaNFSwMKbf lwE=
;; Received 446 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 20 ms

www.isc.org.		300	IN	CNAME	dualstack.osff2.map.fastly.net.
www.isc.org.		300	IN	RRSIG	CNAME 13 3 300 20220309140450 20220207132719 27566 isc.org. QRsTnA1etMEBeA/txjOtLVIQXHSo22uuBQNUsIQXkN6j8njRVZ1iEYsV JVgG1f0R2QwNRomK23G9EcvGPaBCcw==
;; Received 215 bytes from 199.6.1.52#53(ns2.isc.org) in 13 ms

BIND version used

9.18.0

Steps to reproduce

Using the latest dig:

/usr/local/bind-9.18.0/bin/dig @127.0.0.1 +trace www.isc.org

What is the current bug behavior?

The utility does not iterates to the final authoritative server and queries this server for the requested resource record.

What is the expected correct behavior?

An answer for the requested RR from the final authoritative server like it works with dig 9.11.26 (for example).

Edited Feb 11, 2022 by Michał Kępień
Assignee
Assign to
Time tracking