Discussion:
what does 127.0.1.1 mean?
lynn
2012-03-29 17:34:29 UTC
Permalink
12.1
Hi
We have a bind nameserver for our 192 domain.

For a non static IP client I have to set the line:
127.0.1.1 hostname.domain hostname
in /etc/hosts otherwise hostname -f and lots of other stuff doesn't work.

1. Why?
2. What should the file /etc/HOSTNAME contain?
a. fqdn
b. hostname

Thanks,
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-29 18:43:03 UTC
Permalink
Post by lynn
12.1
Well it will depend on whether you are running systemd or sysvinit
... sort of
Post by lynn
Hi
We have a bind nameserver for our 192 domain.
And you have reverse lookup as well so that the FQDN of the machine
based on its 192.whatever IP address can be determined?
Post by lynn
127.0.1.1 hostname.domain hostname
in /etc/hosts
It really should be
127.0.0.1 localhost.localdomain localhost
which makes me think you have an error in you DNS config.

Do you have an entry in named.conf something like

zone "0.0.127.in-addr.arpa" IN {
type master;
file "reverse/named.localdomain";
allow-update { none; };
};

::::::::::::
reverse/named.localdomain
::::::::::::
$TTL 86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.


and a corresponding forward?

zone "localdomain" IN {
type master;
file "master/localdomain.zone";
allow-update { none; };
};


::::::::::::::
master/localdomain.zone
::::::::::::::
$TTL 86400
@ IN SOA localhost root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS localhost
localhost IN A 127.0.0.1
Post by lynn
otherwise hostname -f and lots of other stuff doesn't work.
1. Why?
2. What should the file /etc/HOSTNAME contain?
I don't use that, but perhaps you're thinking of "hostname -F ..." as in
Post by lynn
-F, --file filename
Read the host name from the specified file. Comments (lines starting with a ‘#') are ignored.
The manual says of "-f"
Post by lynn
-f, --fqdn, --long
Display the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and the DNS
domain name. Unless you are using bind or NIS for host lookups you can change the FQDN and the DNS
domain name (which is part of the FQDN) in the /etc/hosts file.
I'm sure that if you do a strace you'll find that the hostname command
tries using DNS first. The issue is does it try "0.0.0.0" or does it
try the ip address on Eth0 ?

So take a look at boot scripts and see which it uses.
Maybe it syslogs ....? Maybe it does a reverse lookup on /etc hosts and
plonks whatever it finds into /etc/HOSTNAME.

Maybe your problem is that its doing this before DHCP has assigned the
192. address and its using 127.0.0.1 instead ... perhaps because you're
doing a boot in parallel and this should be a sync point.

I haven't looked at how this works in systemd.


I'll admit that I have a central control view of things.
I've set up my DHCP/DNS so that it does it as "Oh, that's you MAC
address, well on *that* subnet, this is your IP address and this is your
name".
None of this nonsense about the host telling the DHCP server what name
it wants and what subnet it wants to be on ... Only static hosts (aka
servers) have that right ... well not really, they don't use DHCP :-)
If you're a visitor with an unrecognised address you get sandboxed.
If you try spoofing a MAC address .... lets not talk about that, I don't
want to give people ideas ...

Yes, there are other ways to do it all, but this one works.
--
"Conviction is worthless unless it is converted into conduct."
-- Thomas Carlyle.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-30 11:12:13 UTC
Permalink
Post by Anton Aylward
12.1
Well it will depend on whether you are running systemd or sysvinit
... sort of
systemd
Post by Anton Aylward
And you have reverse lookup as well so that the FQDN of the machine
based on its 192.whatever IP address can be determined?
No. It's straight from the box, as fas as it can be straight out of the
box on openSUSE, cache only but we have added the dlz for dynamic updates.
Post by Anton Aylward
It really should be
127.0.0.1 localhost.localdomain localhost
Setting only that does not work for, e.g. Kerberos realm lookups. In
particular, krb5 nfs mounts fail if the 127.0.1.1 address is not specified.
Post by Anton Aylward
which makes me think you have an error in you DNS config.
Everything else works fine. The dynamic updates included.
Post by Anton Aylward
Do you have an entry in named.conf something like
We have this:

options {
directory "/var/lib/named";
managed-keys-directory "/var/lib/named/dyn/";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
listen-on-v6 { any; };
notify no;
disable-empty-zone
"1.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";
include "/etc/named.d/forwarders.conf";
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
};
zone "." in {
type hint;
file "root.hint";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone
"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"
in {
type master;
file "127.0.0.zone";
};
include "/usr/local/samba/private/named.conf";

Nearly the weekend:-)
Cheers,
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-30 12:35:52 UTC
Permalink
Post by lynn
Post by Anton Aylward
And you have reverse lookup as well so that the FQDN of the machine
based on its 192.whatever IP address can be determined?
No. It's straight from the box, as fas as it can be straight out of the
box on openSUSE, cache only but we have added the dlz for dynamic updates.
Sorry: please clarify. Are you saying your DNS server is 'straight out
of the box'?

Have you tried the reverse lookup?
(Sorry this is complicated but its finding the IP address in a site
independent manner)

# dig -s $( ip addr show to 0.0.0.0/0 scope global | \
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )

That should give you the FQDN of your host.
Post by lynn
Post by Anton Aylward
It really should be
127.0.0.1 localhost.localdomain localhost
Setting only that does not work for, e.g. Kerberos realm lookups. In
particular, krb5 nfs mounts fail if the 127.0.1.1 address is not specified.
Having that setting is 'out of the box'.

The fact that Kerberos lookups don't work unless that is altered from
the default makes me think you have an incorrect setup. As you can see
below, properly set up, 127.0.0.1 *IS* there ... via DNS. And the
lookup of the Kerberos server should be done by DNS, and the lookup of
the NFS server(s) should be done by DNS. That's the point of having it
'centrally managed' and the distributed/replicated database that is DNS
(and LDAP for that matter!)

If you read the man page HOSTS(5) you;ll see it says

<quote>
The Berkeley Internet Name Domain (BIND) Server implements the Internet
name server for UNIX systems. It augments or replaces the /etc/hosts
file or hostname lookup, and frees a host from relying on /etc/hosts
being up to date and complete.
</quote>

Yes there is the proviso for bootstrapping and yes you can buqqer this
up by a mistake in /etc/nsswitch. Yes there is the provision for
standalone.

But if your machine is using /etc/hosts to do reverse lookup or to find
the address of servers then either
a) your DNS has failed, or
b) your DNS is misconfigured.

The latter could be because
a) /etc/nsswitch is wrong
b) information handed back by the DHCP server is wrong or inadequate
c) your DNS is not set up correctly





I'm skipping your named.conf.
You can use nslookup, host or dig to test your DNS from this box.

Before any network mount, any other stuff to do with networking, the
machines needs an IP address. Its getting that either from DHCP or its
hard wired. The ifconfig tool will tell you what the address is.

You should be able to use the DNS lookup tools (see above) to do a
reverse lookup of that IP address. It should make use of the DNS server
if you have /etc/resolve set properly (either via DHCP or manually).
Using the debug option will tell you how the DNS server is being
interrogated.

You should get something like this.
It is from my redhat w/s which uses DHCP and my dns server is at .18

# dig -x 127.0.0.1

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc15 <<>> -x 127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5784
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 86400 IN PTR localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 86400 IN NS localhost.

;; ADDITIONAL SECTION:
localhost. 86400 IN A 127.0.0.1

;; Query time: 30 msec
;; SERVER: 192.168.2.18#53(192.168.2.18)
;; WHEN: Fri Mar 30 07:49:50 2012
;; MSG SIZE rcvd: 93

