NAMED issue
Hi Team, We are facing an issue with BIND since last 1 year, will you be able to help. We have a DNS master and 4 Replicas at 2 sites. Current BIND version: 9.9.9.P5 (recently patched to P5). Issue: The named process is getting hung or stopped at least once a day on each of these Replicas. This is happening since more than 1 year. Meanwhile, many vulnerability patch versions upgraded and currently running with the latest BIND 9.9.9.P5. Temporary Fix: A script is running to check and restart the named process if stopped or hung. OS Version: AIX 6.1, TL 9 Though our DNS master is also running with the same version, we never faced this issue. Please Note: all the DNS queries goes to the Replicas and none to the master. Thanks and Regards. Sudharanjan Patnaik Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question!
Hello, We have DNS servers (Venders are Dell & HP & Fujitsu) Recently, we upgraded bind version from 9.9.8-P3 to 9.9.9-P4. We find out server query performance droped from our test.(Used DNS perf. program) Especially, dell server droped minus 61%. I wonder why server performance droped. And why dell server droped high percentage than HP servers. ㅇ Server performance test result (Based Maximum Unique Query/Sec) - server name (CPU spec): Bind 9.9.8-P3 -> Bind 9.9.9-P4 - HP DL360 G5 (3.0Ghz dual*2) : 10,000pps -> 6,896pps (-31%) - HP DL360 G7 (2.17Ghz 4core*1) : 14,000pps -> 13,938pps - HP DL380 G7 (2.4Ghz 4core*2):14,000pps -> 14,262pps - HP DL360 G8 (2.3Ghz 6core*1):24,000pps -> 21,318pps (-11%) - Dell R610 (2.27Ghz 4core*2): 17,000pps-> 6,557pps (-61%) Thank you, Wonyoung, Lee 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다. This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: domain-unable-resolve
Is your DNS server(ns10.cyberia.net.sa) able to connect NS servers of of abudawood.com ? On 2/9/2017 11:32 AM, Ejaz wrote: Helo, Time to time we are having problem in resolving some domains, one of them is “*abudawood.com*” we unable to resolve through our DNS servers of “ns10.cyberia.net.sa” where I have latest bind version and all, what could be the issue and what is the best way to trouble shoot. My bind version [root@ns10 ~]# named -v BIND 9.11.0 The below is trace result, it reached to their DNS server, but could not able to get query results. [root@ns10 ~]# dig ns SAMANet.gov.sa \ ; <<>> DiG 9.11.0 <<>> ns SAMANet.gov.sa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31831 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: b7510c2058b91a7d3bc824e8589c0f68772d7bfd43357c41 (good) ;; QUESTION SECTION: ;SAMANet.gov.sa. IN NS ;; ANSWER SECTION: SAMANet.gov.sa. 3587IN NS ns2.bluvalt.sa. SAMANet.gov.sa. 3587IN NS ns1.bluvalt.sa. ;; ADDITIONAL SECTION: ns1.bluvalt.sa. 23003 IN A 46.49.128.130 ns2.bluvalt.sa. 23003 IN A 46.49.140.146 ;; Query time: 5 msec ;; SERVER: 212.119.64.2#53(212.119.64.2) ;; WHEN: Thu Feb 09 09:42:48 AST 2017 ;; MSG SIZE rcvd: 147 [root@ns10 ~]# dig ns sama.org.sa ; <<>> DiG 9.11.0 <<>> ns sama.org.sa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11980 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 2bebca3cf5e2d6f3cad9e21b589c0f726413bf957d972607 (good) ;; QUESTION SECTION: ;sama.org.sa. IN NS ;; ANSWER SECTION: sama.org.sa.3600IN NS ns1.bluvalt.sa. sama.org.sa.3600IN NS ns2.bluvalt.sa. ;; ADDITIONAL SECTION: ns1.bluvalt.sa. 22993 IN A 46.49.128.130 ns2.bluvalt.sa. 22993 IN A 46.49.140.146 ;; Query time: 9 msec ;; SERVER: 212.119.64.2#53(212.119.64.2) ;; WHEN: Thu Feb 09 09:42:58 AST 2017 ;; MSG SIZE rcvd: 144 [root@ns10 ~]# sama.org.sa. 3600IN NS ns1.bluvalt.sa. bash: sama.org.sa.: command not found... [root@ns10 ~]# sama.org.sa. 3600IN NS ns2.bluvalt.sa.sa ma.org.sa.3600IN NS ns1.bluvalt.sa. bash: sama.org.sa.: command not found... [root@ns10 ~]# sama.org.sa. 3600IN NS ns2.bluvalt.sa.^C [root@ns10 ~]# named -v BIND 9.11.0 [root@ns10 ~]# vi /etc/named.conf [root@ns10 ~]# dig abudawood.com +trace ; <<>> DiG 9.11.0 <<>> abudawood.com +trace ;; global options: +cmd . 106794 IN NS a.root-servers.net. . 106794 IN NS c.root-servers.net. . 106794 IN NS k.root-servers.net. . 106794 IN NS l.root-servers.net. . 106794 IN NS f.root-servers.net. . 106794 IN NS b.root-servers.net. . 106794 IN NS h.root-servers.net. . 106794 IN NS m.root-servers.net. . 106794 IN NS j.root-servers.net. . 106794 IN NS d.root-servers.net. . 106794 IN NS i.root-servers.net. . 106794 IN NS g.root-servers.net. . 106794 IN NS e.root-servers.net. . 107999 IN RRSIG NS 8 0 518400 2017022205 201 7020904 61045 . TMv9X94Rxe6LPkPDaUB4KgOOP80SX5cNBXSawftLwIofkZWLDB1H9BUk EP8 P+7OobV6BxU/prHrNaReq4V7GY5GyOIBkvH7N6QqbrTpaYyAuWlWz gdtF9DthsLfsKSqUMqB50NGBDR V3erxuenHmX5f2VkLK/Dor3eUMdSBN wwUN4NPPst9PaORSqmTzSIirRfm7oglOvjKMtIrTu4+cOofHs XO0bi7j fXu+TT/+6SlFu2x3NXxOZStGSmeWOf6xmkIUNUShjP0HDFz0KxrxOYPj Y8agXhxchni2js4 92pY6/oFeb4txcps6tk28WdSeYljCCUTsQ39tQTBO PjrnvA== ;; Received 1125 bytes from 212.119.64.2#53(212.119.64.2) in 0 ms com.172800 IN NS l.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.
Re: NAMED issue
On 09.02.17 09:24 Sudharanjan Patnaik wrote: > Issue: The named process is getting hung or stopped at least once a > day on each of these Replicas. This is happening since more than 1 > year. Meanwhile, many vulnerability patch versions upgraded and > currently running with the latest BIND 9.9.9.P5. Temporary Fix: A > script is running to check and restart the named process if stopped > or hung. Without logs it might be very hard to help you... Johannes signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: domain-unable-resolve
In message <9adb101d282a6$ac1699b0$0443cd10$@cyberia.net.sa>, "Ejaz" writes: > > Helo, > > Time to time we are having problem in resolving some domains, one of them is > "abudawood.com" we unable to resolve through our DNS servers of > "ns10.cyberia.net.sa" where I have latest bind version and all, what could > be the issue and what is the best way to trouble shoot. The nameservers for abudawood.com are broken. ns1.abudawood.com incorrectly returns FORMERR to queries which contain a DNS COOKIE irrespective of the EDNS version field. This behaviour in not compliant with either the initial EDNS specification nor the revised EDNS specification. ns2.abudawood.com appears to be a old Microsoft DNS server which fails to respond to EDNS queries after the first one. Failure to respond to consistently to DNS queries breaks recovery from packet loss. Both these servers need to be replaced with ones that are RFC compliant. EDNS Compliance Tester Checking: 'abudawood.com.' as at 2017-02-09T08:37:05Z abudawood.com. @212.118.102.2 (ns1.abudawood.com.): edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed,nosoa edns1opt=formerr,badversion,echoed do=ok ednsflags=ok docookie=formerr,nosoa,echoed edns@512tcp=ok optlist=formerr,nosoa,subnet abudawood.com. @212.118.102.3 (ns2.abudawood.com.): edns=timeout edns1=timeout edns@512=timeout ednsopt=timeout edns1opt=timeout do=timeout ednsflags=timeout docookie=timeout edns@512tcp=status,noopt optlist=timeout The Following Tests Failed Warning: test failures may indicate that some DNS clients cannot resolve the zone or will get a unintended answer or resolution will be slower than necessary. Warning: failure to address issues identified here may make future DNS extensions that you want to use ineffective. In particular echoing back unknown EDNS options and unknown EDNS flags will break future signaling between DNS client and DNS server. We already have examples of this were you cannot depend on the AD flag bit meaning anything in replies because too many DNS servers just echo it back. Similarly the EDNS Client Subnet (ECS) option cannot just be sent to everyone in part because of servers just echoing it back. Plain EDNS (edns) This is the style of the initial query that BIND 9.0.x sends. dig +nocookie +norec +noad +edns=0 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: EDNS over IPv6 See RFC6891 EDNS - Unknown Version Handling (edns1) dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server expect: BADVERS expect: OPT record with version set to 0 expect: not to see SOA See RFC6891, 6.1.3. OPT Record TTL Field Use EDNS - Truncated Response (edns@512) dig +nocookie +norec +noad +dnssec +bufsize=512 +ignore dnskey zone @server expect: NOERROR expect: OPT record with version set to 0 expect: UDP DNS message size to be less than or equal to 512 bytes See RFC6891, 7. Transport Considerations EDNS - Unknown Option Handling (ednsopt) dig +nocookie +norec +noad +ednsopt=100 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: that the option will not be present in response See RFC6891, 6.1.2 Wire Format EDNS - Unknown Version with Unknown Option Handling (edns1opt) dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server expect: BADVERS expect: OPT record with version set to 0 expect: not to see SOA expect: that the option will not be present in response See RFC6891 EDNS - DNSSEC (do) This is the style of then initial query that BIND 9.1.0 - BIND 9.10.x sends. dig +nocookie +norec +noad +dnssec soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: DO flag in response if RRSIG is present in response See RFC3225 EDNS - Unknown Flag Handling (ednsflags) dig +nocookie +norec +noad +ednsflags=0x80 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: Z bits to be clear in response See RFC6891, 6.1.4 Flags EDNS - DNSSEC with DNS COOKIE Option (docookie) This is the style of the initial query that BIND 9.11.0 and BIND 9.10.4 Windows onwards send. dig +cookie +norec +noad +dnssec soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: DO flag in response if RRSIG is present in response See RFC3225, RFC6891, and RFC7873. EDNS - over TCP Response (edns@512tcp) dig +vc +nocookie +norec +noad +edns +dnssec +bufsize=512 dnskey zone @server expect: NOERROR expect: OPT record with version set to 0 See RFC5966 and See RFC6891 EDNS - Supported Options Probe (optlist) dig +edns +noad +norec +nsid +subnet=0.0.0.0/0 +expire +cookie -q zone @server expect: NOERROR expect: OPT record with version set to 0 See RFC6891 Codes ok - test passed. subnet - EDNS Client Subnet supported [RFC7871]. noopt - OPT record not found when expected. nosoa - SOA record not found when expected. echoed - EDNS option echoed back. status - expected rcode s
Re: domain-unable-resolve
Am 09.02.2017 um 08:32 schrieb Ejaz: Time to time we are having problem in resolving some domains, one of them is “*abudawood.com*” we unable to resolve through our DNS servers of “ns10.cyberia.net.sa” where I have latest bind version and all, what could be the issue and what is the best way to trouble shoot. well, that domain is maintained by incompetent admins and violates several rules - a single point of failre combined with a SOA expire of 15 minutes - i better don't speak out what i think https://intodns.com/abudawood.com I could use the nameservers listed below to performe recursive queries. It may be that I am wrong but the chances of that are low. You should not have nameservers that allow recursive queries as this will allow almost anyone to use your nameservers and can cause problems. Problem record(s) are: 212.118.102.2 ERROR: One or more of your nameservers did not respond: The ones that did not respond are: 212.118.102.3 WARNING: Not all of your nameservers are in different subnets WARNING: Single point of failure WARNING: Your SOA REFRESH interval is: 900. That is not so ok Your SOA EXPIRE number is: 86400. That is NOT OK ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: domain-unable-resolve
Thank you all, for the detailed explanation, I understood as sys admin but our client will comparing with Google open DNS server. No, I can't use his DNS server. From ns10.cyberia.net.sa, connection timed out.. It is one of our VIP customer and complaining that if "I have problem in my "name servers" when we use open DNS server such as google and several others, they don't have any issue to resolve their records. Satisfying customer is become tough. Only they have problem to resolve the queries when they start using our DNS ns10.cyberia.net.sa Ejaz From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Abdul Khader Sent: Thursday, February 9, 2017 11:31 AM To: bind-users@lists.isc.org Subject: Re: domain-unable-resolve Is your DNS server(ns10.cyberia.net.sa) able to connect NS servers of of abudawood.com ? On 2/9/2017 11:32 AM, Ejaz wrote: Helo, Time to time we are having problem in resolving some domains, one of them is "abudawood.com" we unable to resolve through our DNS servers of "ns10.cyberia.net.sa" where I have latest bind version and all, what could be the issue and what is the best way to trouble shoot. My bind version [root@ns10 ~]# named -v BIND 9.11.0 The below is trace result, it reached to their DNS server, but could not able to get query results. [root@ns10 ~]# dig ns SAMANet.gov.sa \ ; <<>> DiG 9.11.0 <<>> ns SAMANet.gov.sa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31831 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: b7510c2058b91a7d3bc824e8589c0f68772d7bfd43357c41 (good) ;; QUESTION SECTION: ;SAMANet.gov.sa.IN NS ;; ANSWER SECTION: SAMANet.gov.sa. 3587IN NS ns2.bluvalt.sa. SAMANet.gov.sa. 3587IN NS ns1.bluvalt.sa. ;; ADDITIONAL SECTION: ns1.bluvalt.sa. 23003 IN A 46.49.128.130 ns2.bluvalt.sa. 23003 IN A 46.49.140.146 ;; Query time: 5 msec ;; SERVER: 212.119.64.2#53(212.119.64.2) ;; WHEN: Thu Feb 09 09:42:48 AST 2017 ;; MSG SIZE rcvd: 147 [root@ns10 ~]# dig ns sama.org.sa ; <<>> DiG 9.11.0 <<>> ns sama.org.sa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11980 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 2bebca3cf5e2d6f3cad9e21b589c0f726413bf957d972607 (good) ;; QUESTION SECTION: ;sama.org.sa. IN NS ;; ANSWER SECTION: sama.org.sa.3600IN NS ns1.bluvalt.sa. sama.org.sa.3600IN NS ns2.bluvalt.sa. ;; ADDITIONAL SECTION: ns1.bluvalt.sa. 22993 IN A 46.49.128.130 ns2.bluvalt.sa. 22993 IN A 46.49.140.146 ;; Query time: 9 msec ;; SERVER: 212.119.64.2#53(212.119.64.2) ;; WHEN: Thu Feb 09 09:42:58 AST 2017 ;; MSG SIZE rcvd: 144 [root@ns10 ~]# sama.org.sa.3600IN NS ns1.bluvalt.sa. bash: sama.org.sa.: command not found... [root@ns10 ~]# sama.org.sa.3600IN NS ns2.bluvalt.sa.sa ma.org.sa. 3600IN NS ns1.bluvalt.sa. bash: sama.org.sa.: command not found... [root@ns10 ~]# sama.org.sa.3600IN NS ns2.bluvalt.sa.^C [root@ns10 ~]# named -v BIND 9.11.0 [root@ns10 ~]# vi /etc/named.conf [root@ns10 ~]# dig abudawood.com +trace ; <<>> DiG 9.11.0 <<>> abudawood.com +trace ;; global options: +cmd . 106794 IN NS a.root-servers.net. . 106794 IN NS c.root-servers.net. . 106794 IN NS k.root-servers.net. . 106794 IN NS l.root-servers.net. . 106794 IN NS f.root-servers.net. . 106794 IN NS b.root-servers.net. . 106794 IN NS h.root-servers.net. . 106794 IN NS m.root-servers.net. . 106794 IN NS j.root-servers.net. . 106794 IN NS d.root-servers.net. . 106794 IN NS i.root-servers.net. . 106794 IN NS g.root-servers.net. . 106794 IN NS e.root-servers.net. . 107999 IN RRSIG NS 8 0 518400 2017022205 201 7020904 61045 . TMv9X94Rxe6LPkPDaUB4KgOOP80SX5cNBXSawftLwIofkZWLDB1H9BUk EP8 P+7OobV6BxU/prHrNaReq4V7GY5GyOIBkvH7N6QqbrTpaYyAuWlWz gdtF9DthsLfsKSqUMqB50NGBDR V3erxuenHmX5f2VkLK/Dor3eUMdSBN wwUN4NPPst9PaORSqmTzS
Re: domain-unable-resolve
On your DNS server(recursing) put the following do that any query for
the domain abudawood.com all the requests are forwarded to google DNS
server.
zone "abudawood.com" IN {
type forward;
forward only;
forwarders {
8.8.8.8;
};
};
Regards
On 2/9/2017 1:34 PM, Ejaz wrote:
Thank you all, for the detailed explanation, I understood as sys
admin but our client will comparing with Google open DNS server.
No, I can’t use his DNS server. From ns10.cyberia.net.sa,
connection timed out..
It is one of our VIP customer and complaining that if “I have problem
in my “name servers” when we use open DNS server such as google and
several others, they don’t have any issue to resolve their records.
Satisfying customer is become tough.
Only they have problem to resolve the queries when they start using
our DNS ns10.cyberia.net.sa
Ejaz
*From:*bind-users [mailto:bind-users-boun...@lists.isc.org] *On Behalf
Of *Abdul Khader
*Sent:* Thursday, February 9, 2017 11:31 AM
*To:* bind-users@lists.isc.org
*Subject:* Re: domain-unable-resolve
Is your DNS server(ns10.cyberia.net.sa) able to connect NS servers of
of abudawood.com ?
On 2/9/2017 11:32 AM, Ejaz wrote:
Helo,
Time to time we are having problem in resolving some domains, one
of them is “*abudawood.com*” we unable to resolve through our DNS
servers of “ns10.cyberia.net.sa” where I have latest bind version
and all, what could be the issue and what is the best way to
trouble shoot.
My bind version
[root@ns10 ~]# named -v
BIND 9.11.0
The below is trace result, it reached to their DNS server, but
could not able to get query results.
[root@ns10 ~]# dig ns SAMANet.gov.sa
\
; <<>> DiG 9.11.0 <<>> ns SAMANet.gov.sa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31831
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b7510c2058b91a7d3bc824e8589c0f68772d7bfd43357c41 (good)
;; QUESTION SECTION:
;SAMANet.gov.sa. IN NS
;; ANSWER SECTION:
SAMANet.gov.sa. 3587IN NS ns2.bluvalt.sa.
SAMANet.gov.sa. 3587IN NS ns1.bluvalt.sa.
;; ADDITIONAL SECTION:
ns1.bluvalt.sa. 23003 IN A 46.49.128.130
ns2.bluvalt.sa. 23003 IN A 46.49.140.146
;; Query time: 5 msec
;; SERVER: 212.119.64.2#53(212.119.64.2)
;; WHEN: Thu Feb 09 09:42:48 AST 2017
;; MSG SIZE rcvd: 147
[root@ns10 ~]# dig ns sama.org.sa
; <<>> DiG 9.11.0 <<>> ns sama.org.sa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11980
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2bebca3cf5e2d6f3cad9e21b589c0f726413bf957d972607 (good)
;; QUESTION SECTION:
;sama.org.sa. IN NS
;; ANSWER SECTION:
sama.org.sa.3600IN NS ns1.bluvalt.sa.
sama.org.sa.3600IN NS ns2.bluvalt.sa.
;; ADDITIONAL SECTION:
ns1.bluvalt.sa. 22993 IN A 46.49.128.130
ns2.bluvalt.sa. 22993 IN A 46.49.140.146
;; Query time: 9 msec
;; SERVER: 212.119.64.2#53(212.119.64.2)
;; WHEN: Thu Feb 09 09:42:58 AST 2017
;; MSG SIZE rcvd: 144
[root@ns10 ~]# sama.org.sa. 3600IN NS ns1.bluvalt.sa.
bash: sama.org.sa.: command not found...
[root@ns10 ~]# sama.org.sa. 3600IN NS ns2.bluvalt.sa.sa
ma.org.sa.3600IN NS ns1.bluvalt.sa.
bash: sama.org.sa.: command not found...
[root@ns10 ~]# sama.org.sa. 3600IN NS ns2.bluvalt.sa.^C
[root@ns10 ~]# named -v
BIND 9.11.0
[root@ns10 ~]# vi /etc/named.conf
[root@ns10 ~]# dig abudawood.com +trace
; <<>> DiG 9.11.0 <<>> abudawood.com +trace
;; global options: +cmd
. 106794 IN NS a.root-servers.net.
. 106794 IN NS c.root-servers.net.
. 106794 IN NS k.root-servers.net.
. 106794 IN NS l.root-servers.net.
. 106794 IN NS f.root-servers.net.
. 106794 IN NS b.root-servers.net.
. 106794 IN NS h.root-servers.net.
. 106794 IN NS m.root-servers.net.
. 106794 IN NS j.root-servers.net.
. 106794 IN NS d.root-servers.net.
. 106794 IN NS i.root-servers.net.
. 106794 IN NS g.root-servers.net.
. 106794 IN NS
Named issue
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of bind-users-requ...@lists.isc.org Sent: Thursday, February 09, 2017 3:06 PM To: bind-users@lists.isc.org Subject: bind-users Digest, Vol 2599, Issue 3 Send bind-users mailing list submissions to bind-users@lists.isc.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: NAMED issue (Johannes Kastl) 2. Re: domain-unable-resolve (Mark Andrews) 3. Re: domain-unable-resolve (Reindl Harald) 4. RE: domain-unable-resolve (Ejaz) -- Message: 1 Date: Thu, 9 Feb 2017 09:32:02 +0100 From: Johannes Kastl To: bind-users@lists.isc.org Subject: Re: NAMED issue Message-ID: <9db26aa7-acc0-2edd-ab83-28225d651...@ojkastl.de> Content-Type: text/plain; charset="iso-8859-1" On 09.02.17 09:24 Sudharanjan Patnaik wrote: > Issue: The named process is getting hung or stopped at least once a > day on each of these Replicas. This is happening since more than 1 > year. Meanwhile, many vulnerability patch versions upgraded and > currently running with the latest BIND 9.9.9.P5. Temporary Fix: A > script is running to check and restart the named process if stopped or > hung. Without logs it might be very hard to help you... Johannes Hi Johannes, Thanks for you response. Please let me know what logs you need. Sudharanjan -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 244 bytes Desc: OpenPGP digital signature URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170209/d9b44df6/attachment-0001.bin> -- Message: 2 Date: Thu, 09 Feb 2017 20:00:17 +1100 From: Mark Andrews To: "Ejaz" Cc: prxjedadmi...@abudawood.com, "'bind-users'" Subject: Re: domain-unable-resolve Message-ID: <20170209090017.19c1c6362...@rock.dv.isc.org> In message <9adb101d282a6$ac1699b0$0443cd10$@cyberia.net.sa>, "Ejaz" writes: > > Helo, > > Time to time we are having problem in resolving some domains, one of > them is "abudawood.com" we unable to resolve through our DNS servers > of "ns10.cyberia.net.sa" where I have latest bind version and all, > what could be the issue and what is the best way to trouble shoot. The nameservers for abudawood.com are broken. ns1.abudawood.com incorrectly returns FORMERR to queries which contain a DNS COOKIE irrespective of the EDNS version field. This behaviour in not compliant with either the initial EDNS specification nor the revised EDNS specification. ns2.abudawood.com appears to be a old Microsoft DNS server which fails to respond to EDNS queries after the first one. Failure to respond to consistently to DNS queries breaks recovery from packet loss. Both these servers need to be replaced with ones that are RFC compliant. EDNS Compliance Tester Checking: 'abudawood.com.' as at 2017-02-09T08:37:05Z abudawood.com. @212.118.102.2 (ns1.abudawood.com.): edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed,nosoa edns1opt=formerr,badversion,echoed do=ok ednsflags=ok docookie=formerr,nosoa,echoed edns@512tcp=ok optlist=formerr,nosoa,subnet abudawood.com. @212.118.102.3 (ns2.abudawood.com.): edns=timeout edns1=timeout edns@512=timeout ednsopt=timeout edns1opt=timeout do=timeout ednsflags=timeout docookie=timeout edns@512tcp=status,noopt optlist=timeout The Following Tests Failed Warning: test failures may indicate that some DNS clients cannot resolve the zone or will get a unintended answer or resolution will be slower than necessary. Warning: failure to address issues identified here may make future DNS extensions that you want to use ineffective. In particular echoing back unknown EDNS options and unknown EDNS flags will break future signaling between DNS client and DNS server. We already have examples of this were you cannot depend on the AD flag bit meaning anything in replies because too many DNS servers just echo it back. Similarly the EDNS Client Subnet (ECS) option cannot just be sent to everyone in part because of servers just echoing it back. Plain EDNS (edns) This is the style of the initial query that BIND 9.0.x sends. dig +nocookie +norec +noad +edns=0 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: EDNS over IPv6 See RFC6891 EDNS - Unknown Version Handling (edns1) dig +nocookie +norec +noa
Bind failing to start on new 9.9.4 server
I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, I am building this on a new server. I currently do not have DNSSEC enabled, and not enabling it for the initial migration work. I have looked over changes in named.conf and believe I have made the necessary changes. My named.conf is loading as are the zone files. This is what 'systemctl -l status named' shows: ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2017-02-09 09:08:25 EST; 14min ago Process: 1851 ExecStart=/usr/sbin/named -u named $OPTIONS (code=exited, status=1/FAILURE) Process: 1847 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: view internal: 74.100.IN-ADDR.ARPA Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: view internal: 75.100.IN-ADDR.ARPA Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: view internal: 76.100.IN-ADDR.ARPA Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: view internal: 77.100.IN-ADDR.ARPA Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: view internal: 78.100.IN-ADDR.ARPA Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: view internal: 79.100.IN-ADDR.ARPA Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: named.service: control process exited, code=exited status=1 Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: Unit named.service entered failed state. Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: named.service failed. Not very informative with all those auto empty zone messages. Is there a way to suppress those messages, or is this part of the problem? I worked at viewing /var/log/messages, digging through all those auto empty zone messages and found the following: Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 101.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 102.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 103.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 104.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 105.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 106.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 107.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 108.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 109.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo systemd: named.service: control process exited, code=exited status=1 Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 110.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo systemd: Failed to start Berkeley Internet Name Domain (DNS ). Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 111.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo systemd: Unit named.service entered failed state. Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 112.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo systemd: named.service failed. Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 113.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 114.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 115.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 116.100.I N-ADDR.ARPA Feb 9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 117.100.I named enters failed state and no reason why is given. Perhaps it is the number of empty zones generated? Thank you for your help on this. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 09/02/2017 14:28, Robert Moskowitz wrote: > I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, > I am building this on a new server. I currently do not have DNSSEC > enabled, and not enabling it for the initial migration work. > > I have looked over changes in named.conf and believe I have made the > necessary changes. My named.conf is loading as are the zone files. > This is what 'systemctl -l status named' shows: I'd suggest that you try starting named manually with the '-g' flag so that it sends all output to stderr without forking. This should hopefully reveal why it's failing to start. Ray ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 09-02-2017 15.31, Ray Bellis wrote: > On 09/02/2017 14:28, Robert Moskowitz wrote: >> I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, >> I am building this on a new server. I currently do not have DNSSEC >> enabled, and not enabling it for the initial migration work. >> >> I have looked over changes in named.conf and believe I have made the >> necessary changes. My named.conf is loading as are the zone files. >> This is what 'systemctl -l status named' shows: > I'd suggest that you try starting named manually with the '-g' flag so > that it sends all output to stderr without forking. > > This should hopefully reveal why it's failing to start. I did a similar move, my problem was that the ownership and access properties were not ok. > > Ray > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 02/09/2017 09:31 AM, Ray Bellis wrote: On 09/02/2017 14:28, Robert Moskowitz wrote: I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, I am building this on a new server. I currently do not have DNSSEC enabled, and not enabling it for the initial migration work. I have looked over changes in named.conf and believe I have made the necessary changes. My named.conf is loading as are the zone files. This is what 'systemctl -l status named' shows: I'd suggest that you try starting named manually with the '-g' flag so that it sends all output to stderr without forking. This should hopefully reveal why it's failing to start. Since I use systemctl to start the service, I would have to do some digging to figure out something like this that i haven't done in a couple decades. :) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
Am 09.02.2017 um 15:44 schrieb Robert Moskowitz: On 02/09/2017 09:31 AM, Ray Bellis wrote: On 09/02/2017 14:28, Robert Moskowitz wrote: I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, I am building this on a new server. I currently do not have DNSSEC enabled, and not enabling it for the initial migration work. I have looked over changes in named.conf and believe I have made the necessary changes. My named.conf is loading as are the zone files. This is what 'systemctl -l status named' shows: I'd suggest that you try starting named manually with the '-g' flag so that it sends all output to stderr without forking. This should hopefully reveal why it's failing to start. Since I use systemctl to start the service, I would have to do some digging to figure out something like this that i haven't done in a couple decades. :) systemd typically is catching stdout and sterr and forward it to the journal and when that don't echo out errors starting named by hand is easy just take the "ExecStart" line, look in the environment file which defines $OPTIONS, add them and finally -g and press enter ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 02/09/2017 09:31 AM, Ray Bellis wrote: On 09/02/2017 14:28, Robert Moskowitz wrote: I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, I am building this on a new server. I currently do not have DNSSEC enabled, and not enabling it for the initial migration work. I have looked over changes in named.conf and believe I have made the necessary changes. My named.conf is loading as are the zone files. This is what 'systemctl -l status named' shows: I'd suggest that you try starting named manually with the '-g' flag so that it sends all output to stderr without forking. This should hopefully reveal why it's failing to start. '-g' is not a valid option. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 2/9/17 8:53 AM, Robert Moskowitz wrote: > > > On 02/09/2017 09:31 AM, Ray Bellis wrote: >> On 09/02/2017 14:28, Robert Moskowitz wrote: >>> I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, >>> I am building this on a new server. I currently do not have DNSSEC >>> enabled, and not enabling it for the initial migration work. >>> >>> I have looked over changes in named.conf and believe I have made the >>> necessary changes. My named.conf is loading as are the zone files. >>> This is what 'systemctl -l status named' shows: >> I'd suggest that you try starting named manually with the '-g' flag so >> that it sends all output to stderr without forking. >> >> This should hopefully reveal why it's failing to start. >> > '-g' is not a valid option. "named -g" isn't valid? Wow, they really HAVE changed the code. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
Am 09.02.2017 um 15:53 schrieb Robert Moskowitz:
On 02/09/2017 09:31 AM, Ray Bellis wrote:
On 09/02/2017 14:28, Robert Moskowitz wrote:
I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4,
I am building this on a new server. I currently do not have DNSSEC
enabled, and not enabling it for the initial migration work.
I have looked over changes in named.conf and believe I have made the
necessary changes. My named.conf is loading as are the zone files.
This is what 'systemctl -l status named' shows:
I'd suggest that you try starting named manually with the '-g' flag so
that it sends all output to stderr without forking.
This should hopefully reveal why it's failing to start.
'-g' is not a valid option
it is but you can't have "-f" and "-g" - only one of them
usage: named [-4|-6] [-c conffile] [-d debuglevel] [-E engine] [-f|-g]
[-n number_of_cpus] [-p port] [-s] [-S sockets] [-t chrootdir]
[-u username] [-U listeners] [-m
{usage|trace|record|size|mctx}]
usage: named [-v|-V]
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 02/09/2017 09:55 AM, Alan Clegg wrote: On 2/9/17 8:53 AM, Robert Moskowitz wrote: On 02/09/2017 09:31 AM, Ray Bellis wrote: On 09/02/2017 14:28, Robert Moskowitz wrote: I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, I am building this on a new server. I currently do not have DNSSEC enabled, and not enabling it for the initial migration work. I have looked over changes in named.conf and believe I have made the necessary changes. My named.conf is loading as are the zone files. This is what 'systemctl -l status named' shows: I'd suggest that you try starting named manually with the '-g' flag so that it sends all output to stderr without forking. This should hopefully reveal why it's failing to start. '-g' is not a valid option. "named -g" isn't valid? Wow, they really HAVE changed the code. Careless me. I tried 'bind -g' rather than 'named -g' Problem when a major service, bind, is the same as a program function. ARGH!!! :) Making some headway. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
Strange.. On 02/09/2017 09:31 AM, Ray Bellis wrote: On 09/02/2017 14:28, Robert Moskowitz wrote: I am migrating to Centos7 from Centos6. Going from Bind 9.8.2 to 9.9.4, I am building this on a new server. I currently do not have DNSSEC enabled, and not enabling it for the initial migration work. I have looked over changes in named.conf and believe I have made the necessary changes. My named.conf is loading as are the zone files. This is what 'systemctl -l status named' shows: I'd suggest that you try starting named manually with the '-g' flag so that it sends all output to stderr without forking. This should hopefully reveal why it's failing to start. Now doing it 'right' and seeing: 09-Feb-2017 09:59:52.191 could not open file '/run/named/named.pid': Permission denied 09-Feb-2017 09:59:52.192 generating session key for dynamic DNS 09-Feb-2017 09:59:52.192 could not open file '/run/named/session.key': Permission denied 09-Feb-2017 09:59:52.193 could not create /run/named/session.key 09-Feb-2017 09:59:52.193 failed to generate session key for dynamic DNS: permission denied 09-Feb-2017 09:59:52.193 sizing zone task pool based on 21 zones so perhaps some permissions problems? I am su as root. then after all the auto zones: 09-Feb-2017 09:59:53.682 all zones loaded 09-Feb-2017 09:59:53.690 running 09-Feb-2017 09:59:53.691 zone 128.168.192.in-addr.arpa/IN/internal: sending notifies (serial 2009031701) 09-Feb-2017 09:59:53.692 zone labs.htt-consult.com/IN/internal: sending notifies (serial 2015031801) 09-Feb-2017 09:59:53.695 zone home.htt/IN/internal: sending notifies (serial 2013041501) 09-Feb-2017 09:59:53.719 zone labs.htt-consult.com/IN/external: sending notifies (serial 2015031801) 09-Feb-2017 09:59:53.726 zone htt-consult.com/IN/external: sending notifies (serial 2015123001) 09-Feb-2017 09:59:53.732 error (network unreachable) resolving 'ns1.icsl.net/A/IN': 2001:503:c27::2:30#53 09-Feb-2017 09:59:53.734 error (network unreachable) resolving './DNSKEY/IN': 2001:503:c27::2:30#53 09-Feb-2017 09:59:53.735 error (network unreachable) resolving 'ns1.icsl.net//IN': 2001:503:c27::2:30#53 09-Feb-2017 09:59:53.736 error (network unreachable) resolving './NS/IN': 2001:503:c27::2:30#53 09-Feb-2017 09:59:53.818 error (unexpected RCODE REFUSED) resolving 'ns1.icsl.net/A/IN': 12.36.173.2#53 09-Feb-2017 09:59:53.820 error (unexpected RCODE REFUSED) resolving 'ns1.icsl.net//IN': 12.36.173.2#53 09-Feb-2017 09:59:53.822 error (unexpected RCODE REFUSED) resolving 'ns2.icsl.net/A/IN': 12.36.173.2#53 09-Feb-2017 09:59:53.843 error (unexpected RCODE REFUSED) resolving 'ns2.icsl.net//IN': 12.36.173.2#53 09-Feb-2017 09:59:53.918 error (network unreachable) resolving 'ns1.mudkips.net/A/IN': 2607:f4b8:2600:6::1#53 Now why am I getting network unreachable? I can ping out to a lot of addrs. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 09/02/2017 15:32, Robert Moskowitz wrote: > Now doing it 'right' and seeing: > > 09-Feb-2017 09:59:52.191 could not open file '/run/named/named.pid': > Permission denied > 09-Feb-2017 09:59:52.192 generating session key for dynamic DNS > 09-Feb-2017 09:59:52.192 could not open file '/run/named/session.key': > Permission denied > 09-Feb-2017 09:59:52.193 could not create /run/named/session.key > 09-Feb-2017 09:59:52.193 failed to generate session key for dynamic DNS: > permission denied > 09-Feb-2017 09:59:52.193 sizing zone task pool based on 21 zones > > so perhaps some permissions problems? I am su as root. Are you specifying the '-u ' flag to named, and does that user have read / write permissions to /run/named ? [ also, does the config specify use of chroot? ] > then after all the auto zones: > > ... > > Now why am I getting network unreachable? I can ping out to a lot of > addrs. The errors all relate to IPv6 ... Ray ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SOLVED - Re: Bind failing to start on new 9.9.4 server
File permission problems. On 02/09/2017 10:38 AM, Ray Bellis wrote: On 09/02/2017 15:32, Robert Moskowitz wrote: Now doing it 'right' and seeing: 09-Feb-2017 09:59:52.191 could not open file '/run/named/named.pid': Permission denied 09-Feb-2017 09:59:52.192 generating session key for dynamic DNS 09-Feb-2017 09:59:52.192 could not open file '/run/named/session.key': Permission denied 09-Feb-2017 09:59:52.193 could not create /run/named/session.key 09-Feb-2017 09:59:52.193 failed to generate session key for dynamic DNS: permission denied 09-Feb-2017 09:59:52.193 sizing zone task pool based on 21 zones so perhaps some permissions problems? I am su as root. Are you specifying the '-u ' flag to named, and does that user have read / write permissions to /run/named ? [ also, does the config specify use of chroot? ] then after all the auto zones: ... Now why am I getting network unreachable? I can ping out to a lot of addrs. When I rsynced all my backed up zone files, I then had to chown in /var/named. Well, I set /var/named/data to root:named, this made named create /var/named/data/named.run as root:named, which then named could not write to! did a chown to named:named, rm the bad named.run, restarted named, and all is working. nits They get you every time. Thanks for the help. Bob ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failing to start on new 9.9.4 server
On 09/02/17 14:51, Reindl Harald wrote: just take the "ExecStart" line, look in the environment file which defines $OPTIONS, add them and finally -g and press enter On RH-based systems, the SELinux transition behaviour is different running something from the CLI versus init scripts/systemd, so be aware of that. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
