Re: redundant bump-in-the-wire signers using BIND
Michael Sinatra wrote: > > My only concern is that serial numbers might get out of sync between the > two signers at some point. You can avoid this problem with `serial-update-method unixtime`. HOWEVER! I think you are going to have problems with inconsistent IXFRs depending on which signer the public authoritative servers talk to. You can work around this by only using AXFR, by turning off `provide-ixfr` and `request-ixfr`. If this is going to be painful for you because of zone sizes, you might consider getting dirty with dnssec-signzone which gives you more control over when signing happens and RRSIG validity periods. I think (depending on the signature algorithm) this will allow you to ensure that the two signers produce the same zones at the same times. But it'll require a fair amount of fiddling to get right. (My recovery plan for a failed signer is to reprovision a replacement from scratch.) Tony. -- f.anthony.n.finchhttp://dotat.at/ individual and social justice ___ 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
Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.
Dear Bind-Users, Greetings of the Day!!! I have faced an issue on my RPZ Server. I have added the A record Entry & record entry for some domains. The RPZ Policy is running fine. But the werired response that i am getting with few domains are that when I have quered the A record for that domain, the answer is OK. When I have quered for record, it is not given the answer. When I have run the dig query using any option, it has shown me the A record as well as record too. I have facing this issue while querying following domains: 1. gim8.pl 2. ns-cnc1.qq.com 3. ns-tel1.qq.com Lets take an example of first doamin: I have sharing the dig o/p here with different options: A. querying A Record: - ; <<>> DiG 9.10.3-P3 <<>> gim8.pl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gim8.pl. IN A ;; ANSWER SECTION: gim8.pl.5 IN A 10.40.124.13 ;; AUTHORITY SECTION: rpz.nkn.in. 3600IN NS ns1.rpz.nkn.in. ;; ADDITIONAL SECTION: ns1.rpz.nkn.in. 3600IN A 10.199.88.2 ;; Query time: 4406 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 22 17:22:57 IST 2018 ;; MSG SIZE rcvd: 96 B: Query the Record: - ; <<>> DiG 9.10.3-P3 <<>> gim8.pl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60907 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gim8.pl. IN ;; Query time: 517 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 22 17:24:13 IST 2018 ;; MSG SIZE rcvd: 36 C: Query the Record with ANY option: -- ; <<>> DiG 9.10.3-P3 <<>> gim8.pl any ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gim8.pl. IN ANY ;; ANSWER SECTION: gim8.pl.5 IN 2001:4408:5240::13 gim8.pl.5 IN A 10.40.124.13 ;; AUTHORITY SECTION: rpz.nkn.in. 3600IN NS ns1.rpz.nkn.in. ;; ADDITIONAL SECTION: ns1.rpz.nkn.in. 3600IN A 10.199.88.2 ;; Query time: 821 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 22 17:24:42 IST 2018 ;; MSG SIZE rcvd: 124 Last o/p shows the record too...but alone its not working. I am sharing you the messages that i received when I hit the query using dig: May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': 104.130.132.112#53 May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': 198.245.62.20#53 May 22 17:25:46 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': 104.130.132.112#53 May 22 17:25:46 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': 198.245.62.20#53 Can anyone suggest, what goes wrong & why the RPZ policy is not throuugh the result when the dig alone run with query? Thanks & Regards, Saurabh Srivastava, Mobile: +91-9958399291 Email: jp.saur...@gmail.com ___ 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: Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.
Saurabh Srivastava wrote: > I have faced an issue on my RPZ Server. > I have added the A record Entry & record entry for some domains. > The RPZ Policy is running fine. > But the werired response that i am getting with few domains are that when I > have quered the A record for that domain, the answer is OK. > When I have quered for record, it is not given the answer. > May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl//IN': > 104.130.132.112#53 RPZ is a bit weird because it performs the query as usual, then applies its rewrite rules. In this case, the original query fails, so there isn't an in the answer to rewrite. You can set the `qname-wait-recurse` option, so that RPZ will skip recursion when it is able to rewrite a response based only on the query. You might also want to set `break-dnssec` to make it ignore the DO bit. If you are using `qname-wait-recurse`, you need to be careful about the order of the policy zones listed in your RPZ clause so that it works as expected: you should keep qname and client-ip triggers in separate zones, and list those zones first - other RPZ rewrite rules force recursion to happen. The manual says the reason for this weird behaviour is: "not resolving the requested name can leak the fact that response policy rewriting is in use and that the name is listed in a policy zone to operators of servers for listed names." If you are worried about that, it implies that (sadly) you have an adversarial relationship with your users, since they are the only people who can observe this information leak. In my opinion your users should be able to trust you, so you should be up-front about DNS rewriting, and you should explain to your users clearly what your rewrite policy is. And if you have documented your policy, there's no information leak because the information is in the documentation. Tony. -- f.anthony.n.finchhttp://dotat.at/ promote human rights and open government ___ 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
nsupdate with RPZ
Hi Team, Wondering if anyone have a working How-To guide for implementing nsupdate with RPZ? I mean do we need to configure any specific settings in zone of Options? Please advise TIA ___ 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: redundant bump-in-the-wire signers using BIND
Tony, Our environment has the secondary set up as a slave with 'raw' zones in the same paths, so upon primary failure, change the zone roles to 'master' and include the inline signing stanzas. They keys are duplicated using an external process. Happy days. Now if only BIND could to a true multi-master-signer. Oh, the pipe dreams! Stuart > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Tony Finch > Sent: Tuesday, 22 May 2018 8:23 PM > To: Michael Sinatra > Cc: bind-users@lists.isc.org > Subject: Re: redundant bump-in-the-wire signers using BIND > > > (My recovery plan for a failed signer is to reprovision a replacement > from scratch.) ___ 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
