OS13.1 DNS: External name resolution works, but absolutely no cooperation with the DHCP

Hi there,

both DHCP and DNS are working, but they are not working together at all. (Only Ipv4, disabled Ipv6 for security reasons)
The pc has 2 network cards set int the firewall : 1 internal and 1 external.

All dynamic LAN addresses are NOT delivered from the DHCP to the DNS. I have defined 2 zones and have set all those parameters. As the yast help was almost useless, I used a described procedure from an internet site … did not help.
I also found out that I can’t use the logging to file feature (Yast->Network Services->DNS->Logging) . I always get an error message afterwards if I want to log into anything else than into the system log:**
"Error occured while starting service named.
Error: " **
Well it looks like this error has not got yet his nubmer …

Here is a part of the systemlog concerning the DNS:

2014-02-04T14:52:01.774470+01:00 Obelix systemd[1]: Reloading LSB: Domain Name System (DNS) server, named.
2014-02-04T14:52:01.860217+01:00 Obelix named[6036]: Reloading name server BIND tput: No value for $TERM and no -T specified
2014-02-04T14:52:01.862687+01:00 Obelix named[6036]: Error: tput: No value for $TERM and no -T specified
2014-02-04T14:52:01.863691+01:00 Obelix named[6036]: Can not find /lib/YaST/SuSEconfig.functions!
2014-02-04T14:52:01.864392+01:00 Obelix named[6036]: This should not happen. Exiting.
2014-02-04T14:52:01.878408+01:00 Obelix named[4391]: received control channel command ‘reload’
2014-02-04T14:52:01.879151+01:00 Obelix named[4391]: loading configuration from ‘/etc/named.conf’
2014-02-04T14:52:01.879683+01:00 Obelix named[4391]: using default UDP/IPv4 port range: [1024, 65535]
2014-02-04T14:52:01.880121+01:00 Obelix named[4391]: using default UDP/IPv6 port range: [1024, 65535]
2014-02-04T14:52:01.881728+01:00 Obelix named[4391]: sizing zone task pool based on 5 zones
2014-02-04T14:52:01.887765+01:00 Obelix named[4391]: couldn’t add command channel ::1#953: address not available
2014-02-04T14:52:01.888309+01:00 Obelix named[4391]: the working directory is not writable
2014-02-04T14:52:01.890266+01:00 Obelix named[4391]: reloading configuration succeeded
2014-02-04T14:52:01.890929+01:00 Obelix named[4391]: reloading zones succeeded
2014-02-04T14:52:01.892528+01:00 Obelix named[6036]: server reload successful
2014-02-04T14:52:01.894271+01:00 Obelix named[6036]: …done
2014-02-04T14:52:01.898103+01:00 Obelix systemd[1]: Reloaded LSB: Domain Name System (DNS) server, named.
2014-02-04T14:52:01.899898+01:00 Obelix named[4391]: 127.0.0.zone:9: ignoring out-of-zone data (0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa)
2014-02-04T14:52:01.903999+01:00 Obelix named[4391]: zone 0.0.127.in-addr.arpa/IN: has no NS records
2014-02-04T14:52:01.904759+01:00 Obelix named[4391]: zone 0.0.127.in-addr.arpa/IN: not loaded due to errors.
2014-02-04T14:52:01.913663+01:00 Obelix named[4391]: all zones loaded
2014-02-04T14:52:01.915093+01:00 Obelix named[4391]: running

I have no idea what’s wrong, although it obviously seems to have problems.
My questions are now:

**1. **What’s $TERM ?
2. Why cant it find /lib/YaST/SuSEconfig.functions ?
3. And why couldn’t it add command channel ::1#953: address not available ?
**4. **Last but not least: Any idea why DCHP and DNS don’t work together ?

TIA and kind regards, Joe

Hello there,

I think I got the same problem, at a freh installed and updated openSuSE 12.3.

Greetings Franz

I report this Bug :
Bug 862182

Excellent idea !

Do you use a 32 or 64 bit version of OS 13.1 ?

Cheers , Joe