Note that this is querying the DNS server, not /etc/hosts.
Post by lynn
Post by Anton Aylward
which makes me think you have an error in you DNS config.
Everything else works fine. The dynamic updates included.
In some ways networking is very tolerant of minor errors and has
fallbacks (that's the point of /etc/nsswitch)

That your routing and DNS lets you access google and youtube and msn and
facebook doesn't mean that you have *any* reverse lookup set up correctly.

The fact that your /etc/hosts settings are used for reverse lookup tells
me that the DNS reverse lookup isn't working or isn't being used. The
latter emerges from how /etc/nsswitch is set.

But a running system (aka 'after a successful boot and network start-up)
with properly set up DNS etc shouldn't need /etc/hosts.

OK so there are a pile of 'yes-buts' people are going to argue with on
this. One I've seen is to set /etc/nsswitch to use 'files dns' for
host lookup on the basis that file lookup is faster than DNS lookup.
OK, but that's if and but; it says nothing about caching, it says
nothing about correctness and maintenance. The point is that you
*should* be able run without /etc/hosts. See the man page, as I quoted.

The fact that you can't, the fact that you have to jimmy stuff in there
to make it work, tells me something is wrong, and I suspect the DNS side
of things.
--
Think then act - There is nothing so useless as doing efficiently that
which should not be done at all
- Peter Drucker.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2012-03-30 15:15:31 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Anton Aylward
Have you tried the reverse lookup?
(Sorry this is complicated but its finding the IP address in a site
independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host.
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
Invalid option: -s
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]

Use "dig -h" (or "dig -h | more") for complete list of options


- --
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEUEARECAAYFAk91zhMACgkQIvFNjefEBxqrUQCfQspPPHICXoSzpZDY63VsjVES
tRMAkwT+vA0pkkEokAhmrOY4XG03Tug=
=MRK4
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-30 17:16:22 UTC
Permalink
Post by Carlos E. R.
Have you tried the reverse lookup? (Sorry this is complicated
but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk
'/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host.
\
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
Invalid option: -s
Sorry, my finger slipped. s is next to x ...


As the man page makes clear, reverse lookup is "-x".

I'm sure everyone is smart enough ...
--
We are born naked, wet and hungry. Then things get worse.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2012-03-30 18:04:17 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Anton Aylward
Post by Carlos E. R.
Invalid option: -s
Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
When you know the idea, yes, perhaps. I didn't.

- --
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk919aEACgkQIvFNjefEBxqAagCdHudj1WpJv69fPX3QcYEKTA1D
VuQAoJds4nm8v0AUnXNNKYP3/KMxItYB
=bQQi
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-30 19:28:27 UTC
Permalink
Post by Anton Aylward
Post by Carlos E. R.
Have you tried the reverse lookup? (Sorry this is complicated
but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk
'/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host.
\
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
Invalid option: -s
Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
Nope. Not working.
I just added the reverse zone in Yast but there seems to be a conflict
between it and the samba4 dlz stuff we're running.

dig -x $( ip addr show to 0.0.0.0/0 scope global | awk '/[[:space:]]inet
/ { print gensub("/.*","","g",$2) }' )
berized nfs
; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56925
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;3.1.168.192.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa. 86400 IN SOA 168.192.in-addr.arpa. . 0
28800 7200 604800 86400

;; Query time: 24 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Fri Mar 30 21:19:19 2012
;; MSG SIZE rcvd: 77

My workaround is to add the 127.0.1.1 as. I only need it for really
fussy dns stuff like Kerberos with nfs where if you so much as breathe,
bind just turns away.

I'm glad to see the Samba4 guys working on a modern replacement for bind.
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-30 22:21:19 UTC
Permalink
Post by lynn
Post by Anton Aylward
Post by Carlos E. R.
Have you tried the reverse lookup? (Sorry this is complicated
but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk
'/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host.
\
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
Invalid option: -s
Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
Nope. Not working.
Right
Post by lynn
I just added the reverse zone in Yast but there seems to be a conflict
between it and the samba4 dlz stuff we're running.
Could you explain what the 'conflict' is, how it manifests and a little
of what's going on behind the scenes?

The point I'm making here is that you need a complete and working
'spanning set'. Just parts of it working aren't going to be enough.
Post by lynn
dig -x $( ip addr show to 0.0.0.0/0 scope global | awk '/[[:space:]]inet
/ { print gensub("/.*","","g",$2) }' )
berized nfs
; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.3
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56925
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;3.1.168.192.in-addr.arpa. IN PTR
168.192.in-addr.arpa. 86400 IN SOA 168.192.in-addr.arpa. . 0
28800 7200 604800 86400
;; Query time: 24 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Fri Mar 30 21:19:19 2012
;; MSG SIZE rcvd: 77
Right.
This shows the reverse for 192.168.1.3 isn't working and I'd assume from
that for the whole of your 192.168.1/24 subnet.

This has nothing to do with the reverse lookup of 127.0.0.1, which you
might like to try as well: :-)

# dig -x 127.0.0.1

I suspect that this has more to do with your problems than anything else.
Post by lynn
My workaround is to add the 127.0.1.1 as. I only need it for really
fussy dns stuff like Kerberos with nfs where if you so much as breathe,
bind just turns away.
I've known many applications where there is a security check - given an
IP address, do a backward lookup to get the name, then do a forward
lookup to get the IP address for that name. Is the address you started
out with the same as the one you ended up with? If not, something is
wrong. If this is the case with the "fussy dns stuff like kerberos"
then the failed reverse lookup you reported is a source of your problems.
Post by lynn
I'm glad to see the Samba4 guys working on a modern replacement for bind.
There are number of 'replacements' - that is there are a number of other
pieces of code that implement the protocol of the DNS server.
BIND may have problems but these are not it. I suspect that if you used
one of the alternatives to BIND you might find the configuration easier.
I'm biased; I've been using BIND since 1990 so I'm used to it, but as I
say, there's interaction with nsswitch and DHCP to consider.
You are updating your DNS from DHCP, aren't you? If not then there's a
possible source of your problems!
http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/


See
http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software#Feature_matrix
for how crippled some of the alternatives are!

The best (?) of the bunch is probably
http://cr.yp.to/djbdns.html
I've not used it; I find Daniels code and commentary to be confusing.

On the whole I recommend the Cricket Lui book from O'Reilly.
--
How come wrong numbers are never busy?
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-31 07:17:24 UTC
Permalink
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by Carlos E. R.
Have you tried the reverse lookup? (Sorry this is complicated
but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk
'/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host.
\
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
Invalid option: -s
Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
Nope. Not working.
Right
Post by lynn
I just added the reverse zone in Yast but there seems to be a conflict
between it and the samba4 dlz stuff we're running.
Could you explain what the 'conflict' is, how it manifests and a little
of what's going on behind the scenes?
The point I'm making here is that you need a complete and working
'spanning set'. Just parts of it working aren't going to be enough.
Hi
Yes. I can explain the conflict now.
My Samba4 dynamic dns configuration was creating the forward zone for me
so by adding my own it was conflicting with the zone that was already
loaded. DUH! I only needed to add the _forward_ zone myself as the A
record was already there.

Anton, could you be an absolute darling and have a look through this for
me? I think it's working now but I need expert opinion before I take it
to the production lan.

The server has fqdn hh3.hh3.site at 192.168.1.3

Here is the log showing samba creating the forward zone and then loading
my reverse zone:

Mar 31 08:47:46 hh3 named[9900]: Loading 'AD DNS Zone' using driver dlopen
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: started for DN DC=hh3,DC=site
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: starting configure
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: configured writeable zone
'hh3.site'
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: configured writeable zone
'_msdcs.hh
3.site'
Mar 31 08:47:46 hh3 named[9900]: zone 1.168.192.in-addr.arpa/IN: loaded
serial 2012033101

Here is my reverse zone (created by Yast):

cat /var/lib/named/master/1.168.192.in-addr.arpa
$TTL 2d
@ IN SOA hh3.hh3.site. root.hh3.hh3.site. (
2012033101 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1d ) ; minimum
1.168.192.in-addr.arpa. IN NS hh3.hh3.site.
3 IN PTR hh3.hh3.site.

Here is /etc/named.conf
grep -v "#" /etc/named.conf

options {
directory "/var/lib/named";
managed-keys-directory "/var/lib/named/dyn/";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
listen-on-v6 { any; };
notify no;
disable-empty-zone
"1.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";
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
include "/etc/named.d/forwarders.conf";
};
zone "." in {
type hint;
file "root.hint";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone
"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"
in {
type master;
file "127.0.0.zone";
allow-transfer { any; };
};
include "/etc/named.conf.include";
logging {
category default { log_syslog; };
channel log_syslog { syslog; };
};
zone "1.168.192.in-addr.arpa" in {
allow-transfer { any; };
file "master/1.168.192.in-addr.arpa";
type master;
};
include "/usr/local/samba/private/named.conf";

And here is the dig:
dig -x 192.168.1.3

; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53998
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;3.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
3.1.168.192.in-addr.arpa. 172800 IN PTR hh3.hh3.site.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 172800 IN NS hh3.hh3.site.

;; ADDITIONAL SECTION:
hh3.hh3.site. 900 IN A 192.168.1.3

;; Query time: 10 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Sat Mar 31 09:01:51 2012
;; MSG SIZE rcvd: 98


Notes:
Changes made to the 12.1 bind to get rid of the startup errors:
chown named:named /var/lib/named (working directory not writable)
touch /var/lib/dyn/managed-keys.bind (file does not exist)
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle
transferring the samba dlz stuff to the jail)

Still can't lose this error:
Mar 31 08:47:46 hh3 named[9900]: couldn't add command channel ::1#953:
address n
ot available

The Yast DNS module is not easy to use. Do you think it would be helpful
if I wrote a howto for it? There is one here:
http://www.pcc-services.com/sles/dns3.html
but it's not correct.
Cheers, TIA and have a great weekend,
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2012-03-31 10:30:16 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You got me curious as to how you did that. I did a DNS with YaST, created
my zone, and only saw the forward files, no reverse. I created them
manually with an editor. If you did it with YaST, how? :-?

By the way, my method to know if the DNS entries are right is testing each
address, one by one... like this:

host 192.168.1.1
host 192.168.1.3
Post by lynn
chown named:named /var/lib/named (working directory not writable)
You are right, I had to do that too. That's bugzilla matter, by the way ;-)
Post by lynn
touch /var/lib/dyn/managed-keys.bind (file does not exist)
Dunno, I was not using dynamic.
Post by lynn
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle transferring the samba dlz stuff to the jail)
I also did that, I did not know what was going wrong, so I removed the jail
to have a class of issues less. Then I did not try to reinstate it back.
Post by lynn
The Yast DNS module is not easy to use.
An understatement :-)

- --
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk923LgACgkQIvFNjefEBxrVGACdH2pf+b7wtF8I4BoQUJeE132k
3HcAoMd3WHRXomzTLRxNRvtonbN8BJ2h
=Kd8D
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-31 11:28:38 UTC
Permalink
Post by Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You got me curious as to how you did that. I did a DNS with YaST, created
my zone, and only saw the forward files, no reverse. I created them
manually with an editor. If you did it with YaST, how? :-?
The main problem with manually writing the zone files is that ridiculous
syntax. Yast doesn't let miss a single punto:
http://linuxcostablanca.blogspot.com.es/2012/03/opensuse-using-yast-to-setup-dns.html
Post by Carlos E. R.
By the way, my method to know if the DNS entries are right is testing each
host 192.168.1.1
host 192.168.1.3
host 192.168.1.3
3.1.168.192.in-addr.arpa domain name pointer hh3.hh3.site.

or dig;-)
Post by Carlos E. R.
Post by lynn
chown named:named /var/lib/named (working directory not writable)
You are right, I had to do that too. That's bugzilla matter, by the way ;-)
bugzilla 738156 and 738258 The maintainer will not accept that this is a
bug.
Post by Carlos E. R.
Post by lynn
touch /var/lib/dyn/managed-keys.bind (file does not exist)
Dunno, I was not using dynamic.
Again. The bugzilla says it's fixed but it isn't.
Post by Carlos E. R.
Post by lynn
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle transferring the samba dlz stuff to the jail)
I also did that, I did not know what was going wrong, so I removed the jail
to have a class of issues less. Then I did not try to reinstate it back.
I don't think we gain much by having it apart from more hassle.
Post by Carlos E. R.
Post by lynn
The Yast DNS module is not easy to use.
An understatement :-)
If you know how to write a zone file this makes it easier to get the
syntax right first time.
HTH
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-31 12:36:55 UTC
Permalink
Post by lynn
Hi
Yes. I can explain the conflict now.
My Samba4 dynamic dns configuration was creating the forward zone for me
so by adding my own it was conflicting with the zone that was already
loaded. DUH! I only needed to add the _forward_ zone myself as the A
record was already there.
Ah.
I'm glad you found that.
I'm glad because I have no experience or insight into Samba*4*.
I use a simplified samba3; the on;ly time I bring a early W/Xp out of
the closet it to run MS-Money/97 and I fire up samba on a server so I
can print out stuff for my accountant. Its a once a year event and my
samba needs are not great.
Post by lynn
Anton, could you be an absolute darling and have a look through this for
me? I think it's working now but I need expert opinion before I take it
to the production lan.
The server has fqdn hh3.hh3.site at 192.168.1.3
Now *that* I would put in /etc/host!
Actually it should be supplied by DHCP but my experience is that
many/some machines don't always honour all of

option log-servers
option lpr-servers
option time-servers
option smtp-server
option netbios-name-servers


I'd recommend reading
http://www.cymru.com/Documents/secure-bind-template.html
which is what I've based my home network on.
Its simple and clear and well explained.
Post by lynn
Here is the log showing samba creating the forward zone and then loading
Mar 31 08:47:46 hh3 named[9900]: Loading 'AD DNS Zone' using driver dlopen
Ouch! Samba stuff. I'm out of my depth with this :-(
Post by lynn
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: started for DN DC=hh3,DC=site
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: starting configure
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: configured writeable zone
'hh3.site'
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: configured writeable zone
'_msdcs.hh
3.site'
Mar 31 08:47:46 hh3 named[9900]: zone 1.168.192.in-addr.arpa/IN: loaded
serial 2012033101
cat /var/lib/named/master/1.168.192.in-addr.arpa
$TTL 2d
@ IN SOA hh3.hh3.site. root.hh3.hh3.site. (
2012033101 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1d ) ; minimum
1.168.192.in-addr.arpa. IN NS hh3.hh3.site.
3 IN PTR hh3.hh3.site.
Now you *may* have a problem here.

[Sidebar: I'm assuming that yast created such a minimalist
zone file because that was all it could see, just the
local machine.
If you google, you'll find there are many tools (often written
in perl or shell) for generating zone files.
]

I'm assuming that your other machines - workstations ? - are also on the
192.168.1/24 subnet and have addresses assigned by DHCP.

There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries. Its another
thing to have to get exactly right.
http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_02.htm
http://www.sghaida.com/dhcp-bind-dynamic-updates/
and this mentions a few important 'secrets'
http://hackerific.net/2007/12/24/dynamic-dns-with-dhcp-and-bind-9/

When you report
address not available

Well that's what its talking about, but it looks like that involves IPv6.
To be honest, once IPv6 comes into play with ddns things get a bit
complicated, especially of you're not using IPv6 in the first place :-)


The other way to deal with workstation addresses is a bit of a cheat,
but its easy and it works and in a constrained small system as opposed
to a multi-segment, multi-server campus, I'm not going to argue. I use
it for my home system, a few machines around the house, a couple of
laptops, toys ... wifi on the patio ...

Basically you pre-load the reverse domain to match the addresses DHCP
can supply.

So if your DHCP says

subnet 192.168.1.0 netmask 255.255.255.127 {
authoritative;
range dynamic-bootp 192.168.1.32 192.168.1.64 ;

Then you can load up you reverse zone with

32 IN PTR ws32.hh3.site.
33 IN PTR ws33.hh3.site.
...
64 IN PTR ws64.hh3.site.


Actually if you're really good and have the upper levels set correctly,
you can use a lot of shorthand and only need lines like

32 IN PTR ws32


:-) But heck, belt and braces approach never hurt!
Post by lynn
Here is /etc/named.conf
grep -v "#" /etc/named.conf
Filtering out comments .... after reading mine, go back and read what
you didn't show!
Post by lynn
options {
directory "/var/lib/named";
managed-keys-directory "/var/lib/named/dyn/";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
All those should be writeable by named.
Post by lynn
listen-on-v6 { any; };
WHOA! listen-on-v6 turns on BIND to listen for IPv6 queries.
If you're not running IPv6 then you want "none" rather than "any".
This may account for one error :-)

See http://www.zytrax.com/books/dns/ch7/hkpng.html
Post by lynn
notify no;
disable-empty-zone
"1.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";
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
include "/etc/named.d/forwarders.conf";
That may or may not produce more ....
Post by lynn
};
zone "." in {
type hint;
file "root.hint";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone
"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"
If you're not using IPv6 then you might consider removing all such
references.
Post by lynn
in {
type master;
file "127.0.0.zone";
allow-transfer { any; };
Why?
Post by lynn
};
include "/etc/named.conf.include";
Again, an 'include' may alter things dramatically!
Post by lynn
logging {
category default { log_syslog; };
channel log_syslog { syslog; };
};
zone "1.168.192.in-addr.arpa" in {
allow-transfer { any; };
Why?
Post by lynn
file "master/1.168.192.in-addr.arpa";
type master;
};
include "/usr/local/samba/private/named.conf";
Again, an 'include' may alter things dramatically!
Post by lynn
chown named:named /var/lib/named (working directory not writable)
:-)
Post by lynn
touch /var/lib/dyn/managed-keys.bind (file does not exist)
No, that needs to contain the crypto key used by ddns.
Post by lynn
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle
transferring the samba dlz stuff to the jail)
I can see that; I'm not going to harp on abut "basic security".
I chroot so I know I can, but if you can justify not needing to
then its "no harm, no foul".
Post by lynn
The Yast DNS module is not easy to use. Do you think it would be helpful
http://www.pcc-services.com/sles/dns3.html
but it's not correct.
There are so many tools out there that do all this a help page might
read "use these instead"!

