I use dig to see which nameserver ist replying: dig server-1.de And I see NOT bind managed by ISP ist replying. But that the local bind should answer even if I try: dig gmx.de the answer should come from the local bind. Right? But is does'nt. resolf.conf has this entries: I should be able to remove the external nameserver: nameserver 1.2.2.4 nameserver 1.2.2.1 but if I do that dig does find any answer :-( What would be right to do? Do I have to add a new “pri. server-1.de” zone pointing to 1.2.3.4 pri. server-1.de contains this: Even I get this error during bind is starting if I don't change the DefaultAddress 127.0.0.1 in /etc/proftpd_ispconfig.conf to I’m using xen: Dom0 ip 1.2.3.4 and domU with ispconig ip 10.0.1.1
If you want to ask your local DNS server, you must run Code: dig @localhost gmx.de What's the output of Code: netstat -tap ? What's in /etc/hosts? Which distribution do you use?
Code: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 *:mysql *:* LISTEN 1186/mysqld tcp 0 0 *:81 *:* LISTEN 1522/ispconfig_http tcp 0 0 *:ftp *:* LISTEN 2482/proftpd: (acce tcp 0 0 server-1.d:domain *:* LISTEN 1052/named tcp 0 0 localhost:domain *:* LISTEN 1052/named tcp 0 0 *:smtp *:* LISTEN 2624/master tcp 0 0 localhost:953 *:* LISTEN 1052/named tcp6 0 0 *:imaps *:* LISTEN 1095/couriertcpd tcp6 0 0 *:pop3s *:* LISTEN 1116/couriertcpd tcp6 0 0 *:pop3 *:* LISTEN 1103/couriertcpd tcp6 0 0 *:imap2 *:* LISTEN 1077/couriertcpd tcp6 0 0 *:ssh *:* LISTEN 1407/sshd tcp6 0 0 *:smtp *:* LISTEN 2624/master tcp6 0 0 ip6-localhost:953 *:* LISTEN 1052/named tcp6 0 52 ::ffff:10.0.1.1:ssh dslb-088-074-097-:25330 ESTABLISHED22396/14 Code: x01:~# cat /etc/hosts 127.0.0.1 localhost 10.0.1.1 server-1.de server-1.de x01
Looks good. Do you still see errors in your log files? BTW, I've just seen this in your named.conf: Code: [B][COLOR="Red"]zone " server-1.de" {[/COLOR][/B] type master; [B][COLOR="Red"]file "pri. server-1.de ";[/COLOR][/B] }; Should be Code: [B][COLOR="Red"]zone "server-1.de" {[/COLOR][/B] type master; [B][COLOR="Red"]file "pri.server-1.de";[/COLOR][/B] }; instead. What's the output of Code: dig @localhost server-1.de ?
yes Even again I've got an other problem which I already had before: I can't recieve mail at localhost. In local-host-names I find already "localhost.localdomain":
What's in /etc/postfix/main.cf (please strip out the comments)? The dig output looks ok (although you should check if you want the A record to point to a local IP address). What errors do you see in your logs?
server01:/etc/postfix# grep ^[^#].* main.cf Code: smtpd_banner = $myhostname ESMTP biff = no append_dot_mydomain = no myhostname = server-1.de alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mail.server-1.de, server-1.de, localhost.de, localhost relayhost = mynetworks = 127.0.0.0/8 mailbox_command = mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all smtpd_sasl_local_domain = smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination smtpd_tls_auth_only = no smtp_use_tls = yes smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom home_mailbox = Maildir/ virtual_maps = hash:/etc/postfix/virtusertable I don't see another way than pointig to the local address because that's the address that belongs to the the server (It's a domU on an dom0) Code: Nov 14 16:47:33 server-1 named[1052]: invalid command from 127.0.0.1#49873: bad auth Nov 14 16:47:35 server-1 named[27487]: starting BIND 9.2.4 -u bind -t /var/lib/named Nov 14 16:47:35 server-1 named[27487]: using 1 CPU Nov 14 16:47:35 server-1 named[27487]: loading configuration from '/etc/bind/named.conf' Nov 14 16:47:35 server-1 named[27487]: listening on IPv4 interface lo, 127.0.0.1#53 Nov 14 16:47:35 server-1 named[27487]: binding TCP socket: address in use Nov 14 16:47:35 server-1 named[27487]: listening on IPv4 interface eth0, 10.0.1.1#53 Nov 14 16:47:35 server-1 named[27487]: binding TCP socket: address in use
Please run Code: postconf -e 'mydestination = /etc/postfix/local-host-names' /etc/init.d/postfix restart So I guess it's behind a router? Then point the domain to the router's public IP address becasue otherwise nobody can access your machine/web sites if he's outside your network. Have a look here: http://www.howtoforge.com/forums/showthread.php?t=6863
The "mail loops back to itself" problem is gone since I've taken the line "localhost.localdomain.server-1.de" from /etc/postfix/local-host-name. I don't even know how to emty the mailq which holds old mail like: Yes and no, but everybody can reach the webserver by directing the traffic with iptaples, nat and forwarding. My question an my concept was: If dig or a local client is asking for a domain should'nt bind anwser the questin by using its cache. For example sombody is using a hyperlink on a website which is located on this example server configured with ispconfig. Bind already know the anwser because its asked another dns server before. The resolving anwser from the local bind must be faster and even save some trafic than asking another dns server every time. That is the reason why I am wondering about the default answer from dig. dig is getting the another from outsite dns server but not from the local dns bind and I think that could be like that. Why not? Do you know what I mean? Ok, it's fine now. I've kill nearly 20 bind daemons. Thanks a lot. But still I don't understand why it is nessesary to kill the bind process than to stop it. I tried to stop bind whith: rndc stop and with /etc/init.d/bind9 stop but every time I get this notice: Stopping domain name service: namedrndc: connection to remote host closed This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid. .
You can empty the mail queue like this (but this will delete all mails in the queue): Code: postsuper -d ALL
ok, thanks for the hint. My question an my concept was: If dig or a local client is asking for a domain should'nt bind anwser the questin by using its cache. For example sombody is using a hyperlink on a website which is located on this example server configured with ispconfig. Bind already know the anwser because its asked another dns server before. The resolving anwser from the local bind must be faster and even save some trafic than asking another dns server every time. That is the reason why I am wondering about the default answer from dig. dig is getting the another from outsite dns server but not from the local dns bind and I think that could be like that. Why not? Do you know what I mean?
The computer of your visitor will ask the DNS servers that he put into his network settings or that he got by DHCP. Your own server will always ask the DNS servers that are in /etc/resolv.conf. If you have a caching nameserver and want to save traffic, you can put Code: nameserver 127.0.0.1 into /etc/resolv.conf (as the first record).
Ok, I got that. As far as I know bind is a caching nameserver as defauld. Thanks a lot for your help and your patience falko
Now I think I've found a solution for my question but this contains more questions. Bind9 as a caching nameserver is resolving dns questions as defauld configured by /etc/resolv.conf. If this local caching nameserver bind9 is'nt able to resolv a dns question by its zone files or by using its cache it will use forwarders. If configured it like that: Code: /etc/resolv.conf nameserver 10.0.1.1 and /etc/bind/namd.conf Code: options { pid-file "/var/run/bind/run/named.pid"; directory "/etc/bind"; forwarders { 1.0.0.100;1.0.0.101; }; forward only; auth-nxdomain no; But after rebooting I go two new problems: 1. After rebooting the resolv.conf file was overwritten whith the old entries so it looks like that again: Which script is overwriting the file /etc/resolv.conf during the reboot ? 2. The second problem ist the two named are started by defauld that I find this after a fresh reboot: I don't understand why two named are started during the reboot and I supposed the is one to much. This startscripts I've are there: but it don't seems to be more than usual. I suppose there are other startscrips to start bind in chroot but I not used to it..
Debian Sarge Problably I've found the solution. The dhcpd is rewriting the resonv.conf during its starts. I've commented out the line "SET_DNS='yes'" in /etc/dhcpc/config that is looks like that now : Code: #SET_DNS='yes' It seems to stop overwriting the resolv.conf during rebooting. Edit: It is not the final solution because I'm getting plenty mail containing errors like the following now: Code: The Postfix program <[email protected]>: [localhost.localdomain]: Name or service not known mail.log Code: Nov 20 17:42:03 server-1 postfix/smtp[1962]: 32C411F5FF: to=<[email protected]>, relay=none, delay=0, status=bounced ([localhost.localdomain]: Name or service not known) /etc/postfix/locl-host-names contails: Code: ################################### localhost server01.de localhost.server01.de localhost.de localhost.localdomain [url]www.server-1.de[/url] #### MAKE MANUAL ENTRIES BELOW THIS LINE! #### I've changed /etc/dhcpc/config back to last contend by setting the chaged line again to Code: SET_DNS='yes' and did a reboot. The mail messing are gone... Why I got this bloody mail now? Sure? Why it starts two? It seems to me that the error message which arised during to stard bind is the result of the two named. If I kill both and start only one there is no errormessage during bind is starting.