[update]: Playing around (all in Yast) with the dynamic updates in the DNS and the DNS Zones I somehow could reproduce the error I always thought to be a problem of the log.
The error without number and description appeared and I was afterwards asked whether I would like to change the setup or leave it unchanged.
The dynamic updates seem to be very picky.

I have good and a bad news !

The good ones first:

DHCP & DNS are now working together, as If they never have done something else … now all LAN PC’s can see each other.

**The bad news: **

You have to switch off the Application Armor (Yast → Security and Users → AppArmor config. ->Settings : Uncheck " Enable AppArmor "
I don’t know how important this armor thing really is … Well I guess we can switch it on sometime in the future when they have fixed this.

I thought that DHCP & DNS is software from the stone age of the internet and should be meanwhile rock solid. Thus I assumed that something else, something new is responsible for this strange behaviour. As only the communication between DHCP and DNS did not work, I was looking for something new and … voila, had the idea while having dinner :stuck_out_tongue:

Franz, I await your feedback. Would be really interesting to see whether this solves your problem too !

Greetings and good night , Joe

Am curious what is your result if you run the following on any machine which is throwing the $TERM error you described.

echo $TERM

on my 13.1 it results

xterm

I’m also not clear what your problem(s) might have been.

DHCP - Manages and allocates IP addresses when a DHCP client requests. Has nothing to do with name resolution… normally.
DNS - Manages hostname resolution by mapping IP addresses to hostnames. Has nothing to do with managing and allocating IP addresses.

In other words, ordinarily (not talking about special implementations) there is no relationship between the two services. One does one thing and the other does its own without any kind of integration.

It might also be relevant to verify this is a very generic BIND DNS install from the OSS repo and not a special implementation or installed (and configured) from some other source.

TSU

Hi TSU,

The result for “Echo $TERM” is “xterm” like on your computer.

As mentioned above I am using the Yast UI to configure both the DNS and the DHCP server. Thus your assumption that I was writing about a problem which appeared with the OpenSuse packaged servers is true.

Each server running alone is working without problem. But the DHCP needs to inform the DNS about those IP / name tuples it has created by allocating IP numbers for requesting PC’s.

I solved the problem by switching off the OpenSuse Application Armor feature, which obviously has a negative impact on the “Dynamic DNS” as it is called in the DHCP server. But I see this solution only as a temporary workaround and hope that one day I can switch on the “Application Armor” feature again.

I hope I herewith could explain the situation a bit better.

Thanks, Joe

Joe,
You’re expecting something which just isn’t there by default.

In a default setup, what you’re observing is exactly why the traditional (and still true more often than not) advice is that your Servers should never be configured with DHCP. More exactly, they should not be configured to be simple DHCP clients because as you’ve seen when/if the client’s IP address changes it’s no longer consistent with the information in DNS.

You can still use DHCP for your Servers (or any other machine which serves resources on your network), but in that case you should configure a Reserved Lease on your DHCP server. What this does is configure DHCP so that when it receives a request for a lease from a machine with a certain MAC address in its Reserved Leases table, it will always assign it the same IP address.

Only when you’re running some kind of Enterprise Network Management system will DHCP and DNS share information, but that is outside the scope of anyone who <only> installs DNS and DHCP.

HTH,
TSU

I am having a very similar problem at SUSE 12.3 as JOEeoj.

Using Yast to do the config of DNS and then DHCP, I am seeing what you described at first. I do not have apparmor on this system.

I too have two NICs. eth0 is for INT while eth1 is EXT.

When I start to tell DHCP to sync with the DNS, the drop down offered says “Create a new domain from scratch”. Once done with the wizzard for this you get to <finish> and it comes back with an error sayint that the domain doesn’t exist for it to replace.

Not doing a replace, creating the domain from scratch. Can’t get them to sync. Will look up the bug reported.

TSU2: Unless you know something the rest of us don’t…

Wylbur

Hi Wylbur,

I unfortunately never used OS 12.3 , so I can’t say what’s different between 12.3 and 13.1. But I can tell you what I did in 13.1 and hope it helps you and others a bit :
**
I assume that you have already conigured YAST->DNS and Yast->DHCP and its up and running (without Dynamic DNS) !

  1. **To enable communication between DHCP and DNS you have to create a TSIG keyfile first Goto Yast ->DNS -> TSIG Keys.
    Enter an arbitrary string as a key (like i.e. : 04871151 ) , set a path name for the file (i.e. “/etc/named.d/MyTSIGKey” and press the “Generate” key.

2. Select "DNS Zones ". Assuming that you don’t have a registered domain name, feel free to invent one for your LAN i.e. “MyLan”
Enter “MyLan” as Name in the form , select Master and click on Add. Edit the new entry in the tab “Basics” and “Allow Dynamic Update” and select your TSIG key: i.e. 04871151
I enabled any Zone Transport, although I don’t know whether it’s really needed or not. as I really couldn’t get a hint in the help and the internet. Select now NS Records and add the name of your server to the empty list. i.e “MyServer.MyLan.” (Important: Behind “MyLan” is a point !!!) . Then press OK to save this entry.

3. Now create a 2. Zone, the Reverse zone: Let’s assume you use the range 192.168.1.0/24 for your LAN. Then enter as name “1.168.192.in-addr.arpa” and create this zone also as Master. Edit the new entry: Check “Allow Dynamic Updates” , check “Enable Zone Transport” and “Any” and enable “Automatically generate records for” and enter your zone name (i.e. “MyLan”) Ensure that your server is also in the list in the NS records tab and press ok to save it.
**
4.** Got to Yast->DHCP . Set it to advanced mode (don’t remember whether it was really ‘advanced’ or was it ‘professional’ or … what so ever) (Attention: Once set, it can’t be switched back to normal mode in the Yast UI !) I assume that your DHCP is already fully configured (with exception of the dynamic DNS of course) thus look at “Configured Declarations” and select there the subnet entry ; double click. Now in the lower right corner a button “Dynamic DNS” appears. Click on it. Now enable Dynamic DNS and select in both, Forward and in the Reverse Zone your TSIG key (i.e. : 04871151) .
In Zone enter your Domain (i.e.“MyLan.”) (don’t forget that point after “MyLan” !) and enter your servers fixed IP address. In the reverse zone enter ther reverse zones name (i.e. “1.168.192.in-addr.arpa.”) And yes, again don’t forget that point trap after “arpa” and click on OK.

5. Ensure that in your server’s and Lan PC’s Yast->Network settings->Hostname/DNS the used Domain Name and Domain Search is your chossen domain name (i.e.“MyLan”) indeed. I have added a list of alternative name servers 2 servers so that I don’t depend on the DNS of my provider: 85.88.19.10 and 208.67.220.220.
Save it and now it should work if Yast->Securtiy and Users -> AppArmor ->Settings-> Enable AppArmor is** disabled. **

Hope it works for you too!

Greetings, Joe

On 2014-02-04 15:36, J0Eeoj wrote:

> *1. *What’s $TERM ?

Weird. Maybe it is not started in daemon mode.

> 2. Why cant it find /lib/YaST/SuSEconfig.functions ?

Because they were removed! Current openSUSE releases no longer have
SuSEconfig. Report that in Bugzilla.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

On 2014-02-04 21:46, J0Eeoj wrote:

> THE BAD NEWS:
> You have to switch off the Application Armor (Yast → Security and Users
> → AppArmor config. ->Settings : Uncheck " Enable AppArmor "
> I don’t know how important this armor thing really is … Well I guess
> we can switch it on sometime in the future when they have fixed this.

Very important (sp for servers).

It will not be solved unless /you/ report that issue in bugzilla.

The apparmour issue is mentioned in the release notes. They tell we
should expect problems and please report them.

You can correct locally your profiles by running aa-logprof.

>
> I thought that DHCP & DNS is software from the stone age of the internet
> and should be meanwhile rock solid.

Well… considering that openSUSE puts named inside a chroot jail, no,
it is not rock solid.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

On 2014-02-05 20:16, tsu2 wrote:

> I’m also not clear what your problem(s) might have been.
>
> DHCP - Manages and allocates IP addresses when a DHCP client requests.
> Has nothing to do with name resolution… normally.
> DNS - Manages hostname resolution by mapping IP addresses to hostnames.
> Has nothing to do with managing and allocating IP addresses.

It is quite typical to have dhcpd forward the information about new and
extinguished leases to named so that machines in the network can find
one another. It is not used primarily for the servers in the network,
but for the clients.

You need this if setting an active directory setup, for instance.

You can also use dnsmasq instead of both bind and dhcpd, as it provides
both services simultaneously and should perhaps integrate better.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

Hi Carlos,

thanks for your answer.

I looked into BugZilla page. OpenSuse writes already on the frontpage :

  • Developers and experienced users:
    You can go directly to http://bugzilla.novell.com and report a bug.> - Non-technical users:
    You may try first http://forums.opensuse.org .> - Want to learn:
    It is not the easiest thing that you ever did, but it is not rocket science either. Please read the text below that has basic instructions how to report a bug.>

According to this suggestion I have made my 1.approach and have written about the problem in the forum (fulfilled the 2. point that OpenSuse suggested)
And yes, I am still in the process of reading what’s written in their 3 point, but feel, honestly said, a currently bit lost in doing all this. Guess its to early for me to report bugs, install debug repositories, send logs around which I even don’t know where to find them (though I would like to) .

I definitely want to help openSuse community forward, so I do my share and report in the forum until I am experienced enough to use this BugZilla (Huh, sounds like Godzilla, now I know why ;-).

Why don’t you report this bug?

Greetings, Joe

That was indeed a good hint: dnsmasq !!!

Was not aware that something like that exists and is supported by openSuse!
I hope it works together with the AppArmor feature … as it seems to be for OS 12.3 only.

Cheers, Joe

On 2014-02-10 14:16, J0Eeoj wrote:

>
> According to this suggestion I have made my 1.approach and have written
> about the problem in the forum (fulfilled the 2. point that OpenSuse
> suggested)
> And yes, I am still in the process of reading what’s written in their 3
> point, but feel, honestly said, a currently bit lost in doing all this.
> Guess its to early for me to report bugs, install debug repositories,
> send logs around which I even don’t know where to find them (though I
> would like to) .

You don’t need to add any debug repos. You just need to say what you are
trying to do, and that apparmour is blocking it. And a reference to this
thread.

The output of “aa-notify -l --verbose” might help them.

openSUSE:Submitting bug
reports

Once you report, they should ask you what further information they need.

> Why don’t you report this bug?

Because I don’t have the first hand information that you have. I’m not
using dhcpd and bind.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

On 2014-02-10 14:26, J0Eeoj wrote:

> _That_was_indeed_a_good_hint:_dnsmasq (“http://software.opensuse.org/package/dnsmasq”)!!!
>
> Was not aware that something like that exists and is supported by
> openSuse!
> I hope it works together with the AppArmor feature … as it seems to be
> for OS 12.3 only.

It is installed by default since 12.3 or earlier. 13.1 also has it.
Enabled, not activated, mind.

YaST does not support it. That is, you have to configure it by hand. But
for my uses, it seems much easier to handle than bind. Maybe it will be
handled by YaST on the future.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

Hi Carlos,

thanks for the information. Ok I will try to report that bug.

I am a Windows user as from WfW 3.11 (1993) and my last windows will be my current Win7 version (in a virtualbox)

Thus I am used to GUI and try to use Yast whenever possible. So it’s no wonder that I couldn’t find/see dnsmasq.

Will try it soon and report whether it works in OS 13.1 with AppArmor or not.

Thanks again, Joe

Ok I give up for now with that Godzilla monster … took me now nearly 2 hours and … no result.

It is not sufficient to have logged in into the forum, for Godzilla one has to log in Godzilla again. My forum pw is sent automaticall by the browser and I have meanwhile forgotten it. No problem, I thought, thats why the security question was invented. Well I cut the entire story down the end point: Godzilla does not know that I am logged in in the forum, but it knows that I requested for a new password and even knows the new pw, but now it wants me to “validate your email account” over and over again - seems to be in a loop.

Will try tomorrow a last time again. If it still messes around I wait until they have a new working Zilla (without Bug)…

Interesting, cool if it works!
After you posted, I took a look around on the Internet, apparently some instructions are out there that aren’t too old… typically using certificates as the shared secret instead of a string, but I can see how that might work.

Will setup a VM for testing…

TSU