Check out named-checkconf and named-checkzone
and have a look at named-compilezone
--
Hardware has grown following Moore's Law; software seems to be stuck
with Gresham's Law.
- Jim Horning, Inside Risks 133
CACM 44, 7, July 2001
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-31 15:36:23 UTC
Permalink
Post by Anton Aylward
Post by lynn
Hi
Yes. I can explain the conflict now.
My Samba4 dynamic dns configuration was creating the forward zone for me
so by adding my own it was conflicting with the zone that was already
loaded. DUH! I only needed to add the _forward_ zone myself as the A
record was already there.
Correction: I meant _reverse_ zone of course. It is the forward zone
tyat is already there.
Post by Anton Aylward
Ah.
I'm glad you found that.
I'm glad because I have no experience or insight into Samba*4*.
It's not out of alpha yet but it's an amazing piece of kit. It helps
enormously with sso on heterogeneous lans.
Post by Anton Aylward
Post by lynn
The server has fqdn hh3.hh3.site at 192.168.1.3
Now *that* I would put in /etc/host!
OK. copy:
192.168.1.3 hh3.hh3.site hh3
Post by Anton Aylward
Actually it should be supplied by DHCP but my experience is that
many/some machines don't always honour all of
cat /var/lib/named/master/1.168.192.in-addr.arpa
$TTL 2d
@ IN SOA hh3.hh3.site. root.hh3.hh3.site. (
2012033101 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1d ) ; minimum
1.168.192.in-addr.arpa. IN NS hh3.hh3.site.
3 IN PTR hh3.hh3.site.
Now you *may* have a problem here.
[Sidebar: I'm assuming that yast created such a minimalist
zone file because that was all it could see, just the
local machine.
If you google, you'll find there are many tools (often written
in perl or shell) for generating zone files.
]
I'm assuming that your other machines - workstations ? - are also on the
192.168.1/24 subnet and have addresses assigned by DHCP.
Do I need a PTR for each computer on the lan?
Post by Anton Aylward
There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.
Yes. That's what we have. that's what the samba4 guys added to bind9 to
get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server. It works ok but coming back to the original
point, we have to put 127.0.1.1 in /etc/hosts on the client to get a
name over to the server.
Post by Anton Aylward
Its another
thing to have to get exactly right.
http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_02.htm
http://www.sghaida.com/dhcp-bind-dynamic-updates/
and this mentions a few important 'secrets'
http://hackerific.net/2007/12/24/dynamic-dns-with-dhcp-and-bind-9/
When you report
address not available
Well that's what its talking about, but it looks like that involves IPv6.
To be honest, once IPv6 comes into play with ddns things get a bit
complicated, especially of you're not using IPv6 in the first place :-)
The IPv6 stuff come straight out of a default openSUSE bind install. I
don't want it. It just gets put here.
Post by Anton Aylward
The other way to deal with workstation addresses is a bit of a cheat,
but its easy and it works and in a constrained small system as opposed
to a multi-segment, multi-server campus, I'm not going to argue. I use
it for my home system, a few machines around the house, a couple of
laptops, toys ... wifi on the patio ...
Basically you pre-load the reverse domain to match the addresses DHCP
can supply.
So if your DHCP says
subnet 192.168.1.0 netmask 255.255.255.127 {
authoritative;
range dynamic-bootp 192.168.1.32 192.168.1.64 ;
Then you can load up you reverse zone with
32 IN PTR ws32.hh3.site.
33 IN PTR ws33.hh3.site.
...
64 IN PTR ws64.hh3.site.
Actually if you're really good and have the upper levels set correctly,
you can use a lot of shorthand and only need lines like
32 IN PTR ws32
:-) But heck, belt and braces approach never hurt!
Post by lynn
Here is /etc/named.conf
grep -v "#" /etc/named.conf
Filtering out comments .... after reading mine, go back and read what
you didn't show!
Post by lynn
options {
directory "/var/lib/named";
managed-keys-directory "/var/lib/named/dyn/";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
All those should be writeable by named.
Yes. Infact if the whole of /var/lib/named is not writeable by named,
named will not start. the maintainers will not change this however. Pls
see the other post for details of the bugzillas.
Post by Anton Aylward
Post by lynn
listen-on-v6 { any; };
WHOA! listen-on-v6 turns on BIND to listen for IPv6 queries.
If you're not running IPv6 then you want "none" rather than "any".
This may account for one error :-)
Yes it does. Again, it is default openSUSE.
Post by Anton Aylward
See http://www.zytrax.com/books/dns/ch7/hkpng.html
Post by lynn
notify no;
disable-empty-zone
"1.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";
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
include "/etc/named.d/forwarders.conf";
That may or may not produce more ....
No that's fine. The only error now is here:
Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named
Mar 31 17:25:44 hh3 named[2483]: built with '--prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--localstatedir=/var' '--libdir=/usr/lib'
'--includedir=/usr/include/bind' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-openssl' '--enable-threads'
'--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql'
'--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing'
'LDFLAGS=-L/usr/lib'
Mar 31 17:25:44 hh3 named[2483]: adjusted limit on open files from 4096
to 1048576
Mar 31 17:25:44 hh3 named[2483]: found 1 CPU, using 1 worker thread
Mar 31 17:25:44 hh3 named[2483]: using up to 4096 sockets
Mar 31 17:25:44 hh3 named[2483]: loading configuration from
'/etc/named.conf'
Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file
'/etc/bind.keys'
Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv4 port range:
[1024, 65535]
Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv6 port range:
[1024, 65535]
Mar 31 17:25:44 hh3 named[2483]: listening on IPv6 interfaces, port 53
Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface lo,
127.0.0.1#53
Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface eth1,
192.168.1.3#53
Mar 31 17:25:44 hh3 named[2483]: generating session key for dynamic DNS
Mar 31 17:25:44 hh3 named[2483]: sizing zone task pool based on 5 zones
Mar 31 17:25:44 hh3 named[2483]: Loading 'AD DNS Zone' using driver dlopen
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: started for DN DC=hh3,DC=site
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: starting configure
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone
'hh3.site'
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone
'_msdcs.hh3.site'
Mar 31 17:25:47 hh3 named[2483]: set up managed keys zone for view
_default, file '/var/lib/named/dyn//managed-keys.bind'
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 10.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 16.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 17.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 18.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 19.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 20.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 21.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 22.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 23.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 24.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 25.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 26.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 27.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 28.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 29.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 30.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 31.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 168.192.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 0.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 127.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 254.169.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone:
100.51.198.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone:
113.0.203.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone:
255.255.255.255.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone:
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.0.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: D.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 9.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: A.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: B.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone:
8.B.D.0.1.0.0.2.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: command channel listening on 127.0.0.1#953
Mar 31 17:25:47 hh3 named[2483]: couldn't add command channel ::1#953:
address not available
Mar 31 17:25:47 hh3 named[2483]: zone 0.0.127.in-addr.arpa/IN: loaded
serial 42
Mar 31 17:25:47 hh3 named[2483]: zone 1.168.192.in-addr.arpa/IN: loaded
serial 2012033101
Mar 31 17:25:47 hh3 named[2483]: zone
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/IN:
loaded serial 42
Mar 31 17:25:47 hh3 named[2483]: zone localhost/IN: loaded serial 42
Mar 31 17:25:47 hh3 named[2483]: managed-keys-zone ./IN: loaded serial 0
Mar 31 17:25:47 hh3 named[2450]: Starting name server BIND ..done
Mar 31 17:25:47 hh3 named[2483]: running

