|Summary:||Update usr/bin/host to the latest upstream version to fix IXFR/AXFR handling|
|Product:||Base System||Reporter:||Vitaly Magerya <vmagerya>|
|Component:||bin||Assignee:||Dag-Erling Smørgrav <des>|
|Severity:||Affects Some People||CC:||des, gonzo, ngie|
Description Vitaly Magerya 2016-05-01 10:50:57 UTC
Created attachment 169845 [details] ldns-host-0289cde234a0.diff Current usr/bin/host (coming from contrib/ldns-host and ) has two problems with zone transfers: 1) IXFR queries are badly formed; for example: $ host -t ixfr x 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: Host x not found: 1(FORMERR) This FORMERR comes from the fact that 'host' adds two (instead of one) SOA records to it's IXFR query packets; this started happening after contrib/ldns updated to 1.6.17 due to changes in ldns (I can't tell you precisely which FreeBSD versions ship with ldns 1.6.17 though). 2) Both AXFR and IXFR queries do not support multi-packets responses: 'host' only print the first response packet. In practice this means any zone transfer with zone sizes above 64kb will be silently truncated. While this problem is documented in the man page, it's still unpleasant and I received reports from people burned by it (they had to fix it by installing dns/bind-tools to revert to the old 'host'). The latest upstream version of ldns-host  has both these problems fixed, and I'm attaching a patch to update contrib/ldns-host to that. Ideally it should be eventually imported into both current and stable branches.  https://tx97.net/ldns-host/  https://hg.tx97.net/ldns-host/file/0289cde234a0
Comment 1 Enji Cooper 2016-06-09 14:31:33 UTC
Taking bug for validation/port, as noted on hackers@.
Comment 2 commit-hook 2016-06-09 20:40:56 UTC
A commit references this bug: Author: des Date: Thu Jun 9 20:40:12 UTC 2016 New revision: 301759 URL: https://svnweb.freebsd.org/changeset/base/301759 Log: Update to latest upstream version PR: 209177 Reported by: Vitaly Magerya MFC after: 1 week Changes: _U head/contrib/ldns-host/ head/contrib/ldns-host/Makefile head/contrib/ldns-host/ldns-host.1 head/contrib/ldns-host/ldns-host.c
Comment 3 Enji Cooper 2016-06-09 20:42:18 UTC
des@ did the commit. Reassigning :).
Comment 4 Dag-Erling Smørgrav 2016-06-09 21:28:18 UTC
Note that I still get FORMERR with your test case: % host -t ixfr x localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: Host x not found: 1(FORMERR) ; Transfer failed. (I expected NXDOMAIN)
Comment 5 Vitaly Magerya 2016-06-09 22:57:44 UTC
I'm not sure where that particular FORMERR comes from (what are you running on your localhost?). An easy way to test the IXFR changes would be this: host -t ixfr zonetransfer.me nsztm1.digi.ninja The previous version showed FORMERR, the current one should show a list of records. (An alternative test method is to set up your own authoritative server, which is what I alluded to with "host -t ixfr x localhost", but that's less convenient given the existence of nsztm1.digi.ninja). * * * I just discovered an unfixed problem with ixfr queries in the new code, namely: $ host -t ixfr=2014101603 zonetransfer.me nsztm1.digi.ninja Using domain server: Name: nsztm1.digi.ninja Address: 22.214.171.124#53 Aliases: zonetransfer.me has SOA record nsztm1.digi.ninja. robin.digi.ninja. 2014101603 172800 900 1209600 3600 ; Transfer failed. Instead of "Transfer failed", host should recognize that this response indicates "no new records since 2014101603". I don't know why I didn't test this case until now.
Comment 6 Dag-Erling Smørgrav 2016-06-09 23:09:09 UTC
Previous version on 10.3-p3: % host -t ixfr zonetransfer.me nsztm1.digi.ninja Using domain server: Name: nsztm1.digi.ninja Address: 126.96.36.199#53 Aliases: Host zonetransfer.me not found: 9(NOTAUTH)
Comment 7 Vitaly Magerya 2016-06-10 08:57:09 UTC
Strange. I see a FORMERR on 10.1-RELEASE-p26 amd64, 11.0-CURRENT i386 (built on 2015-01-11), and 10.3-RELEASE i386. Do you have a DNS-redirecting firewall somewhere in your network maybe? Whatever the case with the old one, the new one should work. Does it?
Comment 8 Dag-Erling Smørgrav 2016-06-10 10:13:07 UTC
The new one (what's currently in 11.0) works as you described. There is nothing on my network that intercepts DNS traffic; I have FTTH and my own router.
Comment 9 Vitaly Magerya 2016-06-10 15:30:43 UTC
Created attachment 171271 [details] ldns-host-06347b1f76fe.diff Hm. I'm out of ideas then. I guess the important part is that the new version works, while the old one didn't. * * * While we're at it, would you commit an update to , which fixes the problem from comment 5, or should I submit it separately?  http://hg.tx97.net/ldns-host/rev/06347b1f76fe
Comment 10 commit-hook 2016-07-13 18:27:01 UTC
A commit references this bug: Author: des Date: Wed Jul 13 18:26:05 UTC 2016 New revision: 302779 URL: https://svnweb.freebsd.org/changeset/base/302779 Log: merge upstream hg 06347b1f76fe (fix IXFR) PR: 209177 MFC after: 3 days Changes: _U head/contrib/ldns-host/ head/contrib/ldns-host/ldns-host.c
Comment 11 commit-hook 2016-07-14 06:10:51 UTC
A commit references this bug: Author: ngie Date: Thu Jul 14 06:10:16 UTC 2016 New revision: 302807 URL: https://svnweb.freebsd.org/changeset/base/302807 Log: Initialize first_serial to 0 in dozonetransfer(..) to fix -Wuninitialized warning MFC after: 3 days X-MFC with: r302779 Pointyhat to: des PR: 209177 Reported by: Jenkins (sparc64 job), gcc 4.2.1, gcc 5.3.0 Sponsored by: EMC / Isilon Storage Division Changes: head/contrib/ldns-host/ldns-host.c
Comment 12 commit-hook 2018-03-07 11:03:13 UTC
A commit references this bug: Author: eadler Date: Wed Mar 7 11:03:01 UTC 2018 New revision: 330577 URL: https://svnweb.freebsd.org/changeset/base/330577 Log: MFC r302779,r302807: merge upstream hg 06347b1f76fe (fix IXFR) Initialize first_serial to 0 in dozonetransfer(..) to fix -Wuninitialized warning PR: 209177 Changes: _U stable/11/ stable/11/contrib/ldns-host/ldns-host.c
Comment 13 Oleksandr Tymoshenko 2019-01-21 18:48:56 UTC
There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved. Thanks