Bug 913651 - dnscache resolver ignores ..servers/mydomain.com files.
dnscache resolver ignores ..servers/mydomain.com files.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ndjbdns (Show other bugs)
rawhide
All All
unspecified Severity high
: ---
: ---
Assigned To: pjp
Fedora Extras Quality Assurance
https://github.com/pjps/ndjbdns/
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-21 13:03 EST by pjp
Modified: 2013-03-29 17:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-23 19:53:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description pjp 2013-02-21 13:03:30 EST
dnscache resolver seems to ignore or fails to correctly read authoritative servers for specific domains from files -> /etc/ndjbdns/server/mydomain.com.

Reference:
 -> https://pjps.wordpress.com/2013/02/06/new-djbdns-1-05-6/#comment-328
Comment 1 pjp 2013-02-23 11:59:58 EST
This issue has been fixed.

-> https://github.com/pjps/ndjbdns/commit/ff3e1965e16da053ed1a2bc52ac15a8b6219b34a

As indicated, when dnscache server is invoked with debug level 4, -d4 option, it logs the root server configurations read from ..servers/mydomain.com files.

===
dnscache: DEBUG_LEVEL set to `4'
dnscache: DATALIMIT set to `8000000' bytes
dnscache: root & working directory changed to `..etc/ndjbdns'
dnscache: root privileges dropped, user-id set to `2'
dnscache: singapore.com:
dnscache:   10.0.0.42
dnscache:   10.0.0.43
dnscache:   10.0.0.44
dnscache: roots:
dnscache:   128.63.2.53
dnscache:   128.8.10.90
dnscache:   192.112.36.4
dnscache:   192.203.230.10
dnscache:   192.228.79.201
dnscache:   192.33.4.12
dnscache:   192.36.148.17
dnscache:   192.5.5.241
dnscache:   192.58.128.30
dnscache:   193.0.14.129
dnscache:   198.41.0.4
dnscache:   199.7.83.42
dnscache:   202.12.27.33
dnscache: srilanka.com:
dnscache:   192.168.1.134
===

Review and testing is required.
Comment 3 Bob Gustafson 2013-03-12 19:53:26 EDT
Did you want tinydns version number changed too? It is still at 1.05.7

[root@hoho0 ndjbdns-1.05.7]# dnscache -v
dnscache version 1.05.7
[root@hoho0 ndjbdns-1.05.7]# tinydns -v
tinydns version 1.05.6
[root@hoho0 ndjbdns-1.05.7]# which tinydns
/usr/sbin/tinydns
[root@hoho0 ndjbdns-1.05.7]# ls -l /usr/sbin/tinydns
-rwxr-xr-x. 1 root root 164074 Mar 12 18:46 /usr/sbin/tinydns
Comment 4 Bob Gustafson 2013-03-12 19:54:57 EDT
Having the -d4 option on tinydns would be good too.
Comment 5 pjp 2013-03-13 02:06:14 EDT
  Hello Bob,

(In reply to comment #3)
> Did you want tinydns version number changed too? It is still at 1.05.7

  ndjbdns package has a version, servers & tools are not version-ed separately.

> [root@hoho0 ndjbdns-1.05.7]# dnscache -v
> dnscache version 1.05.7
> [root@hoho0 ndjbdns-1.05.7]# tinydns -v
> tinydns version 1.05.6

  This is weird. How did you get this? Could I've a look at the source please??


Just to clarify: latest release is - 1.05.7. All servers & tools should report the same.

> Having the -d4 option on tinydns would be good too.

  Yep, /me makes a note of it. :)

Thank you.
Comment 6 Bob Gustafson 2013-03-13 09:09:47 EDT
Hi pjp

Yes, you are right, grepping the source finds no 1.05.6 - lots of 1.05.7 ...

I had ndjbdns running on my spare system and spent some time learning dns and how things work by hitting it extensively with dig.

You have the configuration set up slightly different from the way DJB does it - both dnscache and tinydns in the same directory, so some of the older documentation doesn't apply exactly.

When I saw your changes, I downloaded the src package and built my own 1.05.7 as your changes haven't yet made it into the yum repos for f18.

The weird thing is shown below.

[root@hoho0 ndjbdns-1.05.7]# which -a tinydns
/usr/sbin/tinydns
/usr/bin/tinydns
[root@hoho0 ndjbdns-1.05.7]# echo $PATH
/root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
[root@hoho0 ndjbdns-1.05.7]# /usr/sbin/tinydns -v
tinydns version 1.05.7
[root@hoho0 ndjbdns-1.05.7]# /usr/bin/tinydns -v
tinydns version 1.05.6
[root@hoho0 ndjbdns-1.05.7]# tinydns -v
tinydns version 1.05.6
[root@hoho0 ndjbdns-1.05.7]# ls -l /usr/sbin/tinydns 
-rwxr-xr-x. 1 root root 164074 Mar 12 18:46 /usr/sbin/tinydns
[root@hoho0 ndjbdns-1.05.7]# ls -l /usr/bin/tinydns
-rwxr-xr-x. 1 root root 44544 Jan 20 06:14 /usr/bin/tinydns
[root@hoho0 ndjbdns-1.05.7]# 

Apparently the older version of tinydns got loaded into /usr/bin/tinydns - this was done using 'yum install' awhile ago.