This is after changing ownership of /var/lib/named and after creating he
managed-keys.bind file. Without those changes, bind will not start.
Post by Anton Aylward
Post by lynn
};
zone "." in {
type hint;
file "root.hint";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone
"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"
If you're not using IPv6 then you might consider removing all such
references.
the ip6.arpa one no?
Post by Anton Aylward
Post by lynn
in {
type master;
file "127.0.0.zone";
allow-transfer { any; };
Why?
This is what the default install did.
Post by Anton Aylward
Post by lynn
};
include "/etc/named.conf.include";
Again, an 'include' may alter things dramatically!
Default again. named.conf.include is empty.
Post by Anton Aylward
Post by lynn
logging {
category default { log_syslog; };
channel log_syslog { syslog; };
Default openSUSE.
Post by Anton Aylward
Post by lynn
};
zone "1.168.192.in-addr.arpa" in {
allow-transfer { any; };
Why?
This is for reverse lookup. This is what I added. Without it, reverse
lookup does not work.
Post by Anton Aylward
Post by lynn
file "master/1.168.192.in-addr.arpa";
type master;
};
Reverse lookup added by myself.
Post by Anton Aylward
Post by lynn
the samba 4 dlz stuff.
include "/usr/local/samba/private/named.conf";
Again, an 'include' may alter things dramatically!
This is working OK. It's he samba4 dlz stuff
Post by Anton Aylward
Post by lynn
chown named:named /var/lib/named (working directory not writable)
:-)
Post by lynn
touch /var/lib/dyn/managed-keys.bind (file does not exist)
No, that needs to contain the crypto key used by ddns.
Unless that file exists, it throws an error.
Post by Anton Aylward
Post by lynn
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle
transferring the samba dlz stuff to the jail)
I can see that; I'm not going to harp on abut "basic security".
I chroot so I know I can, but if you can justify not needing to
then its "no harm, no foul".
Yes. The samba include file must be readable. In the chroot it can't be
read. I can't find a way of making it work in the chroot without
including most of the samba stuff in there too.
Post by Anton Aylward
Post by lynn
The Yast DNS module is not easy to use. Do you think it would be helpful
http://www.pcc-services.com/sles/dns3.html
but it's not correct.
There are so many tools out there that do all this a help page might
read "use these instead"!
Check out named-checkconf and named-checkzone
and have a look at named-compilezone
Will do.
Meanwhile, one important one. I need to add a PTR for each machine on
the lan?
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-31 16:59:30 UTC
Permalink
Post by lynn
Do I need a PTR for each computer on the lan?
I can imagine circumstance where the answer to that is 'no' but I
suspect those circumstances don't apply to you.

If you had ddns working then it would be done 'auto-magically'.
Post by lynn
Post by Anton Aylward
There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.
Yes. That's what we have. that's what the samba4 guys added to bind9 to
Was it the Samba guys?
I thought DDNS (RFC2136 et al [3007, 4033, 4034, 4035]) dates back to
1997 and was out of ISC edited by the proverbial Mr Vixie :-)

Yes, Microsoft and Ad integrated DDNS and brought in the modified
version of kerberos, but that still doesn't make it a SAMBA initiative.

You can experiment manually adding records from the CLI with 'nsupdate'.
Post by lynn
get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server.
That's the server running under Linux?
Post by lynn
It works ok but coming back to the original
point, we have to put 127.0.1.1 in /etc/hosts on the client to get a
name over to the server.
What is the server in need of? The FQDN?
The FQDN should come from the unique IP address of the client.
That's why I keep talking about the reverse DNS.

I assume we're still talking about something that DHCP-driven?

Either the name is hard-coded or its supplied by the DHCP server and the
DHCP server tells the DNS server (via the DDNS protocol) to create the
forward and reverse records.

I _suspect_ that because there is no reverse record it falls back to
127.0.0.1 and that's what your faced with. I've not used kerberos in
this context; my last venture using it was with AIX/SPSS ....
Post by lynn
The IPv6 stuff come straight out of a default openSUSE bind install. I
don't want it. It just gets put here.
NASTY!

In the screens you show at the bloc ...
opensuse-using-yast-to-setup-dns.html there is the option to delete the
IPV6 entry and the option to enable DDNS
Post by lynn
Post by Anton Aylward
Post by lynn
listen-on-v6 { any; };
WHOA! listen-on-v6 turns on BIND to listen for IPv6 queries.
If you're not running IPv6 then you want "none" rather than "any".
This may account for one error :-)
Yes it does. Again, it is default openSUSE.
I think its up to you to delete what isn't wanted and to enable what is
wanted.
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: built with '--prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--localstatedir=/var' '--libdir=/usr/lib'
'--includedir=/usr/include/bind' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-openssl' '--enable-threads'
'--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql'
'--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing'
'LDFLAGS=-L/usr/lib'
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: adjusted limit on open files from 4096
to 1048576
Mar 31 17:25:44 hh3 named[2483]: found 1 CPU, using 1 worker thread
Mar 31 17:25:44 hh3 named[2483]: using up to 4096 sockets
Mar 31 17:25:44 hh3 named[2483]: loading configuration from
'/etc/named.conf'
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file
'/etc/bind.keys'
Yes but I recall there isn't actual a key, there , is there?

