dnssec-policy behaviour
I've been testing the dnssec-policy (9.15.8)feature, but either I've come across a bug, or my understanding of the configuration is incomplete. Whenever BIND restarts, it adds a new key (or keys, depending on the policy) into the configured key directory. It uses this new key or keys to sign the zone, apparently ignoring previously created keys, although the DNSKEY records remain within the zone. I have observed the same behaviour if I initiate an rndc loadkeys . I've tried both the default policy and an explicitly configured policy with the same results. There's nothing in the logs indicating an error loading previous keys. Am I missing something? -- Kal Feher ___ 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: Centos and RHEL 8 COPR packages
Replying to my own question I just noticed #1258 in Gitlab bind9/issues is on the same topic. If the OS release was not listed on the isc copr site, it might be less confusing. On 17 Oct 2019, 11:08 AM +1100, Kal Feher , wrote: > The copr repositories for centos8 appear to be empty of any packages. Is this > deliberate and if so, where can I find the timeline for bind rpms to be added > to these repos? > > I’ve noted the recent posts regarding changes in package distribution > locations. But I don’t see any explicit statement that rhel/centos8 packages > are not being built. > > -- > Kal Feher > > ___ 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
Centos and RHEL 8 COPR packages
The copr repositories for centos8 appear to be empty of any packages. Is this deliberate and if so, where can I find the timeline for bind rpms to be added to these repos? I’ve noted the recent posts regarding changes in package distribution locations. But I don’t see any explicit statement that rhel/centos8 packages are not being built. -- Kal Feher ___ 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: new version of bind
Those issues you describe are likely not related to the version, rather the configuration. Should you suffer those symptoms again, post their description and your config here and we¹ll try to help out as best we can :) When upgrading anything of value I would suggest trying it on a test system. Luckily with BIND, that should be fairly easy. Depending on how you feel, this might be an opportunity to clean up an old config. If not, then you can use your existing config and test how the upgrade will affect it without causing your company problems. confirm that the latest BIND 9.6.0-P1 can be helpful in ISP¹s environment Yes it can be helpful for an ISP. Check out the announcement with each major release for full details. But significantly, 9.6 will contain a lot more DNSSEC support/features than 9.3.4. Here is a very brief page with the highlights: https://www.isc.org/software/bind/new-features Also note that 9.3.4 is no longer a current release. On 8/6/09 1:00 PM, Mohammed Ejaz me...@cyberia.net.sa wrote: Hi, I am sysadmin of one of the leading ISPs of Saudi Arabia, I am going to upgrade the bind which is from BIND 9.3.4-P1 to the latest one, so please can any one confirm that the latest BIND 9.6.0-P1 can be helpful in ISP¹s environment. As I have experienced some issues earlier when I installed the BIND 9.5.1-P2 version, such as problem in opening the websites and slow browsing issues etc... Ejaz ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single Zone Forwarding Dilema
First you should check that you can receive a valid response for the intended zone from your forwarders (from your caching server) not from your pc. It wasn't clear from your initial email that this is what you did. yourcacheserver ~ # dig @forwarder_address A host.fwd.zone.net Although it may seem appropriate to mask the domain you are looking up. It does make solving your problem quite difficult. If the above test works yet other queries fail, I would suggest providing the full result of a: yourlocalpc ~ # dig @yourcacheserver A host.fwd.zone.net You may also wish to provide the query logs for this query. On 8/6/09 4:01 PM, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 06.06.09 01:10, Ben Croswell wrote: If you want to force forwarding you will probably want to add the forward only; directive. By default your server will try to follow NS delegations and then forward if it can't follow them I think it's the opposite - the server will try to query the configured forwarders first, then to continus in usual NS resolution. Forward only; tells it to not even bother trying to follow NS delegations. and thus I recomment not to use this for public zones - if the forwarders are unavailable or from some reason can't answer, the classic resolution will be used. I guess the configured forwarders have one of these problems -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: glue record
Your domain is still broken. You need to remove the NS record for your internal host. $ dig @dns2.gdpu.cn gdpu.cn ns ;; ANSWER SECTION: gdpu.cn.3600IN NS dns1.gdpu.cn. gdpu.cn.3600IN NS dns2.gdpu.cn. gdpu.cn.3600IN NS dns4.dmz.local.** ;; ADDITIONAL SECTION: dns1.gdpu.cn. 3600IN A 219.136.229.41 dns2.gdpu.cn. 3600IN A 219.136.229.42 dns4.dmz.local. 3600IN A 10.55.11.11** On 13/5/09 11:18 AM, Tech W. tech...@yahoo.com.cn wrote: Oh yes, I have got it. Thanks. --- On Wed, 13/5/09, Stephane Bortzmeyer bortzme...@nic.fr wrote: From: Stephane Bortzmeyer bortzme...@nic.fr Subject: Re: glue record To: Tech W. tech...@yahoo.com.cn Cc: Stephane Bortzmeyer bortzme...@nic.fr, bind-users@lists.isc.org Received: Wednesday, 13 May, 2009, 3:40 PM On Wed, May 13, 2009 at 03:37:19PM +0800, Tech W. tech...@yahoo.com.cn wrote a message of 39 lines which said: if I understand for it correctly, gdpu.cn is not under b.dns.cn, True, but irrelevant. why b.dns.cn returns glues? Because the name servers of gdpu.cn are under gdpu.cn. Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY 2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHR tX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creati veholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=ma iltagline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no NS but having A record
The zone appears to be configured incorrectly. That is why your results and Scott's are so odd. I'll explain below, but in summary, the name servers to which the zone is delegated have what appears to be rubbish records. Specifically these: gdpu.cn.3600IN NS gdpu.cn. gdpu.cn.3600IN NS dns4.dmz.local. ;; ADDITIONAL SECTION: gdpu.cn.3600IN A 219.136.229.43 dns4.dmz.local. 3600IN A 10.55.11.11 I'll explain in a little more detail... First check the delegation: (I've reduced the output for the sake of readability) arapahoe:~ kfeher$ dig ns cn +short a.dns.cn. ns.cernet.net. b.dns.cn. d.dns.cn. c.dns.cn. e.dns.cn. Then query one of those servers for the domains NS record: arapahoe:~ kfeher$ dig ns gdpu.cn @D.DNS.cn ;; AUTHORITY SECTION: gdpu.cn.21600 IN NS dns1.gdpu.cn. gdpu.cn.21600 IN NS dns2.gdpu.cn. ;; ADDITIONAL SECTION: dns1.gdpu.cn. 21600 IN A 219.136.229.41 dns2.gdpu.cn. 21600 IN A 219.136.229.42 This is correct so far. Lets see if the 2 name servers agree... arapahoe:~ kfeher$ dig ns gdpu.cn @dns2.gdpu.cn ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; ANSWER SECTION: gdpu.cn.3600IN NS gdpu.cn. gdpu.cn.3600IN NS dns4.dmz.local. ;; ADDITIONAL SECTION: gdpu.cn.3600IN A 219.136.229.43 dns4.dmz.local. 3600IN A 10.55.11.11 A 10.x.x.x address is an rfc1918 address and is either internal zone information leaking to the outside world, or just plan wrong. In any case you will not be able to query it. The other address does not respond to DNS queries. I suspect this is in fact a webserver accidentally listed as a nameserver. Note that the reason your queries fail is because name servers are supposed to assume that the apex of the zone contains the most correct data. Therefore if the 2 name servers to which this zone is delegated respond with rubbish, your resolver will cache that rubbish. If you know the owner of that domain their name server should have these 2 records most likely: gdpu.cn.21600 IN NS dns1.gdpu.cn. gdpu.cn.21600 IN NS dns2.gdpu.cn. On 11/5/09 12:57 PM, Tech W. tech...@yahoo.com.cn wrote: Hi, Firstly the DNS serveres for that domain is not mastered by me. I got the NS dig info as below. You can see, if I specify another public DNS (211.66.80.161), the results can be fetched. If I don't specify a DNS (use the default one 202.96.128.143 of my ISP), dig gets nothing. So I'm really confused on their configure. Please help again, thanks~ # dig gdpu.cn ns @211.66.80.161 ; DiG 9.5.0-P2 gdpu.cn ns @211.66.80.161 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 57139 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; ANSWER SECTION: gdpu.cn.21347 IN NS dns2.gdpu.cn. gdpu.cn.21347 IN NS dns1.gdpu.cn. ;; ADDITIONAL SECTION: dns2.gdpu.cn. 21347 IN A 219.136.229.42 dns1.gdpu.cn. 21347 IN A 219.136.229.41 ;; Query time: 3 msec ;; SERVER: 211.66.80.161#53(211.66.80.161) ;; WHEN: Mon May 11 18:51:19 2009 ;; MSG SIZE rcvd: 95 # dig gdpu.cn ns ; DiG 9.5.0-P2 gdpu.cn ns ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 15877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; Query time: 1 msec ;; SERVER: 202.96.128.143#53(202.96.128.143) ;; WHEN: Mon May 11 18:51:24 2009 ;; MSG SIZE rcvd: 25 --- On Mon, 11/5/09, Scott Haneda talkli...@newgeo.com wrote: I do not think you can have a .local NS. Both of those NS's have to be reachable by the outside world, and .local is not. It may be on your local lan, but outside that, it will not be. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Relevant RFC on A records for NS's
When I clicked on that link the only error was an MNAME error. Did you see another error? (I wonder if it was a transient error you observed, because it appears different to yours). The error according to the report (run against isc.org): ERROR: Your SOA (Start of Authority) record states that your master (primary) name server is: ns-int.isc.org. That server is not listed at the parent servers, which is not correct. $ dig soa isc.org +short ns-int.isc.org. hostmaster.isc.org. 2009042800 7200 3600 24796800 3600 $ dig ns isc.org +short ord.sns-pb.isc.org. sfba.sns-pb.isc.org. ns-ext.nrt1.isc.org. ams.sns-pb.isc.org. So the report states that the MNAME is not one of the listed name servers. This appears to be true. Checking your domain: newgeo.com (did you mean this one or another?). The error is a different one. Your name servers: $ dig ns newgeo.com +short ns1.nacio.com. ns1.hostwizard.com. Now the report wants to check each name server: $ dig ns1.hostwizard.com @ns1.nacio.com +short 64.84.37.14 That worked. $ dig ns1.nacio.com @ns1.hostwizard.com ; DiG 9.4.2-P2 ns1.nacio.com @ns1.hostwizard.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: REFUSED, id: 24774 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.nacio.com. IN A This one didnt So to answer your question what is this error asking of me?. It wants ns1.hostwizard.com to reply as ns1.nacio.com did. Specifically to answer an A record query for ns1.nacio.com. On 30/4/09 10:12 AM, Scott Haneda talkli...@newgeo.com wrote: Someone pointed me to this http://thednsreport.com/?domain=isc.org I am not a huge fan of these checking tools, this one has me curious. My domain of course has the same error, which is a little comforting, sine I am in good company :) What is this error asking of me, they are wanting in my case, A records for NS's? I am pretty sure I have those, as does isc.org. ns-ext.nrt1.isc.org. 3600 IN A 192.228.90.19 So what in the world is this tool reporting? -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