When I installed the new version (I split the build from the install - doing rpmbuild -bc and then after looking things over, 'make install' in the BUILD directory. Shouldn't make any difference..  (I saved the output from 'make install' if you are interested)

When the new version is installed, it is put into /usr/sbin/tinydns, but the older version is not wiped out.

Then, even though /usr/sbin is ahead of /usr/bin in the $PATH, /usr/bin is chosen when just 'tinydns' is run.

I don't think this should happen...

[sizes of new and old tinydns are quite different too..]
Comment 7 pjp 2013-03-13 11:00:44 EDT
Ah, interesting glitch. I'll fix the spec file to remove old server binaries from under /usr/bin. Thanks so much for reporting it. I appreciate it.

Thank you. :)
Comment 8 Bob Gustafson 2013-03-13 11:54:13 EDT
I was going to report the PATH glitch as a bug. In the process, I logged out and then in again. Now the PATH ordering is correct and the weirdness is gone..

[root@hoho0 ~]# which -a tinydns
/usr/sbin/tinydns
/usr/bin/tinydns
[root@hoho0 ~]# tinydns -v
tinydns version 1.05.7
[root@hoho0 ~]# /usr/bin/tinydns -v
tinydns version 1.05.6
[root@hoho0 ~]# 

I wonder what triggered the weird behavior? Maybe something in the rpmbuild scripts?
Comment 9 Bob Gustafson 2013-03-13 12:02:07 EDT
No, weirdness not repeatable.

I rebuilt ndjbnds and did 'make install' in the same way as before.

[root@hoho0 ndjbdns-1.05.7]# tinydns -v
tinydns version 1.05.7
[root@hoho0 ndjbdns-1.05.7]# which -a tinydns
/usr/sbin/tinydns
/usr/bin/tinydns
[root@hoho0 ndjbdns-1.05.7]# echo $PATH
/root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
[root@hoho0 ndjbdns-1.05.7]# ls -l /usr/sbin/tinydns
-rwxr-xr-x. 1 root root 164074 Mar 13 10:56 /usr/sbin/tinydns
[root@hoho0 ndjbdns-1.05.7]# /usr/bin/tinydns -v
tinydns version 1.05.6
[root@hoho0 ndjbdns-1.05.7]#
Comment 10 pjp 2013-03-13 12:05:53 EDT
(In reply to comment #8)
> I wonder what triggered the weird behavior? Maybe something in the rpmbuild
> scripts?

I guess, may be shell remembered(help hash) previous(/usr/bin) path from before you installed the latest RPM. After you logged out and in again, it refreshed that path to resolve from /usr/sbin.
Comment 11 Bob Gustafson 2013-03-13 13:52:58 EDT
Yep, the bash cache...

See new bug 921213

(Wishful thinking on my part..)
Comment 12 Bob Gustafson 2013-03-13 16:55:12 EDT
The -d4 diagnostics in dnscache and tinydns are features that rarely get used, but bulk up the daemon (see difference in executable size from 1.05.6 to 1.05.7)

Why not take out the -d4 stuff and put it into a separate config diagnostic tool. You could load up this new 'ndjbdns-tool' with whatever comes to mind that would help the person trying to come up with a valid configuration.

The config read routines could be common to the daemons and to the tool - to help keep them in sync if there are other changes.
Comment 13 pjp 2013-03-14 01:04:42 EDT
(In reply to comment #12)
> Why not take out the -d4 stuff and put it into a separate config diagnostic
> tool. You could load up this new 'ndjbdns-tool' with whatever comes to mind
> that would help the person trying to come up with a valid configuration.

  Hmmn, interesting. /me make a note of this too. :)

> The config read routines could be common to the daemons and to the tool - to
> help keep them in sync if there are other changes.

  This could be tricky. Currently -d4 option shows what is there in the main-memory, not validate the disk file.
Comment 14 Fedora Update System 2013-03-14 11:08:12 EDT
ndjbdns-1.05.7-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.7-1.fc17
Comment 15 Fedora Update System 2013-03-14 11:08:38 EDT
ndjbdns-1.05.7-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.7-1.fc18
Comment 16 Fedora Update System 2013-03-14 11:55:50 EDT
ndjbdns-1.05.7-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.7-1.el6
Comment 17 Fedora Update System 2013-03-14 11:56:58 EDT
ndjbdns-1.05.7-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.7-1.el5
Comment 18 Bob Gustafson 2013-03-14 12:57:53 EDT
(In reply to comment #13)
> 
> > The config read routines could be common to the daemons and to the tool - to
> > help keep them in sync if there are other changes.
> 
>   This could be tricky. Currently -d4 option shows what is there in the
> main-memory, not validate the disk file.

Whatever is in main memory is what the daemons are using..

------

Also - on the difference in compiled size of 1.05.7 and 1.05.6 - I was looking at the tinydns sizes - tinydns did not have the -d4 option and so the size differences must be due to compile flags, symbol stripping, or better compiler used by the final Fedora polish people. (!!)
Comment 19 pjp 2013-03-14 14:00:51 EDT
(In reply to comment #18)
> Whatever is in main memory is what the daemons are using..

  Yep!

> Also - on the difference in compiled size of 1.05.7 and 1.05.6 - I was
> looking at the tinydns sizes - tinydns did not have the -d4 option and so
> the size differences must be due to compile flags, symbol stripping, or
> better compiler used by the final Fedora polish people. (!!)

  Yes, if you build from source, executables are compiled with `-g' option and are not stripped. The latest RPM install on my machine shows

$ cd /usr/sbin
$ ls -shc1 axfrdns dnscache rbldns tinydns walldns 
48K axfrdns
80K dnscache
40K rbldns
44K tinydns
36K walldns
Comment 20 Fedora Update System 2013-03-23 19:53:04 EDT
ndjbdns-1.05.7-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2013-03-23 20:04:12 EDT
ndjbdns-1.05.7-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2013-03-29 17:28:30 EDT
ndjbdns-1.05.7-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2013-03-29 17:31:03 EDT
ndjbdns-1.05.7-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.