Building the key and including it in DNS/DHCP was an option on those
screens at the blog which you didn't take. Perhaps you should have ..
Post by lynn
[1024, 65535]
[1024, 65535]
Mar 31 17:25:44 hh3 named[2483]: listening on IPv6 interfaces, port 53
Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface lo,
127.0.0.1#53
Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface eth1,
192.168.1.3#53
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: generating session key for dynamic DNS
Mar 31 17:25:44 hh3 named[2483]: sizing zone task pool based on 5 zones
Mar 31 17:25:44 hh3 named[2483]: Loading 'AD DNS Zone' using driver dlopen
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: started for DN DC=hh3,DC=site
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: starting configure
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone
'hh3.site'
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone
'_msdcs.hh3.site'
Mar 31 17:25:47 hh3 named[2483]: set up managed keys zone for view
_default, file '/var/lib/named/dyn//managed-keys.bind'
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 10.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 16.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 17.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 18.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 19.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 20.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 21.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 22.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 23.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 24.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 25.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 26.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 27.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 28.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 29.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 30.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 31.172.IN-ADDR.ARPA
That doesn't matter, its all info not err
Post by lynn
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 168.192.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 0.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 127.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 254.169.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
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.0.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: D.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 9.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: A.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: B.E.F.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
You really should disable IPv6 if you're not using it.
Post by lynn
Mar 31 17:25:47 hh3 named[2483]: command channel listening on 127.0.0.1#953
Info, but its the local IP address that counts :-
Post by lynn
address not available
More IPv6 stuff you can do without.
Post by lynn
Mar 31 17:25:47 hh3 named[2483]: zone 0.0.127.in-addr.arpa/IN: loaded
serial 42
Mar 31 17:25:47 hh3 named[2483]: zone 1.168.192.in-addr.arpa/IN: loaded
serial 2012033101
Mar 31 17:25:47 hh3 named[2483]: zone
loaded serial 42
Mar 31 17:25:47 hh3 named[2483]: zone localhost/IN: loaded serial 42
Mar 31 17:25:47 hh3 named[2483]: managed-keys-zone ./IN: loaded serial 0
Mar 31 17:25:47 hh3 named[2450]: Starting name server BIND ..done
Mar 31 17:25:47 hh3 named[2483]: running
This is after changing ownership of /var/lib/named and after creating he
managed-keys.bind file. Without those changes, bind will not start.
The managed keys file isn't something you create by using 'touch'; it
should contain the crypto keys you are using.
Post by lynn
Post by Anton Aylward
Again, an 'include' may alter things dramatically!
Default again. named.conf.include is empty.
OK .....
Post by lynn
Post by Anton Aylward
Post by lynn
chown named:named /var/lib/named (working directory not writable)
:-)
Post by lynn
touch /var/lib/dyn/managed-keys.bind (file does not exist)
No, that needs to contain the crypto key used by ddns.
Unless that file exists, it throws an error.
Yes, but unless it contains the crypto key shared by DHCP and DNS then
DDNS won't work. This should have been generated by YAST. Its one of
the options, like deleting IPv6, that you should have set.
Post by lynn
Post by Anton Aylward
Post by lynn
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle
transferring the samba dlz stuff to the jail)
I can see that; I'm not going to harp on abut "basic security".
I chroot so I know I can, but if you can justify not needing to
then its "no harm, no foul".
Yes. The samba include file must be readable. In the chroot it can't be
read. I can't find a way of making it work in the chroot without
including most of the samba stuff in there too.
Yes, that's the point of chroot...
Post by lynn
Meanwhile, one important one. I need to add a PTR for each machine on
the lan?
Yes.

As I said in a previous post; you can either use DDNS to let DHCP add
and remove or you can 'cheat' and have them in there to match the same
range as DHCP is going to hand out. The latter lets you micromanage the
names.
--
Insanity is hereditary. You get it from your kids.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-31 17:54:23 UTC
Permalink
Post by Anton Aylward
Post by lynn
Do I need a PTR for each computer on the lan?
I can imagine circumstance where the answer to that is 'no' but I
suspect those circumstances don't apply to you.
If you had ddns working then it would be done 'auto-magically'.
OK. Well, we have ddns with a (re) writeable forward zone handled by
Samba4. You can see the IP it has been assigned by DHCP on the server as
it issues Kerberos tickets for the fileserver and such. I suppose the
test would be to remove the
127.0.1.1 hostname.fqdn hostname
entry in /etc/hosts on the client and see if we can still authenticate.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.
Yes. That's what we have. that's what the samba4 guys added to bind9 to
Was it the Samba guys?
I thought DDNS (RFC2136 et al [3007, 4033, 4034, 4035]) dates back to
1997 and was out of ISC edited by the proverbial Mr Vixie :-)
Yes, Microsoft and Ad integrated DDNS and brought in the modified
version of kerberos, but that still doesn't make it a SAMBA initiative.
You can experiment manually adding records from the CLI with 'nsupdate'.
They were the ones who put he dlz code into bind to make it work against AD.
Post by Anton Aylward
Post by lynn
get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server.
That's the server running under Linux?
12.1 server running the Samba4 AD implementation to serve both win7 and
Linux clients.
Post by Anton Aylward
Post by lynn
It works ok but coming back to the original
point, we have to put 127.0.1.1 in /etc/hosts on the client to get a
name over to the server.
What is the server in need of? The FQDN?
The FQDN should come from the unique IP address of the client.
That's why I keep talking about the reverse DNS.
I assume we're still talking about something that DHCP-driven?
Either the name is hard-coded or its supplied by the DHCP server and the
DHCP server tells the DNS server (via the DDNS protocol) to create the
forward and reverse records.
I _suspect_ that because there is no reverse record it falls back to
127.0.0.1 and that's what your faced with. I've not used kerberos in
this context; my last venture using it was with AIX/SPSS ....
The server needs the fqdn of the Linux client (to do e.g. Kerberized nfs
mounts). Under windows this happens automagically whether the win7 box
has a dhcp address or not. Under Linux I have to either have a fixed IP
or, if I want DHCP have to use the 127.0.1.1 workaround. I'm hoping your
reverse lookups will solve this.
Post by Anton Aylward
Post by lynn
The IPv6 stuff come straight out of a default openSUSE bind install. I
don't want it. It just gets put here.
NASTY!
In the screens you show at the bloc ...
opensuse-using-yast-to-setup-dns.html there is the option to delete the
IPV6 entry and the option to enable DDNS
Yes. I'll do the delete. That sould get rid of it. As I say, we already
have ddns handled outside the Yast configuration with an externally
generated tsig key so I would only use that option if I had created the
forward zone myself. As it is, the forward zone is created for me by the
Samba4 server.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
listen-on-v6 { any; };
WHOA! listen-on-v6 turns on BIND to listen for IPv6 queries.
If you're not running IPv6 then you want "none" rather than "any".
This may account for one error :-)
Yes it does. Again, it is default openSUSE.
I think its up to you to delete what isn't wanted and to enable what is
wanted.
Point taken. I should not blame the tools, rather he bad workman. My fault.
Post by Anton Aylward
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: built with '--prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--localstatedir=/var' '--libdir=/usr/lib'
'--includedir=/usr/include/bind' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-openssl' '--enable-threads'
'--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql'
'--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing'
'LDFLAGS=-L/usr/lib'
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: adjusted limit on open files from 4096
to 1048576
Mar 31 17:25:44 hh3 named[2483]: found 1 CPU, using 1 worker thread
Mar 31 17:25:44 hh3 named[2483]: using up to 4096 sockets
Mar 31 17:25:44 hh3 named[2483]: loading configuration from
'/etc/named.conf'
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file
'/etc/bind.keys'
Yes but I recall there isn't actual a key, there , is there?
Building the key and including it in DNS/DHCP was an option on those
screens at the blog which you didn't take. Perhaps you should have ..
The only reason I created an empty file at
/var/lib/named/dyn/managed-keys.bind was to get rid of the managed-keys
file not found error when starting bind.
Post by Anton Aylward
Post by lynn
[1024, 65535]
[1024, 65535]
Mar 31 17:25:44 hh3 named[2483]: listening on IPv6 interfaces, port 53
Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface lo,
127.0.0.1#53
Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface eth1,
192.168.1.3#53
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: generating session key for dynamic DNS
Mar 31 17:25:44 hh3 named[2483]: sizing zone task pool based on 5 zones
Mar 31 17:25:44 hh3 named[2483]: Loading 'AD DNS Zone' using driver dlopen
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: started for DN DC=hh3,DC=site
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: starting configure
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone
'hh3.site'
Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone
'_msdcs.hh3.site'
Mar 31 17:25:47 hh3 named[2483]: set up managed keys zone for view
_default, file '/var/lib/named/dyn//managed-keys.bind'
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 10.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 16.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 17.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 18.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 19.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 20.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 21.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 22.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 23.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 24.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 25.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 26.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 27.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 28.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 29.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 30.172.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 31.172.IN-ADDR.ARPA
That doesn't matter, its all info not err
Post by lynn
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 168.192.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 0.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 127.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 254.169.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
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.0.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: D.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 9.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: A.E.F.IP6.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: B.E.F.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
You really should disable IPv6 if you're not using it.
Will do.
Post by Anton Aylward
Post by lynn
Mar 31 17:25:47 hh3 named[2483]: command channel listening on 127.0.0.1#953
Info, but its the local IP address that counts :-
Post by lynn
address not available
More IPv6 stuff you can do without.
Post by lynn
Mar 31 17:25:47 hh3 named[2483]: zone 0.0.127.in-addr.arpa/IN: loaded
serial 42
Mar 31 17:25:47 hh3 named[2483]: zone 1.168.192.in-addr.arpa/IN: loaded
serial 2012033101
Mar 31 17:25:47 hh3 named[2483]: zone
loaded serial 42
Mar 31 17:25:47 hh3 named[2483]: zone localhost/IN: loaded serial 42
Mar 31 17:25:47 hh3 named[2483]: managed-keys-zone ./IN: loaded serial 0
Mar 31 17:25:47 hh3 named[2450]: Starting name server BIND ..done
Mar 31 17:25:47 hh3 named[2483]: running
This is after changing ownership of /var/lib/named and after creating he
managed-keys.bind file. Without those changes, bind will not start.
The managed keys file isn't something you create by using 'touch'; it
should contain the crypto keys you are using.
Post by lynn
Post by Anton Aylward
Again, an 'include' may alter things dramatically!
Default again. named.conf.include is empty.
OK .....
Post by lynn
Post by Anton Aylward
Post by lynn
chown named:named /var/lib/named (working directory not writable)
:-)
Post by lynn
touch /var/lib/dyn/managed-keys.bind (file does not exist)
No, that needs to contain the crypto key used by ddns.
Unless that file exists, it throws an error.
Yes, but unless it contains the crypto key shared by DHCP and DNS then
DDNS won't work. This should have been generated by YAST. Its one of
the options, like deleting IPv6, that you should have set.
In my case, the ddns is handled elsewhere so no problem.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle
transferring the samba dlz stuff to the jail)
I can see that; I'm not going to harp on abut "basic security".
I chroot so I know I can, but if you can justify not needing to
then its "no harm, no foul".
Yes. The samba include file must be readable. In the chroot it can't be
read. I can't find a way of making it work in the chroot without
including most of the samba stuff in there too.
Yes, that's the point of chroot...
Post by lynn
Meanwhile, one important one. I need to add a PTR for each machine on
the lan?
Yes.
As I said in a previous post; you can either use DDNS to let DHCP add
and remove or you can 'cheat' and have them in there to match the same
range as DHCP is going to hand out. The latter lets you micromanage the
names.
Big thanks again from all here at lcb.
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-03-31 18:57:04 UTC
Permalink
Post by lynn
Post by Anton Aylward
Post by lynn
Do I need a PTR for each computer on the lan?
I can imagine circumstance where the answer to that is 'no' but I
suspect those circumstances don't apply to you.
If you had ddns working then it would be done 'auto-magically'.
OK. Well, we have ddns with a (re) writeable forward zone handled by
Samba4. You can see the IP it has been assigned by DHCP on the server as
it issues Kerberos tickets for the fileserver and such. I suppose the
test would be to remove the
127.0.1.1 hostname.fqdn hostname
entry in /etc/hosts on the client and see if we can still authenticate.
I'm not sure that would actually be a test.
See later ....
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.
Yes. That's what we have. that's what the samba4 guys added to bind9 to
Was it the Samba guys?
I thought DDNS (RFC2136 et al [3007, 4033, 4034, 4035]) dates back to
1997 and was out of ISC edited by the proverbial Mr Vixie :-)
Yes, Microsoft and Ad integrated DDNS and brought in the modified
version of kerberos, but that still doesn't make it a SAMBA initiative.
You can experiment manually adding records from the CLI with 'nsupdate'.
They were the ones who put he dlz code into bind to make it work against AD.
Are you running AD? You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?
Post by lynn
Post by Anton Aylward
Post by lynn
get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server.
That's the server running under Linux?
12.1 server running the Samba4 AD implementation to serve both win7 and
Linux clients.
Just Windows clients then ...
Post by lynn
The server needs the fqdn of the Linux client (to do e.g. Kerberized nfs
mounts). Under windows this happens automagically whether the win7 box
has a dhcp address or not. Under Linux I have to either have a fixed IP
or, if I want DHCP have to use the 127.0.1.1 workaround. I'm hoping your
reverse lookups will solve this.
THis is where thigns are tricky, a bit beyond my experince, so I'm
speculating.

I do know the code I've seen has kerberos calling "krb_mk_req()" to get
a ticket and that needs the FQDN as a parameter.

Now the question I'm left with is this. Is the machine up and running,
has it got its IP address from the DHCP server? If it has and there is
a reverse lookup that gives its FQDN that will satisfy the kerberos
ticket server, then fine. I'm sorry but I'm not enough of a code-monkey
to be able to hunt down what I should be looking at in the low level
code; is it the kerb5 libraries; is it those bits of SAMBA4?
Its one of those things that its quicker to experuiment.

My suggestion is to use the 'cheat' I suggested.
If this is a sort-of static setup so that the MAC address of that
workstation tells DHCP what IP address to hand out, then you are safe to
hard code the reverse stuff in; it seems the YAST interface will allow
that. Oh, and get rid of all the IPV6 stuff while you're about it.
Post by lynn
Post by Anton Aylward
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file
'/etc/bind.keys'
Yes but I recall there isn't actual a key, there , is there?
Building the key and including it in DNS/DHCP was an option on those
screens at the blog which you didn't take. Perhaps you should have ..
The only reason I created an empty file at
/var/lib/named/dyn/managed-keys.bind was to get rid of the managed-keys
file not found error when starting bind.
Yes, I got that.
But that's where it expect to see they keys when its doing the DDNS stuff.
Post by lynn
Post by Anton Aylward
Yes, but unless it contains the crypto key shared by DHCP and DNS then
DDNS won't work. This should have been generated by YAST. Its one of
the options, like deleting IPv6, that you should have set.
In my case, the ddns is handled elsewhere so no problem.
Yes, but it seems only for the Windows clients.
With the linux clients up you should be able to do a reverse lookup for
each of them.

You really want to use the tools (dig, host, nslookup) to dump the whole
of the in-memory forward and reverse tables - a 'zone transfer'.

According to
http://docstore.mik.ua/orelly/networking_2ndEd/tcp/appc_01.htm
<quote>
SIGINT: Causes named to dump its cache to named_dump.db. The dump file
contains all of the domain information that the local name server knows.
The file begins with the root servers and marks off every domain under
the root that the local server knows anything about.
</quote>

Try that - after all the machines are 'up and runnning' and see if the
forward and reverse entries are being injected.
--
"How well we communicate is determined not by how well we say things but
by how well we are understood."
-- Andrew S. Grove.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-03-31 20:05:44 UTC
Permalink
Post by Anton Aylward
Post by lynn
127.0.1.1 hostname.fqdn hostname
entry in /etc/hosts on the client and see if we can still authenticate.
I'm not sure that would actually be a test.
See later ....
Post by lynn
Post by Anton Aylward
You can experiment manually adding records from the CLI with 'nsupdate'.
They were the ones who put he dlz code into bind to make it work against AD.
Are you running AD?
Yes. Using Samba4 to which we have added the rfc2307 attributes by
including the posixGroup and posixAccount objects which are defined in
the AD LDAP schema. The very schema that m$ were forced to make public
after the European Court found in favour of The Samba Team last year.
Good ol' Tridge:-)

You have a Microsoft domain master running AD or
Post by Anton Aylward
are you all Linux at the core and just Windows clients?
Post by lynn
Post by Anton Aylward
Post by lynn
get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server.
That's the server running under Linux?
12.1 server running the Samba4 AD implementation to serve both win7 and
Linux clients.
Just Windows clients then ...
No. Linux and Windows clients. It is a heterogeneous lan.

<snip>

Will get back to the rest 2moro. Thanks for your time. I'm learning a lot.
BFN
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-04-01 07:06:04 UTC
Permalink
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
Do I need a PTR for each computer on the lan?
If you had ddns working then it would be done 'auto-magically'.
Yes. I have ddns working. The forward zone is updated by Samba4 when new
machines are allocated IP's, join the domain etc. I just didn't have a
reverse lookup zone.

I suppose the
Post by Anton Aylward
Post by lynn
test would be to remove the
127.0.1.1 hostname.fqdn hostname
entry in /etc/hosts on the client and see if we can still authenticate.
I'm not sure that would actually be a test.
See later ....
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.
I think that is what is happening because you can see the KDC receive
requests from IP's which have been allocated via DHCP _and_ correctly
lookup their Kerberos machine$/fqdn key correctly for authentication.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
Yes. That's what we have. that's what the samba4 guys added to bind9 to
Was it the Samba guys?
I thought DDNS (RFC2136 et al [3007, 4033, 4034, 4035]) dates back to
1997 and was out of ISC edited by the proverbial Mr Vixie :-)
Yes, Microsoft and Ad integrated DDNS and brought in the modified
version of kerberos, but that still doesn't make it a SAMBA initiative.
You can experiment manually adding records from the CLI with 'nsupdate'.
They were the ones who put he dlz code into bind to make it work against AD.
Are you running AD? You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our
users have the posixAccount and posixGroup objects which are defined in
the m$ AD schema. (made public via the Samba vs m$ European Court ruling
last year)
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server.
That's the server running under Linux?
12.1 server running the Samba4 AD implementation to serve both win7 and
Linux clients.
Just Windows clients then ...
No. Our lan consists of Linux and windows with a 12.1 server. Mainly
12.1 and win7 with some Ubuntu and xp clients to keep the punters happy.
Post by Anton Aylward
I do know the code I've seen has kerberos calling "krb_mk_req()" to get
a ticket and that needs the FQDN as a parameter.
Kerberos needs not only to authenticate the user but also the machines
on the lan. When I logon, both I and my computer have to authenticate.
If I request a file then both I and the fileserver have to authenticate.
This is why the dns is crucial with Kerberos.
Post by Anton Aylward
Now the question I'm left with is this. Is the machine up and running,
has it got its IP address from the DHCP server?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is
updated so my reverse zone is going to know nothing about the update is it?

If it has and there is
Post by Anton Aylward
a reverse lookup that gives its FQDN that will satisfy the kerberos
ticket server, then fine.
My suggestion is to use the 'cheat' I suggested.
If this is a sort-of static setup so that the MAC address of that
workstation tells DHCP what IP address to hand out, then you are safe to
hard code the reverse stuff in; it seems the YAST interface will allow
that. Oh, and get rid of all the IPV6 stuff while you're about it.
Will do.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named
Info not err
Post by lynn
Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file
'/etc/bind.keys'
Yes but I recall there isn't actual a key, there , is there?
No. Just an empty file to get rid of he error message about the file not
found.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Building the key and including it in DNS/DHCP was an option on those
screens at the blog which you didn't take. Perhaps you should have ..
Yes, I got that.
But that's where it expect to see they keys when its doing the DDNS stuff.
Post by lynn
Post by Anton Aylward
Yes, but unless it contains the crypto key shared by DHCP and DNS then
DDNS won't work. This should have been generated by YAST. Its one of
the options, like deleting IPv6, that you should have set.
In my case, the ddns is handled elsewhere so no problem.
Yes, but it seems only for the Windows clients.
With the linux clients up you should be able to do a reverse lookup for
each of them.
How come the windows clients work OK. What do they have that we don't?
Post by Anton Aylward
You really want to use the tools (dig, host, nslookup) to dump the whole
of the in-memory forward and reverse tables - a 'zone transfer'.
According to
http://docstore.mik.ua/orelly/networking_2ndEd/tcp/appc_01.htm
<quote>
SIGINT: Causes named to dump its cache to named_dump.db. The dump file
contains all of the domain information that the local name server knows.
The file begins with the root servers and marks off every domain under
the root that the local server knows anything about.
</quote>
Try that - after all the machines are 'up and runnning' and see if the
forward and reverse entries are being injected.
Nearer to undestanding. Thanks again.
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2012-04-01 10:19:31 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by lynn
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our
users have the posixAccount and posixGroup objects which are defined in the
m$ AD schema. (made public via the Samba vs m$ European Court ruling last
year)
Interesting...
Post by lynn
Kerberos needs not only to authenticate the user but also the machines on
the lan. When I logon, both I and my computer have to authenticate. If I
request a file then both I and the fileserver have to authenticate. This is
why the dns is crucial with Kerberos.
I see...

I underwent a period of training, mostly with W2K8 R2. These servers had
their corresponding DNS, but not DHCP because you can imagine the havoc 14
DHCP servers can make in the same LAN :-)

But clients did authenticate to the domains.

What I did not make sure is if the DNS could always track the clients. I
think that when someone logged in, the machine was counted in the DNS. This
can not be replicated with bind, AFAIK, and is perhaps the reason that the
samba folks think of another dns daemon.
Post by lynn
Nearer to undestanding. Thanks again.
L x
Try to trim your messages, removing the old stuff from previous messages.
Yours are very long and more difficult to read because you don't.
It also needs learning, but please do :-)

- --
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk94K7MACgkQIvFNjefEBxrXRgCg2h4V6c0+wmRUA+OJVid57yt7
3vIAn3POL3p4yeqmHGUECp6nWBfHjuIc
=qMSW
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-04-01 12:53:05 UTC
Permalink
Post by Carlos E. R.
Interesting...
The Samba team needs greater recognition for the services they make to
open source. Linux is on the verge of being able to replace m$ servers
by running AD DNS itself.
Post by Carlos E. R.
But clients did authenticate to the domains.
What I did not make sure is if the DNS could always track the clients. I
think that when someone logged in, the machine was counted in the DNS. This
can not be replicated with bind, AFAIK, and is perhaps the reason that the
samba folks think of another dns daemon.
Yes it can and is replicated in bind. The Samba team sent patches to
bind which enabled it to do so. They are included as of bind9.8. We have
the dlz patches working fine. win 7 clients use bind as their DNS and
Samba4 as their AD, all under openSUSE. One of the points of this thread
is to enable our Linux clients which are on the same lan, work as the
windows clients do and get rid of that awful 127.0.1.1
Post by Carlos E. R.
Post by lynn
Nearer to undestanding. Thanks again.
L x
Try to trim your messages,
I read the messages in tb, not in an archive so I forget to trim but
will do.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2012-04-01 20:35:32 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
their AD, all under openSUSE. One of the points of this thread is to enable
our Linux clients which are on the same lan, work as the windows clients do
and get rid of that awful 127.0.1.1
But "127.0.1.1" is your own localhost. The entire 127 network is your
localhost, always, not another machine. Tri pinging, it works.

- --
Cheers,
Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk94vBQACgkQtTMYHG2NR9WYCQCgjvrmbTyv0slz62U1hgfii6G3
oL4AnizrivAX3v2pGS4NRmpwFsanjxV5
=ccly
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-04-01 20:53:49 UTC
Permalink
Post by Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
But "127.0.1.1" is your own localhost. The entire 127 network is your
localhost, always, not another machine. Tri pinging, it works.
I have three entries in /etc/hosts on each Linux client:
127.0.0.1 localhost
127.0.1.1 host.domain host
192.168.1.3 server.domain server

with /etc/HOSTNAME
containing
host
only

Without the 127.0.1.1, hostname -f does not work and not much else does
either.

Without the 127.0.1.1, domain logons work but this is useless because
Kerberized nfs doesn't and the user ends up without her files and nfs
mounted windows shares. The automounter and rpc.gssd throw a fit if that
value is not present.

An alternative is to give the clients a fixed IP and use that instead of
the 127.0.1.1. But if the windows clients can use dhcp, why can't our
openSUSE clients use it from the same server?

Windows clients have something that we do not. What is it?
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
James Knott
2012-04-01 21:31:16 UTC
Permalink
The entire 127 network is your localhost
Along with ::1 in IPv6.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-04-01 13:21:44 UTC
Permalink
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Post by lynn
Do I need a PTR for each computer on the lan?
If you had ddns working then it would be done 'auto-magically'.
Yes. I have ddns working. The forward zone is updated by Samba4 when new
machines are allocated IP's, join the domain etc. I just didn't have a
reverse lookup zone.
Then you don't have ddns working _completely_.
Sorry if I seem picky, but we are definitely in a realm where accuracy
and completeness matters.
Post by lynn
I suppose the
Post by Anton Aylward
Post by lynn
test would be to remove the
127.0.1.1 hostname.fqdn hostname
entry in /etc/hosts on the client and see if we can still authenticate.
I'm not sure that would actually be a test.
See later ....
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.
I think that is what is happening because you can see the KDC receive
requests from IP's which have been allocated via DHCP _and_ correctly
lookup their Kerberos machine$/fqdn key correctly for authentication.
KDC = Kerberos Domain Controller ?

To correctly look up FQDN from only a IP requires treat DNS properly
implements reverse lookup. We've established you don't have complete
and accurate reverse tables.

Could you please elucidate.
Post by lynn
Post by Anton Aylward
Are you running AD? You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our
users have the posixAccount and posixGroup objects which are defined in
the m$ AD schema. (made public via the Samba vs m$ European Court ruling
last year)
I think we are talking at cross [purposes or I need an update.
I thought SAMBA was acting as a Domain Controller and that the AD was
the database, possibly (but not always) implemented by LDAP.

AD = Active Directory, a dynamically maintained database, a directory
service that runs on the Domain Controller and needs DNS, Kerberos and
LDAP to support it.

I thought SAMBA was more than just AD.
Post by lynn
Post by Anton Aylward
I do know the code I've seen has kerberos calling "krb_mk_req()" to get
a ticket and that needs the FQDN as a parameter.
... and it needs other parameters but I forget, ....
Post by lynn
Kerberos needs not only to authenticate the user but also the machines
on the lan. When I logon, both I and my computer have to authenticate.
If I request a file then both I and the fileserver have to authenticate.
This is why the dns is crucial with Kerberos.
That is why *properly implemented* DNS is crucial with Kerberos.

If the code can't do a full backward-for-ward-backward verification of
the IP/FQDN from the *authoritative* (and presumably secured) DNS
service then the fallback to the /etc/hosts is a security hole. The
user in control of the client machine can put whatever he (or she) likes
into /etc/hosts and so spoof the identification.
Post by lynn
Post by Anton Aylward
Now the question I'm left with is this. Is the machine up and running,
has it got its IP address from the DHCP server?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is
updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the
DHCP server telling the DNS server. Since its supplying both IP address
and name, the DNS server should be able to slot RRs in for both forward
and backward zones.

The address is handed out after the Linux machine is booted, long before
the SAMBA client comes up, so the SAMBA side of things should have
nothing to do with it. All this DDNS should work regardless of the
presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement
for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it
running in that kind of setting.
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Yes, but unless it contains the crypto key shared by DHCP and DNS then
DDNS won't work. This should have been generated by YAST. Its one of
the options, like deleting IPv6, that you should have set.
In my case, the ddns is handled elsewhere so no problem.
Yes, but it seems only for the Windows clients.
With the linux clients up you should be able to do a reverse lookup for
each of them.
How come the windows clients work OK. What do they have that we don't?
I don't know. I'm not very Windows-savvy.

Actually we are *assuming* things here.
Did you do the dump of the DNS tables?

If we see in that dump that the Windows clients have both forward and
reverse entries we know they are doing something the Linux clients are
not. Then and only then can we say they are working OK in this sense of OK.
--
Plunderers of the world, after they, laying everything waste, run
out of land, they probe even the sea: if their enemy has wealth,
they have greed; if the enemy be poor, they are ambitious; neither
East nor West has sated them; alone of mankind they covet poverty
with the same passion as wealth. Robbery, butchery, rape they misname
Empire: they make a wasteland and call it peace.
- Tacitus, Agricola 80
The speech of Calgacus the Caledonian at the
battle of Mons Graupius
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
lynn
2012-04-01 20:41:31 UTC
Permalink
Post by Anton Aylward
Then you don't have ddns working _completely_.
Sorry if I seem picky, but we are definitely in a realm where accuracy
and completeness matters.
No, be as picky as necessary. I need it.
Post by Anton Aylward
KDC = Kerberos Domain Controller ?
Yes.
Post by Anton Aylward
To correctly look up FQDN from only a IP requires treat DNS properly
implements reverse lookup. We've established you don't have complete
and accurate reverse tables.
Could you please elucidate.
I do not have reverse lookup. The forward zone is created when I start
bind. It get updated when a new client (Linux or windows) boots or joins
the domain. For ddns it has a tsig which is a Kerberos keytab. The
keytab was produced when the AD was first provisioned. I posted he
named.conf a few posts ago. I also have a static reverse zone. The only
thing that prevents it too from being included in the ddns is that I
don't know how to generate a keytab for it. This is where the Samba guys
have changed the bind innards.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Are you running AD? You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our
users have the posixAccount and posixGroup objects which are defined in
the m$ AD schema. (made public via the Samba vs m$ European Court ruling
last year)
I think we are talking at cross [purposes or I need an update.
I thought SAMBA was acting as a Domain Controller and that the AD was
the database, possibly (but not always) implemented by LDAP.
AD = Active Directory, a dynamically maintained database, a directory
service that runs on the Domain Controller and needs DNS, Kerberos and
LDAP to support it.
I thought SAMBA was more than just AD.
Samba4 is a windows domain controller. It consists of a totally
Linux-ified AD. It has its own built in KDC and LDAP server.

Soon, it will have its own DNS server too. It already has its own
working DNS server but ironically it only works for forward ddns at the
moment.
Post by Anton Aylward
Post by lynn
Kerberos needs not only to authenticate the user but also the machines
on the lan.
That is why *properly implemented* DNS is crucial with Kerberos.
If the code can't do a full backward-for-ward-backward verification of
the IP/FQDN from the *authoritative* (and presumably secured) DNS
service then the fallback to the /etc/hosts is a security hole. The
user in control of the client machine can put whatever he (or she) likes
into /etc/hosts and so spoof the identification.
Only root has access to /etc/hosts on our lan.
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Now the question I'm left with is this. Is the machine up and running,
has it got its IP address from the DHCP server?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is
updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the
DHCP server telling the DNS server.
The address is handed out after the Linux machine is booted, long before
the SAMBA client comes up, so the SAMBA side of things should have
nothing to do with it. All this DDNS should work regardless of the
presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement
for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it
running in that kind of setting.
Kerberos has to authenticate the dns server before it can do anything on
the lan. The KDC is supplied by Samba so Samba must be up before any
ddns takes place. We can however show that the clients have an IP before
doing a domain logon as they can ping the server on bot IP and fqdn
(because the server is in their etc/hosts file. The missing link seems
to be what the windows clients have instead of /etc/hosts.
Post by Anton Aylward
Post by lynn
How come the windows clients work OK. What do they have that we don't?
I don't know. I'm not very Windows-savvy.
Actually we are *assuming* things here.
Did you do the dump of the DNS tables?
How do I do a dump?
Post by Anton Aylward
If we see in that dump that the Windows clients have both forward and
reverse entries we know they are doing something the Linux clients are
not. Then and only then can we say they are working OK in this sense of OK.
Will post it as soon as I know how. Meanwhile am running with the
mysterious 127.0.1.1:-(
Thanks again for your time,
L x
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Anton Aylward
2012-04-01 21:32:26 UTC
Permalink
Post by lynn
Post by Anton Aylward
To correctly look up FQDN from only a IP requires treat DNS properly
implements reverse lookup. We've established you don't have complete
and accurate reverse tables.
Could you please elucidate.
I do not have reverse lookup.
Then I can't see how you can expect this to work properly.

And no, spoofing Kerberos by fiddling with /etc/hosts 127.0.0.1 entry is
not "working properly". Carlos is quite right, that is
localhost.localdomain and cannot be anything else without breaking other
fundamentals. Changing it to the fqdn to get around the absence of
reverse lookup is subverting Kerberos.
Post by lynn
The forward zone is created when I start
bind.
Picky: No, when you start bind it reads the config file and builds its
internal map so that it can respond to queries about the forward zone.

You need to have that zone defined and all the static devices in it
(servers, firewalls, routers) as defined resource records (RRs)

DHCP will add and remove more RRs - if you have the thing set up
properly and DHCP knows about the shared cypto key needed for secure
communications.
Post by lynn
It get updated when a new client (Linux or windows) boots or joins
the domain. For ddns it has a tsig which is a Kerberos keytab. The
keytab was produced when the AD was first provisioned. I posted he
named.conf a few posts ago. I also have a static reverse zone. The only
thing that prevents it too from being included in the ddns is that I
don't know how to generate a keytab for it. This is where the Samba guys
have changed the bind innards.
Try reading
http://www.oceanwave.com/technical-resources/unix-admin/nsupdate.html

You recall that bind complained about a file and you created it (empty)
with 'touch'? Well guess what....
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Are you running AD? You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our
users have the posixAccount and posixGroup objects which are defined in
the m$ AD schema. (made public via the Samba vs m$ European Court ruling
last year)
I think we are talking at cross [purposes or I need an update.
I thought SAMBA was acting as a Domain Controller and that the AD was
the database, possibly (but not always) implemented by LDAP.
AD = Active Directory, a dynamically maintained database, a directory
service that runs on the Domain Controller and needs DNS, Kerberos and
LDAP to support it.
I thought SAMBA was more than just AD.
Samba4 is a windows domain controller. It consists of a totally
Linux-ified AD. It has its own built in KDC and LDAP server.
Soon, it will have its own DNS server too. It already has its own
working DNS server but ironically it only works for forward ddns at the
moment.
You keep asserting that, but can you give reference please.
Post by lynn
Post by Anton Aylward
Post by lynn
Kerberos needs not only to authenticate the user but also the machines
on the lan.
That is why *properly implemented* DNS is crucial with Kerberos.
If the code can't do a full backward-for-ward-backward verification of
the IP/FQDN from the *authoritative* (and presumably secured) DNS
service then the fallback to the /etc/hosts is a security hole. The
user in control of the client machine can put whatever he (or she) likes
into /etc/hosts and so spoof the identification.
Only root has access to /etc/hosts on our lan.
Picky: Its not meant to be accessed from the LAN, its meant to be
accessed from local programs, including ones that are not running as
root. It should be 0644/root:root.

Carlos, others, would you care to verify that and explain to Lynn why
/etc/hosts needs to be readable by everyone.

Check /etc/permissions
Post by lynn
Post by Anton Aylward
Post by lynn
Post by Anton Aylward
Now the question I'm left with is this. Is the machine up and running,
has it got its IP address from the DHCP server?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is
updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the
DHCP server telling the DNS server.
The address is handed out after the Linux machine is booted, long before
the SAMBA client comes up, so the SAMBA side of things should have
nothing to do with it. All this DDNS should work regardless of the
presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement
for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it
running in that kind of setting.
Kerberos has to authenticate the dns server before it can do anything on
the lan.
Please explain.
Are you saying that before the DNS server program listening on port 53
on the server machine can respond to DNS requests from the machine some
Kerberos authentication has to take lace? Of what and by what?

What about the DHCP server program running on the server ... ?
Post by lynn
The KDC is supplied by Samba so Samba must be up before any
ddns takes place.
No, that doesn't make sense.

Take all the Windows stuff off your LAN, disable SAMBA and run it just
as a Linux server and Linux clients. (or Linux server and Solaris
clients, or AIX clients or HP-UX or DG-UX). You're running DHCP and
BIND, so it must still be able to work.

And I know, BTDT, that DDNS works without SAMBA in that kind of setup.
I'm sure there are many people on this list who are or who have clients
that are running DHCP<->DDNS<->BIND.

Yes, I'm sure that one-day/some-day SAMBA will have built in
replacements for all this (and probably its own internal database so you
can forget about LDAP, forget about everything about Linus except the
kernel...) but this is now.

I'm sure that SAMBA *does* deal with the Windows side of things quite
well, but what we are discussion is getting Linux machines working with
Kerberos. That means getting forward and reverse DNS entries working.
And if these machines have addresses handed out by DHCP that means
either "cheating" (as I've described) or getting DDNS working.
Post by lynn
We can however show that the clients have an IP before
doing a domain logon as they can ping the server on bot IP and fqdn
(because the server is in their etc/hosts file. The missing link seems
to be what the windows clients have instead of /etc/hosts.
Googling I see mention of
c:\windows\system32\drivers\etc\hosts

Please note: Unlike the DNS, the hosts file is under the direct control
of the local computer's administrator. That's why it should be
*writeable* only by root and end users should not have root access.

In addition, your nsswitch should prefer DNS and only use the host file
when DNS isn't available.

See also http://support.microsoft.com/kb/172218
Post by lynn
Post by Anton Aylward
Actually we are *assuming* things here.
Did you do the dump of the DNS tables?
How do I do a dump?
Send a signal to the server, as I described in the except from the man
page in an earlier mail.
--
If computers get too powerful, we can organize them into a committee -
that will do them in. -- Bradley's Bromide
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
ianseeks
2012-03-30 07:21:30 UTC
Permalink
Post by lynn
12.1
Hi
We have a bind nameserver for our 192 domain.
127.0.1.1 hostname.domain hostname
in /etc/hosts otherwise hostname -f and lots of other stuff doesn't work.
1. Why?
2. What should the file /etc/HOSTNAME contain?
a. fqdn
b. hostname
Thanks,
L x
It might be a "bug", these may help
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099
http://www.debian.org/doc/manuals/debian-
reference/ch05.en.html#_the_hostname_resolution (see 5.1.2)
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
Loading...