Re: DS keys with 2 digest algorithms
Hi, Thanks for this confirmation. I had our registrar remove the digest algorithm SHA1 DS entry and this has worked as expected. No errors or warnings at any DNSSEC checkers. Maybe in the future dnssec-signzone won't generate the deprecated entry to begin with. On Tue, Sep 20, 2022 at 3:44 PM Mark Elkins wrote: > Just remove the type-1 digest from the domain registrar. > > In the future - only upload type type-2 version. > On 2022/09/20 20:32, frank picabia wrote: > > > The algorithm migration I made to 8 has worked well. > Getting green lights on DNSSEC checkers, etc. > > The only odd bit is some warnings at DNSVIS.NET > about DS records using digest algorithm 1. > > DNSSEC specification prohibits signing with DS records that use digest > algorithm 1 (SHA-1). > > Somehow the way I do the zone signing results in 2 pairs of DS > records - one with digest algorithm 2 and one with algorithm 1. > > This is the command I've been running lately: > > /sbin/dnssec-signzone -A -3 - -N keep -o mydomain.ca -t -f > forward/mydomain.ca.signed forward/mydomain.ca > > As per the howtos I followed years ago, I've provided the domain registrar > with both DS key records (one key number, two digest algorithms). > > mydomain.ca. IN DS 20084 8 1 42419294EC592BFE044D256126F0420212E4E619 > mydomain.ca. IN DS 20084 8 2 > 827039A146CD8CD4528627BCB1351219FA7C36CFA54F702F2592047DEFE9C416 > > In the diagram at DNSVIS.NET, it looks like the DS with alg 1 > is dangling at the top level domain (.ca) with the yellow warning as per > above, > while the alg 2 links to my domain's DNSKEY properly. > > How should I tidy up this digest algo 1? Do I simply remove it at the > domain registrar, > or is there a better way to run dnssec-signzone? > > > > > -- > > Mark James ELKINS - Posix Systems - (South) Africa > m...@posix.co.za Tel: +27.826010496 <+27826010496> > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > [image: Posix Systems][image: VCARD for MJ Elkins] > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DS keys with 2 digest algorithms
The algorithm migration I made to 8 has worked well. Getting green lights on DNSSEC checkers, etc. The only odd bit is some warnings at DNSVIS.NET about DS records using digest algorithm 1. DNSSEC specification prohibits signing with DS records that use digest algorithm 1 (SHA-1). Somehow the way I do the zone signing results in 2 pairs of DS records - one with digest algorithm 2 and one with algorithm 1. This is the command I've been running lately: /sbin/dnssec-signzone -A -3 - -N keep -o mydomain.ca -t -f forward/mydomain.ca.signed forward/mydomain.ca As per the howtos I followed years ago, I've provided the domain registrar with both DS key records (one key number, two digest algorithms). mydomain.ca. IN DS 20084 8 1 42419294EC592BFE044D256126F0420212E4E619 mydomain.ca. IN DS 20084 8 2 827039A146CD8CD4528627BCB1351219FA7C36CFA54F702F2592047DEFE9C416 In the diagram at DNSVIS.NET, it looks like the DS with alg 1 is dangling at the top level domain (.ca) with the yellow warning as per above, while the alg 2 links to my domain's DNSKEY properly. How should I tidy up this digest algo 1? Do I simply remove it at the domain registrar, or is there a better way to run dnssec-signzone? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What action to take first with DS algorithm migration?
That's a good resource. Thanks, Hugo. On Wed, Sep 14, 2022 at 1:40 PM Hugo Salgado wrote: > On 11:23 14/09, frank picabia wrote: > > Hi, > > > > I'm at the point in DNSSEC algorithm migration > > where I have two types of keys involved in signing. > > Both algorithm 7 and 8 are in use. > > > > The top level domain registrar also has DS keys set up for both 7 and 8. > > > > I need to coordinate pulling out algorithm 7 with the domain registrar so > > our domain will be running against only algo 8. > > > > Should the TLD registrar remove 7 first, or should I remove signing of > zone > > with the algo 7 keys before they make their change? > > > > I noticed that when I tried removing signing with the algo 7 keys, and > > checked > > the DNS state at https://dnsviz.net/d/acadiau.ca/dnssec/ > > > > I saw errors at the analyzer like this: > > > > The DS RRset for the zone included algorithm 7 (RSASHA1NSEC3SHA1), but no > > RRSIG with algorithm 7 covering the RRset was returned in the response. > > > > I'm not sure if that would be a crippling error to DNS functionality > > if I didn't reverse removal of algo 7 signing, which I've done after > seeing > > this. > > > > Can I do removal of algo 7 at one side prior to the > > other (Bind signing vs TLD Registrar side), > > or do we have to try to coordinate this with the TLD > > registrar as closely as possible? > > If you already have the two DS at your parent, the next step is > removing the old DS, then wait, then remove the old KSK (but > still have the old ZSK and old signatures), then wait, then > remove everything from the old algorithm. > > For adding a new DS is the other way around. You first add the > new ZSK + signatures, then the KSK, then the DS at your parent. > > Here's an step by step method, in spanish, but hopefully the > diagrams are self explanatory: > > https://hugo.salga.do/post/615501933278642176/c%C3%B3mo-hacer-un-rollover-de-algoritmo-en-dnssec > > Hugo > > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
What action to take first with DS algorithm migration?
Hi, I'm at the point in DNSSEC algorithm migration where I have two types of keys involved in signing. Both algorithm 7 and 8 are in use. The top level domain registrar also has DS keys set up for both 7 and 8. I need to coordinate pulling out algorithm 7 with the domain registrar so our domain will be running against only algo 8. Should the TLD registrar remove 7 first, or should I remove signing of zone with the algo 7 keys before they make their change? I noticed that when I tried removing signing with the algo 7 keys, and checked the DNS state at https://dnsviz.net/d/acadiau.ca/dnssec/ I saw errors at the analyzer like this: The DS RRset for the zone included algorithm 7 (RSASHA1NSEC3SHA1), but no RRSIG with algorithm 7 covering the RRset was returned in the response. I'm not sure if that would be a crippling error to DNS functionality if I didn't reverse removal of algo 7 signing, which I've done after seeing this. Can I do removal of algo 7 at one side prior to the other (Bind signing vs TLD Registrar side), or do we have to try to coordinate this with the TLD registrar as closely as possible? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Only one DS key comes back in query
Thanks for this detailed information, Mark. I'll blame it on the antibiotics and old age but I had never noticed the key is actually complete in my dsset file if I don't interpret the space as a delimiter. So there are two ways to get the DS keys: from the dsset file while ignoring the space between the two values of digest 2, or by using the dnssec-dsfromkey method while querying one's DNS server. My domain registrar has the values now and we're good. Thanks for the assistance. On Wed, May 18, 2022 at 2:16 PM Mark Andrews wrote: > I suspect that you failed to copy the complete second record or that the > registrar failed to handle the optional white space in the last field. > Without you posting the contents of the dsset file and what you passed to > the registrar there is no way to know. There is also no way to know if it > was miscomputed unless we have a copy of the DNSKEY it was generated from. > > example.com. IN DS 28387 5 1 47145FCABDFC00DD9CDE1369FA6A456F0D196C11 > example.com. IN DS 28387 5 2 > AC92037CEB08E7AF3539D140BC3855FA32AB0055973ABC7A4FB4A49C 385E7C29 > > The second record could be written like below and it would still be > correct. > > example.com. IN DS 28387 5 2 A C 9 2 0 3 7 C E B 0 8 E 7 A F 3 5 3 9 D 1 > 4 0 B C 3 8 5 5 F A 3 2 A B 0 0 5 5 9 7 3 A B C 7 A 4 F B 4 A 4 9 C 3 8 5 E > 7 C 2 9 > > As for how many records there are in the dsset file that has changed over > time. It started out as just type 1 (SHA1), then type 1 (SHA1) and type 2 > (SHA256), and more recently just type 2 (SHA256) as the DNSSEC standards > evolve based on changes in cryptographic best practice. DNSSEC is > approximately 20 years old now and computing capabilities have changed a > lot over that period. > > I know computers are not infallible but dnssec-signzone has been > generating dsset files for almost all of those 20 years now. We would be > getting thousands of reports of errors if it was mis-generating DS > records. Named itself needs to generate 10’s of thousands of DS records a > second to perform DNSSEC validations on a busy validator and > dnssec-signzone uses the same code to generate the DS records it prints out. > > Using ‘example’ is fine until something goes wrong or it is believed to > have gone wrong. At that point you need the actual real names. You don’t > go to your mechanic with a different car when you have a problem with your > car. Using ‘example’ is like doing that. > > Mark > > > > On 17 May 2022, at 04:41, frank picabia wrote: > > > > I've been using open source for decades. Long enough that I rarely need > to use lists for help. > > > > Here's the RFC mentioning reserved domain name use: > https://www.rfc-editor.org/rfc/rfc2606.html > > > > I am ridiculed by an ISC member for using a reserved domain according to > the purpose in the RFC and then > > a second ISC member states I am arrogant? I think there's a bunch of > you that need to check your privilege! > > Or maybe these persons are the chief whips responsible for driving > people from the lists into paying customers? > > > > Check other lists. Postfix. Apache. Whatever. No one ever has an > issue when they see example.com > > It's widely known as the boilerplate value you're leaving out of the > equation for the moment. > > > > In the documentation I see this: > > > > Once the rndc reconfig command is issued, BIND serves a signed zone. The > file dsset-example.com (created by dnssec-signzone when it signed the > example.com zone) contains the DS record for the zone’s KSK. You will > need to pass that to the administrator of the parent zone, to be placed in > the zone. > > > > It seems the first value in dsset file is okay. The documentation > doesn't talk about the second one, and this is where > > the problem is seen. I see one value on the second key (digest 2) in > dsset file, and a different value using the value > > obtained by running something like: > > > > dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f – irrashai.net > > The digest 2 second key here seems to be what should be used with the > domain registrar. I'll soon find out. > > > > > > > > On Mon, May 16, 2022 at 2:54 PM Ondřej Surý wrote: > > Well, then don’t expect people will want to help you. If you need to > hide the information and you need help then you should be prepared to pay > for the support. Coming to open source list asking for help for free and > expect other people to help you is just plain arrogant behavior. Again, > Bert Hubert was exactly right here: > > > > https://berthub.eu/articles/posts/anonymous-hel
Re: Only one DS key comes back in query
I've been using open source for decades. Long enough that I rarely need to use lists for help. Here's the RFC mentioning reserved domain name use: https://www.rfc-editor.org/rfc/rfc2606.html I am ridiculed by an ISC member for using a reserved domain according to the purpose in the RFC and then a second ISC member states I am arrogant? I think there's a bunch of you that need to check your privilege! Or maybe these persons are the chief whips responsible for driving people from the lists into paying customers? Check other lists. Postfix. Apache. Whatever. No one ever has an issue when they see example.com It's widely known as the boilerplate value you're leaving out of the equation for the moment. In the documentation I see this: Once the rndc reconfig > <https://bind9.readthedocs.io/en/v9_18_2/manpages.html#cmdoption-rndc-arg-reconfig> > command > is issued, BIND serves a signed zone. The file dsset-example.com (created > by dnssec-signzone > <https://bind9.readthedocs.io/en/v9_18_2/manpages.html#std-iscman-dnssec-signzone> > when > it signed the example.com zone) contains the DS record for the zone’s > KSK. You will need to pass that to the administrator of the parent zone, to > be placed in the zone. It seems the first value in dsset file is okay. The documentation doesn't talk about the second one, and this is where the problem is seen. I see one value on the second key (digest 2) in dsset file, and a different value using the value obtained by running something like: dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f – irrashai.net The digest 2 second key here seems to be what should be used with the domain registrar. I'll soon find out. On Mon, May 16, 2022 at 2:54 PM Ondřej Surý wrote: > Well, then don’t expect people will want to help you. If you need to hide > the information and you need help then you should be prepared to pay for > the support. Coming to open source list asking for help for free and expect > other people to help you is just plain arrogant behavior. Again, Bert > Hubert was exactly right here: > > https://berthub.eu/articles/posts/anonymous-help/ > > Ondrej > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > On 16. 5. 2022, at 19:06, frank picabia wrote: > > Suppose I was working on a problem for Barclays > Bank, do you suppose they would be thrilled with me posting > their networking innards for the world to see? > > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Only one DS key comes back in query
Perhaps you are unaware of the use of this domain as a generic filler. https://example.com/ I don't know why so many people assume the DNS information will be openly shared. Suppose I was working on a problem for Barclays Bank, do you suppose they would be thrilled with me posting their networking innards for the world to see? On Mon, May 16, 2022 at 1:50 PM Jan-Piet Mens via bind-users < bind-users@lists.isc.org> wrote: > >The values in the file dsset-example.com generated by signing the zone > are not good. > > If they are 'not good' then it's possible you are using an outdated dsset > file. (And you are hiding domain names; I doubt example.com has been > delegated > to you.) > > dnssec-signzone creates dsset- files when signing a zone > manually/semi-automatically. If you are signing with, say, > autodnssec-maintain, > then no dsset- file is created and you use dnssec-dsfromkey to determine > the DS > which you then submit to your parent zone. > > -JP > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Only one DS key comes back in query
I think I see the problem now. The values in the file dsset-example.com generated by signing the zone are not good. I believe this was the bad value being provided as reported by the registrar. It was mentioned in a user's comment on the DNSSEC guide that using the dsset file wasn't the thing to do. Using one of the other approaches with dnssec-dsfromkey is needed. The values in dsset file begin the same but it's different. On Mon, May 16, 2022 at 11:37 AM frank picabia wrote: > > That's helpful. Very similar to what I found a minute ago on > > https://blog.apnic.net/2019/05/23/how-to-deploying-dnssec-with-bind-and-ubuntu-server/ > > with their example: > > dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f – irrashai.net > > I've done this for my domain and both of my DS keys are showing up. Tried > the dnssec-dsfromkey > with the .key file as well and that sanity check passed. I think I'm set > up all right, > I'll need to check again with the domain registrar. > > Thanks for the assistance. > > > On Mon, May 16, 2022 at 11:15 AM Daniel Stirnimann < > daniel.stirnim...@switch.ch> wrote: > >> If you have the public key file you can do: >> >> dnssec-dsfromkey Kexample.com.+013+55640.key >> example.com. IN DS 55640 13 2 >> CF681BA4D66B41912B4DC525ADFC948218EC3DBA724F266D25BD1702BE8A8BA9 >> >> Or you can query the auth nameserver like this: >> >> dig @localhost example.com. DNSKEY | egrep "IN\sDNSKEY\s257" | >> dnssec-dsfromkey -f - example.com. >> >> Daniel >> >> >> On 16.05.22 16:01, frank picabia wrote: >> > Let's put it another way: >> > >> > Using tools like host or dig, can I look up my DS without it talking to >> > the domain registrar? >> > >> > If it is always getting from the domain registrar, I can't see how to >> > check the DS is set up all right purely within bind. >> > >> > >> > On Mon, May 16, 2022 at 10:16 AM Anand Buddhdev > > <mailto:ana...@ripe.net>> wrote: >> > >> > On 16/05/2022 15:07, frank picabia wrote: >> > >> > Hi Frank, >> > >> > > I have dsset-example.com <http://dsset-example.com> showing two >> DS >> > keys with algorithm 8. >> > > I included both .key files in my DNS. Only digest 1 comes back >> > > in a dig query. >> > > >> > > I use dnssec-signzone tool to sign the zone file. >> > > >> > > The domain registrar says there is a problem with the digest 2 >> value. >> > > It's copied directly from the dsset file. >> > > >> > > Not sure about the chicken and the egg in this case. When I do a >> > dig, is >> > > it really >> > > just getting the value back from the domain registrar? >> > > >> > > Any suggestions on how to ensure my digest 2 DS value is set up >> right? >> > >> > We cannot help you if we cannot see the DS records or know which >> domain >> > they are for. >> > >> > Anand >> > >> > >> > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Only one DS key comes back in query
That's helpful. Very similar to what I found a minute ago on https://blog.apnic.net/2019/05/23/how-to-deploying-dnssec-with-bind-and-ubuntu-server/ with their example: dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f – irrashai.net I've done this for my domain and both of my DS keys are showing up. Tried the dnssec-dsfromkey with the .key file as well and that sanity check passed. I think I'm set up all right, I'll need to check again with the domain registrar. Thanks for the assistance. On Mon, May 16, 2022 at 11:15 AM Daniel Stirnimann < daniel.stirnim...@switch.ch> wrote: > If you have the public key file you can do: > > dnssec-dsfromkey Kexample.com.+013+55640.key > example.com. IN DS 55640 13 2 > CF681BA4D66B41912B4DC525ADFC948218EC3DBA724F266D25BD1702BE8A8BA9 > > Or you can query the auth nameserver like this: > > dig @localhost example.com. DNSKEY | egrep "IN\sDNSKEY\s257" | > dnssec-dsfromkey -f - example.com. > > Daniel > > > On 16.05.22 16:01, frank picabia wrote: > > Let's put it another way: > > > > Using tools like host or dig, can I look up my DS without it talking to > > the domain registrar? > > > > If it is always getting from the domain registrar, I can't see how to > > check the DS is set up all right purely within bind. > > > > > > On Mon, May 16, 2022 at 10:16 AM Anand Buddhdev > <mailto:ana...@ripe.net>> wrote: > > > > On 16/05/2022 15:07, frank picabia wrote: > > > > Hi Frank, > > > > > I have dsset-example.com <http://dsset-example.com> showing two DS > > keys with algorithm 8. > > > I included both .key files in my DNS. Only digest 1 comes back > > > in a dig query. > > > > > > I use dnssec-signzone tool to sign the zone file. > > > > > > The domain registrar says there is a problem with the digest 2 > value. > > > It's copied directly from the dsset file. > > > > > > Not sure about the chicken and the egg in this case. When I do a > > dig, is > > > it really > > > just getting the value back from the domain registrar? > > > > > > Any suggestions on how to ensure my digest 2 DS value is set up > right? > > > > We cannot help you if we cannot see the DS records or know which > domain > > they are for. > > > > Anand > > > > > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Only one DS key comes back in query
Let's put it another way: Using tools like host or dig, can I look up my DS without it talking to the domain registrar? If it is always getting from the domain registrar, I can't see how to check the DS is set up all right purely within bind. On Mon, May 16, 2022 at 10:16 AM Anand Buddhdev wrote: > On 16/05/2022 15:07, frank picabia wrote: > > Hi Frank, > > > I have dsset-example.com showing two DS keys with algorithm 8. > > I included both .key files in my DNS. Only digest 1 comes back > > in a dig query. > > > > I use dnssec-signzone tool to sign the zone file. > > > > The domain registrar says there is a problem with the digest 2 value. > > It's copied directly from the dsset file. > > > > Not sure about the chicken and the egg in this case. When I do a dig, is > > it really > > just getting the value back from the domain registrar? > > > > Any suggestions on how to ensure my digest 2 DS value is set up right? > > We cannot help you if we cannot see the DS records or know which domain > they are for. > > Anand > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Only one DS key comes back in query
I have dsset-example.com showing two DS keys with algorithm 8. I included both .key files in my DNS. Only digest 1 comes back in a dig query. I use dnssec-signzone tool to sign the zone file. The domain registrar says there is a problem with the digest 2 value. It's copied directly from the dsset file. Not sure about the chicken and the egg in this case. When I do a dig, is it really just getting the value back from the domain registrar? Any suggestions on how to ensure my digest 2 DS value is set up right? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Transitioning to new algorithm for DNSSEC
On Thu, May 5, 2022 at 3:48 PM Tony Finch wrote: > frank picabia wrote: > > On Thu, May 5, 2022 at 1:46 PM wrote: > > > > > > Tony wrote a nice article about that: > > > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html > > > > Thanks for that. My problem is these notes have little in common with > how > > the digital ocean guide > > ran it ( > > > https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2 > > ), > > That guide is sadly very out of date. You really don't want to use SHA1 > (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) > and for at least 10 years it has been much easier to use `named`s > automatic signing than to use dnssec-signzone. > > I think if you are still using `dnssec-signzone`, I would recommend > switching over to automatic signing with your existing keys, before doing > an algorithm rollover. And set up a test zone so that you can run through > the process a few times, so that you can learn from your mistakes before > doing it in production. > > > and I don't think our domain registrar supports CDS records. > > You can ignore the CDS stuff - my registrar didn't support it either, but > I have tools that can use my CDS records to work out the correct thing to > tell my registrar to do. > > > I don't understand how people can run little rndc commands as if this > > sticks without putting an include for the keys in the zone file. > > `named` automatically adds the keys to the zone according to the timing > information in the key files. (At least, that's the way I did it before > dnssec-policy made things even more automatic.) > > Agreed that the digital ocean guide is out of date. That's why I'm redoing the steps with algorithm 8. In our case, we have a DNS service to protect from DDOS and we need to transfer the whole zone to them periodically or from updates. I don't think the Bind built-in signing would work for this situation. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Transitioning to new algorithm for DNSSEC
On Thu, May 5, 2022 at 1:46 PM wrote: > Hi, > > On 5/5/22 6:37 PM, frank picabia wrote: > > > > Hi, > > > > I've been running a Bind set up with DNSSEC for many years. > > It was done following the guide at the digitalocean site. > > > > What I don't find in a nice guide, is how to change your algorithm > > to a more current one, and seamlessly make your domain > > run under this new chain of data. > > > > I tried it on my own estimates of what would be required, and > > it seemed to be poisoned by dropping mention of the prior > > keys files in my DNS while the Internet's cached info > > on our DS is still out there. Whatever has happened, > > I've got a running domain again, but there is an angry diagram > > being drawn at https://dnsviz.net/ <https://dnsviz.net/> when my domain > > (which > > will remain nameless) is analyzed. > > > > With DNS it is always hard to tell what is going on NOW due > > to caching, and breakage works this way as well. > > > > Is there a guide on transitioning the DNSSEC signing algorithm, > > or is ISC support the best way to handle this > > and avoid the risk of total DNS calamity? > > Tony wrote a nice article about that: > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html > > Cheers, > > -- > Nico > > Thanks for that. My problem is these notes have little in common with how the digital ocean guide ran it ( https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2 ), and I don't think our domain registrar supports CDS records. I don't understand how people can run little rndc commands as if this sticks without putting an include for the keys in the zone file. In our setting, we re-sign the zone from our host management automation. There's not enough parallel in the world of that Math department's server and what we have in our host management in production. Normally I'd be flexible to play around with something like this if it were apache or something, but I just experienced a domain outage that makes me prefer something I can really believe in. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Transitioning to new algorithm for DNSSEC
Hi, I've been running a Bind set up with DNSSEC for many years. It was done following the guide at the digitalocean site. What I don't find in a nice guide, is how to change your algorithm to a more current one, and seamlessly make your domain run under this new chain of data. I tried it on my own estimates of what would be required, and it seemed to be poisoned by dropping mention of the prior keys files in my DNS while the Internet's cached info on our DS is still out there. Whatever has happened, I've got a running domain again, but there is an angry diagram being drawn at https://dnsviz.net/ when my domain (which will remain nameless) is analyzed. With DNS it is always hard to tell what is going on NOW due to caching, and breakage works this way as well. Is there a guide on transitioning the DNSSEC signing algorithm, or is ISC support the best way to handle this and avoid the risk of total DNS calamity? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Freezing a Zone vs. Stopping the DNS Server
Hi, Occasionally I need to add hosts manually to forward/reverse lookup zones in BIND 9.16. We also have ISC DHCP. Both are on a Mac Mini using MacPorts to install. Since dynamic updates are continually in progress, I understand I need to use *rndc** freeze zone* and *rndc** thaw zone* before and after making changes (including manually incrementing the sequence number). Can I safely accomplish the same thing by issuing an *rndc stop* command? Would that allow me to make zone changes followed by an *rndc reload* command? Also, is it safe to simply reboot the server after OS updates, or is it necessary to manually stop the DNS server first? Does it matter where in the dynamically updated zone files I insert the new host A record and PTR record? With /etc/hosts I can add hosts on different subnets. To do that in DNS, do I first need to add a reverse zone for the additional subnet so that I can add PTR records to correspond to A records in the forward zone? Thanks for any light you can shed on this subject. -- Frank Kyosho Fallon My pronouns are: He, HIm ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
issue with domain forwarding
Hi, Just to let everyone know that I have solved my issue by upgrading to bind-9.16.10. It is working fine now. -- sysadm cronomagic.com e-mail ve2...@canasoft.net POWERED BY LINUX ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
issue with domain forwarding
Here is my entire config:
My machine IP = 66.159.32.31 2606:af00:1::3
key "rndc-key" {
algorithm hmac-md5;
secret "y4xt0wQJOiOiZmVaWSMgnQ==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
acl local {
127.0.0.1;
66.159.32.31;
::1;
2606:af00::/32;
};
options {
directory "/var/named";
pid-file "/var/run/named.pid";
allow-recursion { local; };
listen-on-v6 { any; };
};
logging {
category lame-servers { null; };
category edns-disabled { null; };
category resolver { null; };
channel security_log {
print-time yes;
file "/var/log/bind_security" versions 20 size 5m;};
category security { security_log; };
channel default {
print-time yes;
file "/var/log/named_log" versions 20 size 5m;};
category default { default; };
};
zone "." {
type hint;
file "/var/named/etc/named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
notify no;
file "127.0.0.rev.cmg";
};
zone "ve2cii.com" {
type forward;
forward only;
forwarders {
108.161.165.156;
};
};
I am using bind-9.16.5. I am having an issue with domain/zone
forwarding.
Global forwarding works fine. When I configure domain forwarding no request
for dns info goes out from the machine. I did a tcpdump to verify this.
For bind-9.13.2 the domain forwarding works properly.
Here is my config:
I am using the default settings for the dnssec config. I tried setting
them to off
and there is no change.
//dnssec-enable yes;
//dnssec-validation auto;
//dnssec-lookaside auto;
zone "ve2cii.com" {
type forward;
forward only;
forwarders {
108.161.165.156;
};
--
sysadm cronomagic.com
e-mail ve2...@canasoft.net
POWERED BY LINUX
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
issue with domain forwarding
Hi,
I am using bind-9.16.5. I am having an issue with domain/zone
forwarding.
Global forwarding works fine. When I configure domain forwarding no request
for dns info goes out from the machine. I did a tcpdump to verify this.
For bind-9.13.2 the domain forwarding works properly.
Here is my config:
I am using the default settings for the dnssec config. I tried setting
them to off
and there is no change.
//dnssec-enable yes;
//dnssec-validation auto;
//dnssec-lookaside auto;
zone "ve2cii.com" {
type forward;
forward only;
forwarders {
108.161.165.156;
};
--
sysadm cronomagic.com
e-mail ve2...@canasoft.net
POWERED BY LINUX
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
bind resolver zone delegation
: 512 ;; QUESTION SECTION: ;vpn.smiths.com.IN MX ;; AUTHORITY SECTION: smiths.com. 59 IN SOA resolve01.sslvpndemo.com. hostmaster.resolve01.sslvpndemo.com. 5 10800 3600 604800 60 ;; Query time: 180 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mi Mai 15 15:26:28 CEST 2019 ;; MSG SIZE rcvd: 111 Can i help you. Regards -- Frank ___ 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: conflicting subdomain delegation
That's an internal setting can't be exposed. I created a public test name: test.c.b.jilapps.com Should you see A record 1.2.3.4 or 5.6.7.8? On Thu, Nov 15, 2018 at 8:25 AM Barry Margolin wrote: > In article , > Frank Liu wrote: > > > Thanks for confirming bind behavior matches what I saw. > > I noticed other resolvers (eg: @8.8.8.8) works differently, c.b.a.com NS > > host2 actually got used, not ignored as occluded data. > > That shouldn't be possible. The occluded data should never be given out > by the authoritative server, so the resolver should never see it. > > Tell us the actual domains so we can see what's really happening. > > > Is this a bind specific implementation, not required by any RFCs? > > >From authoritative dns perspective, Amazon Route53 allows you to add > both > > delegations in the a.com zone without any "out of zone data" error. > > > > > > On Tue, Nov 13, 2018 at 1:50 PM Mark Andrews wrote: > > > > > > > > > On 14 Nov 2018, at 4:04 am, Frank Liu wrote: > > > > > > > > Hi, > > > > > > > > Is there a RFC determining which nameserver to use if there is a > > > conflicting subdomain delegation? > > > > > > > > eg: > > > > In the zone of a.com, there are two NS delegations > > > > > > This one is used. > > > > > > > b.a.com NS host1 > > > > > > This one is ignored as it is occluded data. > > > > > > > c.b.a.com NS host2 > > > > > > > > On host1 in zone b.a.com, there is > > > > c.b.a.com NS host3 > > > > > > Which is occluded data or glue depending upon the rest of the contents > of > > > the zone. > > > > > > > As you can see, there is a conflicting delegation for c.b.a.com. If > I > > > look a name d.c.b.a.com, will the nameserver host2 or host3 be used? > > > > dig +trace seems to go to host2, but bind9 as a resolver goes to > host3. > > > > (the test was done on a centos7). > > > > > > dig +trace follows the returned delegations. > > > > > > > Any ideas? > > > > Thanks! > > > > ___ > > > > 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 > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > > > > -- > Barry Margolin > Arlington, MA > ___ > 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 > ___ 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: conflicting subdomain delegation
Thanks for confirming bind behavior matches what I saw. I noticed other resolvers (eg: @8.8.8.8) works differently, c.b.a.com NS host2 actually got used, not ignored as occluded data. Is this a bind specific implementation, not required by any RFCs? >From authoritative dns perspective, Amazon Route53 allows you to add both delegations in the a.com zone without any "out of zone data" error. On Tue, Nov 13, 2018 at 1:50 PM Mark Andrews wrote: > > > On 14 Nov 2018, at 4:04 am, Frank Liu wrote: > > > > Hi, > > > > Is there a RFC determining which nameserver to use if there is a > conflicting subdomain delegation? > > > > eg: > > In the zone of a.com, there are two NS delegations > > This one is used. > > > b.a.com NS host1 > > This one is ignored as it is occluded data. > > > c.b.a.com NS host2 > > > > On host1 in zone b.a.com, there is > > c.b.a.com NS host3 > > Which is occluded data or glue depending upon the rest of the contents of > the zone. > > > As you can see, there is a conflicting delegation for c.b.a.com. If I > look a name d.c.b.a.com, will the nameserver host2 or host3 be used? > > dig +trace seems to go to host2, but bind9 as a resolver goes to host3. > > (the test was done on a centos7). > > dig +trace follows the returned delegations. > > > Any ideas? > > Thanks! > > ___ > > 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 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ 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: conflicting subdomain delegation
bind9 resolver a simple cache only with root hint. no local zones. On Tue, Nov 13, 2018 at 9:18 AM Lyle Giese wrote: > On 11/13/2018 11:04 AM, Frank Liu wrote: > > Hi, > > Is there a RFC determining which nameserver to use if there is a > conflicting subdomain delegation? > > eg: > In the zone of a.com, there are two NS delegations: > > b.a.com NS host1 > c.b.a.com NS host2 > > On host1 in zone b.a.com, there is > c.b.a.com NS host3 > > As you can see, there is a conflicting delegation for c.b.a.com. If I > look a name d.c.b.a.com, will the nameserver host2 or host3 be used? > dig +trace seems to go to host2, but bind9 as a resolver goes to host3. > (the test was done on a centos7). > > Any ideas? > Thanks! > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing > listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users > > I would expect that behavior if the Bind9 resolver was setup to query > host1. If bind9 queries a server that is authoritive for b.a.com, I > would expect that result. If the bind9 resolver is setup to query a > recursive only server(other than host1), I would expect the same behavior > as the +trace result. > > so I think the answer is dependant on how your bind9 resolver is > configured. > > Lyle Giese > ___ > 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 > ___ 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
conflicting subdomain delegation
Hi, Is there a RFC determining which nameserver to use if there is a conflicting subdomain delegation? eg: In the zone of a.com, there are two NS delegations: b.a.com NS host1 c.b.a.com NS host2 On host1 in zone b.a.com, there is c.b.a.com NS host3 As you can see, there is a conflicting delegation for c.b.a.com. If I look a name d.c.b.a.com, will the nameserver host2 or host3 be used? dig +trace seems to go to host2, but bind9 as a resolver goes to host3. (the test was done on a centos7). Any ideas? Thanks! ___ 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: expired SSL certificate
Cert looks fixed now. Nice to see you're using Letsencrypt certs... just have to fix the cron job for the renew ;-) Frank >Forwarded to our operations people >> On 11 Apr 2018, at 10:12 am, /dev/rob0 wrote: >> >> The certificate for lists.isc.org expired today, and because of STS >> my browser does not allow a security exception. ___ 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: adding zone forwards without restart
I'm adding forwarders, not adding an authoritative domain. I'm not working directly with a zone at all. Just intercepting DNS traffic for a specific zone intended to be internal only and forwarding it to another group of resolvers instead of dumping the queries to the Internet. On Wed, Sep 21, 2016 at 5:03 PM, Sten Carlsen wrote: > I assume you did increase the serial, if not this is what I would expect > to happen. > > On 21/09/16 10:53, Tony Finch wrote: > > Frank Even wrote: > > > Is there a way to add forwarders for specific zones without a restart? > Everything I've read seems to indicate an "rndc reconfig" or an "rndc > reload" should take care of this, but they do not. I add forwarders to > "named.conf" and neither will load the new forwarded zone until I do a full > daemon restart. > > I bet you are running chrooted, and you are editing named.conf outside the > chroot, and the restart script copies it into the chroot. > > You need to find a way to run the copy independently of restarting the > daemon. > > Maybe there is something like `systemctl reload named.service` which does > a graceful reload ... but, looking at the srpm I think you might have to > run `/usr/libexec/setup-named-chroot.sh /var/named/chroot on`. OBVIOUSLY. > > Tony. > > > -- > 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 > ___ 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: adding zone forwards without restart
None of that works. Nothing short of a restart of the daemon notices new forwarders added to the config. That is inclusive of: rndc reconfig rndc reload rndc flushname $nameofforwardersadded rndc flush A restart of the service however, that does work. That is far more disruptive than I like though (making adding a forwarder a bit more labor intensive at this point than I was hoping it would be). On Wed, Sep 21, 2016 at 8:30 AM, Tony Finch wrote: > Benny Pedersen wrote: > > > > why does reload not flush ? > > Often you want to reload zone files without throwing away the cache. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Bailey: Southeast 6 to gale 8, becoming cyclonic, mainly southwest, gale 8 > to > storm 10, backing south 5 to 7 later. Very rough or high, becoming rough. > Rain > then showers. Moderate or poor, occasionally good. > ___ > 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 > ___ 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: adding zone forwards without restart
I am running chrooted. I'm relying on the "feature" of BIND "mounting" the standard dirs into a chroot via the standard startup scripts in Cent6/7. My understanding is it's not "copying" the files anywhere, but using those that are there. I am modifying them via puppet on the system. I've even created a "service" to only do an "rndc reconfig" instead of refreshing the service to ensure I can do safe puppet runs. But yeah, no matter what I do, nothing short of a restart of the service (typically "service named restart" on EL6 and "service named-chroot restart" on EL7) works. On Wed, Sep 21, 2016 at 1:53 AM, Tony Finch wrote: > Frank Even wrote: > > > Is there a way to add forwarders for specific zones without a restart? > > Everything I've read seems to indicate an "rndc reconfig" or an "rndc > > reload" should take care of this, but they do not. I add forwarders to > > "named.conf" and neither will load the new forwarded zone until I do a > full > > daemon restart. > > I bet you are running chrooted, and you are editing named.conf outside the > chroot, and the restart script copies it into the chroot. > > You need to find a way to run the copy independently of restarting the > daemon. > > Maybe there is something like `systemctl reload named.service` which does > a graceful reload ... but, looking at the srpm I think you might have to > run `/usr/libexec/setup-named-chroot.sh /var/named/chroot on`. OBVIOUSLY. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Trafalgar: North or northwest 4 or 5. Moderate or rough. Fair. Good. > ___ 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: adding zone forwards without restart
The basics are fine. BIND just doesn't load newly added forwarded zones, period. It also kind of lies in the output: Sep 20 17:57:48 host01 named[26453]: reloading configuration succeeded Sep 20 17:57:48 host01 named[26453]: any newly configured zones are now loaded ...except they're not. Thus far I think the only condition I've actually seen BIND load new zones without a restart after being added to named.conf is if it's not already authoritative for a lower level part of a domain and you're adding an authoritative zone. Even adding another master zone that is higher up in the hierarchy will not load until a full restart I've found (meaning you have "domain.com" configured as a master zone and add "subdomain.domain.com" as a master zone as well). On Tue, Sep 20, 2016 at 5:56 PM, Benny Pedersen wrote: > On 2016-09-21 02:40, Frank Even wrote: > >> Is there a way to add forwarders for specific zones without a restart? >> Everything I've read seems to indicate an "rndc reconfig" or an "rndc >> reload" should take care of this, but they do not. I add forwarders >> to "named.conf" and neither will load the new forwarded zone until I >> do a full daemon restart. >> > > rndc reload > > after edit named.conf > > remember to named-checkconf first > > is your rndc key pair or acl setup ? > > what are logged ? > > rndc reload zone ? > > type rndc to see valid commands > ___ > 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 > ___ 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
adding zone forwards without restart
Is there a way to add forwarders for specific zones without a restart? Everything I've read seems to indicate an "rndc reconfig" or an "rndc reload" should take care of this, but they do not. I add forwarders to "named.conf" and neither will load the new forwarded zone until I do a full daemon restart. Stock named on Cent 7/6/5 if curious is what I'm working with. Testing currently on 7 (which appears to be 9.9.4). Thanks, Frank ___ 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: Load balancer for Bind
Hello Bert, This is the first I've heard of DNSDIST. I'll need to read more about it, but wanted to ask whether upon receiving the query, does DNSDIST act as a bridge for the complete request/response, or simply redirects the traffic with the response bypassing DNSDIST? THanks, Frank - Original Message - From: "bert hubert" To: "Job" Cc: bind-users@lists.isc.org Sent: Wednesday, 14 September, 2016 13:43:59 Subject: Re: Load balancer for Bind On Wed, Sep 14, 2016 at 06:17:13PM +0200, Job wrote: > which is the best load balancer for two or more Bind DNS Server, located in > the same farm? > I read something about HAProxy but it does not manage udp connection and the > interesting security proxy/balancer DnsDist does not pass original client ip > for Bind-DLZ... Hi Francesco, dnsdist can transfer the original IP over EDNS Client Subnet (ECS). http://dnsdist.org/README/ has how this works. I don't know if BIND can make use of the original IP address though. PowerDNS geoipbackend can in any case. BIND is also an excellent choice. Good luck! Bert (one of the dnsdist authors) ___ 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 ___ 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: Load balancer for Bind
Francesco, You may want to look at relayd from OpenBSD project. The last time I looked it was able to load-balance DNS. If you are looking for an appliance solution, the pfSense project (firewall) had ported relayd and gave it a GUI - though the DNS LB may not be in the GUI. Best is it is free. Regards, Frank - Original Message - From: "Job" To: bind-users@lists.isc.org Sent: Wednesday, 14 September, 2016 12:17:13 Subject: Load balancer for Bind Hello, which is the best load balancer for two or more Bind DNS Server, located in the same farm? I read something about HAProxy but it does not manage udp connection and the interesting security proxy/balancer DnsDist does not pass original client ip for Bind-DLZ... Thank you, regards! Francesco ___ 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 ___ 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: allow-query does not seem to be working
Thanks for the info. Also I'll have to note that I completely missed that the "offending IP" is one of the .uk root servers so the next logical conclusion is I've probably got a box in one of my environments driving an amplification attack of some sort or something at those IPs that I need to figure out. Sorry for the bother and thanks for the feedback. Much appreciated. On Mon, Aug 8, 2016 at 10:51 AM, Ray Bellis wrote: > On 08/08/2016 18:43, Darcy Kevin (FCA) wrote: > > As already noted, allow-query will cause you to send back a REFUSED > > response. That’s sort of the whole point of the REFUSED RCODE. > > > > > > > > If you want to not send back any response **whatsoever**, then take a > > look at the “blackhole” statement, but, honestly, this kind of “drop” > > function may, depending on network topology, be more efficiently > > performed in your firewall or IDS/IPS. > > > > > > > > Be aware that a client that doesn’t get a response may retry the query, > > so simply “dropping” queries may ultimately prove counter-productive. > > and also see Mark Andrew's Internet Draft on this very topic: > > https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-03 > > 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 > ___ 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: how to log client MAC address?
For a local subnet, enable BIND logging, then write a script that scans the BIND logs for client IP addresses and match those against your BIND server's ARP cache (arp -a). Run the script periodically to get your MAC addresses. Again only for clients on a local subnet. - Original Message - From: "Dennis Clarke" To: bind-users@lists.isc.org Sent: Saturday, 6 August, 2016 19:39:21 Subject: Re: how to log client MAC address? On 08/06/2016 10:01 PM, Frank Pikelner wrote: > MAC addresses are layer 2 and you only see those on your subnet, i.e. > most likely your default gateway, etc. > > So the answer is no. Unless he only cares about internal clients on a local subnet. dc ___ 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 ___ 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: how to log client MAC address?
MAC addresses are layer 2 and you only see those on your subnet, i.e. most likely your default gateway, etc. So the answer is no. Frank From: "Fima Leshinsky" To: bind-users@lists.isc.org Sent: Saturday, 6 August, 2016 17:42:59 Subject: how to log client MAC address? I'd like to log the client's MAC address. Is this possible? Could someone point me in the right direction? Thank you! Fima ___ 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 ___ 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
allow-query does not seem to be working
I have a group of servers serving out multiple addresses via anycast. I've
been made aware that an IP outside of our network is hitting the boxes with
queries, and we're returning data to the client.
With allow-query and allow-recursion locked to our subnets, this outside
host is still getting responses, and I'm trying to figure out why.
named.conf snippet:
allow-query { mynets; };
allow-recursion { mynets; };
Yet in response to a host not from one of the subnets allowed, we're
getting requests and returning some kind of response:
# tcpdump -i any -nvv src $myhost and dst 156.154.100.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size
65535 bytes
13:37:30.578020 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto
UDP (17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au]
A? www.sparknewspaper.co.uk. ar: . OPT UDPsize=4096 OK (53)
13:37:30.578025 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto
UDP (17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au]
A? www.sparknewspaper.co.uk. ar: . OPT UDPsize=4096 OK (53)
13:37:30.644502 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto
UDP (17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832
[1au] A? silverstonepaint.co.uk. ar: . OPT UDPsize=4096 OK (51)
13:37:30.644505 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto
UDP (17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832
[1au] A? silverstonepaint.co.uk. ar: . OPT UDPsize=4096 OK (51)
13:37:30.722628 IP (tos 0x0, ttl 64, id 5061, offset 0, flags [none], proto
UDP (17), length 68)
If an IP is not allowed as part of an "allow-query" statement, should the
name server still be returning any responses?
BIND version - BIND 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6
___
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: monitoring/graphing/tracking named queries
Thanks a lot. This is largely what I've been looking for/wondering
about. Thanks again!
Has anyone gotten much of anything going with graphite?
On Fri, Nov 13, 2015 at 3:50 PM, Warren Kumari wrote:
> See:
> DSC - http://dns.measurement-factory.com/tools/dsc/
> Hedgehog - https://github.com/dns-stats/hedgehog/wiki ("demo":
> http://stats.dns.icann.org/hedgehog/hedgehog.html )
>
> W
>
>
> On Fri, Nov 13, 2015 at 5:45 PM, Frank Even
> wrote:
>> What does everyone do for monitoring their DNS traffic, if anything?
>> I've come to a place where I need to have a good understanding of
>> general capacity. For example, how much traffic and types of traffic
>> individual servers are handling.
>>
>> I'd also like to get a breakdown of raw # of queries, then types of
>> queries, and in some cases, the top 20 "busiest hosts" and maybe what
>> they are hitting the servers with.
>>
>> dnstop I'm aware provides a lot of this functionality. But I'm
>> wondering if anyone out there is aggregating a lot of this data and
>> how they are going about doing it. Tutorials for this topic out on
>> the internets seem to be pretty sparse. If there is something out
>> there, I'd rather not reinvent the wheel.
>>
>> Thanks in advance for any assistance,
>> Frank
>> ___
>> 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
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
___
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
monitoring/graphing/tracking named queries
What does everyone do for monitoring their DNS traffic, if anything? I've come to a place where I need to have a good understanding of general capacity. For example, how much traffic and types of traffic individual servers are handling. I'd also like to get a breakdown of raw # of queries, then types of queries, and in some cases, the top 20 "busiest hosts" and maybe what they are hitting the servers with. dnstop I'm aware provides a lot of this functionality. But I'm wondering if anyone out there is aggregating a lot of this data and how they are going about doing it. Tutorials for this topic out on the internets seem to be pretty sparse. If there is something out there, I'd rather not reinvent the wheel. Thanks in advance for any assistance, Frank ___ 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: high CPU and 'top' shows named as the culprit
For the benefit of the archives, I want to share what I found while troubleshooting a high CPU issue on two of our servers running BIND. (We happen to be running Debian Wheezy with a Debian patched version of BIND 9.7.3) While looking through some graphs I noticed that the CPU of two of our servers was very high, and 'top' revealed that named was taking 60 to 70% of the CPU. Since we had enabled DNSsec earlier this week that was the item immediately under suspicion, but the graphs showed this high CPU issue started on June 30. Using my google-fu I found lots of hits on the "managed-keys-directory" issue (https://stackoverflow.com/questions/13059014/bind-named-service-high-cpu-lo ad), and while implementing those suggestion did resolve the warning I was seeing the logs, the CPU remained high. The next area focus was permissions, as I was getting this warning: Jul 24 16:08:41 mail2 named[3787]: logging channel 'default_log' file '/var/log/bind.log': permission denied but logging was working correctly, and fixing the permission for that file, and verifying it for the others, didn't reduce the CPU. (https://askubuntu.com/questions/469866/bind-fatal-error-cant-open-custom-lo g and https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1086775 and others). I got side-tracked with AppArmor for a while, but our Debian installation doesn't have that, so it's a moot point. Then I googled more specifically for 9.7.3 and high CPU, and came across a thread that mentioned NTP (https://lists.isc.org/pipermail/bind-users/2012-July/088166.html). Curious, it was June 30, the day of the leapsecond, let me check ... sure enough, the CPU jump exactly at 7 pm (I'm in U.S. Central). Restarting NTP (and then named) did not resolve the issue, but executing date -s "$(date -u)" immediately resolved the issue, without needing to restart named. More on this issue here: https://serverfault.com/questions/405003/named-9-7-3-takes-lots-of-cpu-on-ce ntos http://www.paranoids.at/high-cpu-load-due-to-leap-second/ http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix / Frank ___ 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: DNSSEC validation on 9.7.4 not working
Here you go: root@nagios:/etc/bind# dig @127.0.0.1 +dnssec +cd ds com; dig @127.0.0.1 +dnssec +cd dnskey . ; <<>> DiG 9.7.3 <<>> @127.0.0.1 +dnssec +cd ds com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38536 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;com. IN DS ;; ANSWER SECTION: com.86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com.86400 IN RRSIG DS 8 1 86400 2015070317 2015062316 48613 . ioJ6KyZ9ig0PsFBdo5jfM/9hLEX9qn06QaitkJubhcH3m/DPBi2o9xTu Cs9Aabwm/tSlGc+JVc3oBVSwv6LakHUY9v7aJn77pD244tnnlgNeR+z4 kkZSn1Kp5tHmhKx8sNYe8Fe9rTA/9hC+3IokE949ppf+3CEyjJ4uhJhm lN0= ;; Query time: 54 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 23 22:41:31 2015 ;; MSG SIZE rcvd: 239 ; <<>> DiG 9.7.3 <<>> @127.0.0.1 +dnssec +cd dnskey . ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11727 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 30703 IN DNSKEY 256 3 8 AwEAAZyIkCwEYeG29NV+4cOdKE4DPng/4BqJeoOhKqzJbl+LR33TPWsr wBRfmAi9wvR/Qc6IV4MFMXjmkclXns+atIQZ9uQV3YAvKv/cVuO7Mneu MssIQixaMw+jp73R7zIUNMbLBgJRQXI57Rl+pvXBAkgHndVwv+aJkf7y GEuE9Dtj . 30703 IN DNSKEY 256 3 8 AwEAAa67bQck1JjopOOFc+iMISFcp/osWrEst2wbKbuQSUWu77QC9UHL ipiHgWN7JlqVAEjKITZz49hhkLmOpmLK55pTq+RD2kwoyNWk9cvpc+tS nIxT7i93O+3oVeLYjMWrkDAz7K45rObbHDuSBwYZKrcSIUCZnCpNMUtn PFl/04cb . 30703 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= . 30703 IN RRSIG DNSKEY 8 0 172800 20150705235959 2015062000 19036 . W6ZIOh5tJ1ph3C0c9Fqot+55jCewbk/cWRquGOeRnWkag7rx/XgsEfvd HLr1HsSIlag+lt1OvTlsLgvVk/yUcOAZA/NvMRPbFfbyrEi82YpZ70Z2 B995qkT7dCf/3uBynAzubAPshUfEi7LuBy9bzyYPMvtRZptEnBz3xsAf 4gmrRTX0BW66ve2xqvitZrPVH2WaYR70iJbJWbKKDCPl9rwEcit95gyi CNQLOIPFq2XgHDmo01Pr4evPbSowny6kNXzuDHgKQn1+BWX5zhbr74OE 3FZXo2DUXm8BA5OhMY0bMg32kjzQLu+lxBWpaXabjFoALNFG4WRRdx1s 4+Wuhg== ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 23 22:41:31 2015 ;; MSG SIZE rcvd: 883 root@nagios:/etc/bind# date -u Wed Jun 24 03:41:52 UTC 2015 root@nagios:/etc/bind# Frank -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, June 23, 2015 10:31 PM To: Frank Bulk Cc: bind-us...@isc.org Subject: Re: DNSSEC validation on 9.7.4 not working Should have asked for +dnssec on those queries. Also "date -u". In message <005601d0ae2c$b698b6c0$23ca2440$@iname.com>, "Frank Bulk" writes: > Mark, > > Sorry for top-posting -- my email client makes it difficult to do otherwise. > > Yes, I'm absolutely sure there's no software or physical firewall (we're an > ISP), and there's also no load-balancer in front of this box. I've also > used the EDNS tests and I can get a 4000+ byte response. There's also no > forwarder configured. > > Here's the requested output: > > > root@nagios:/etc/bind# dig @127.0.0.1 +cd ds com; dig @127.0.0.1 +cd dnskey > . > > ; <<>> DiG 9.7.3 <<>> @127.0.0.1 +cd ds com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55498 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;com. IN DS > > ;; ANSWER SECTION: > com.86400 IN DS 30909 8 2 > E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 > > ;; Query time: 17 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Tue Jun 23 22:17:58 2015 > ;; MSG SIZE rcvd: 69 > > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.7.3 <<>> @127.0.0.1 +cd dnskey . > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25167 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > >
RE: DNSSEC validation on 9.7.4 not working
Mark,
Sorry for top-posting -- my email client makes it difficult to do otherwise.
Yes, I'm absolutely sure there's no software or physical firewall (we're an
ISP), and there's also no load-balancer in front of this box. I've also
used the EDNS tests and I can get a 4000+ byte response. There's also no
forwarder configured.
Here's the requested output:
root@nagios:/etc/bind# dig @127.0.0.1 +cd ds com; dig @127.0.0.1 +cd dnskey
.
; <<>> DiG 9.7.3 <<>> @127.0.0.1 +cd ds com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55498
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;com. IN DS
;; ANSWER SECTION:
com.86400 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 23 22:17:58 2015
;; MSG SIZE rcvd: 69
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.7.3 <<>> @127.0.0.1 +cd dnskey .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25167
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 32115 IN DNSKEY 256 3 8
AwEAAa67bQck1JjopOOFc+iMISFcp/osWrEst2wbKbuQSUWu77QC9UHL
ipiHgWN7JlqVAEjKITZz49hhkLmOpmLK55pTq+RD2kwoyNWk9cvpc+tS
nIxT7i93O+3oVeLYjMWrkDAz7K45rObbHDuSBwYZKrcSIUCZnCpNMUtn PFl/04cb
. 32115 IN DNSKEY 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
. 32115 IN DNSKEY 256 3 8
AwEAAZyIkCwEYeG29NV+4cOdKE4DPng/4BqJeoOhKqzJbl+LR33TPWsr
wBRfmAi9wvR/Qc6IV4MFMXjmkclXns+atIQZ9uQV3YAvKv/cVuO7Mneu
MssIQixaMw+jp73R7zIUNMbLBgJRQXI57Rl+pvXBAkgHndVwv+aJkf7y GEuE9Dtj
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 23 22:17:59 2015
;; MSG SIZE rcvd: 586
Frank
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Tuesday, June 23, 2015 10:11 PM
To: Frank Bulk
Cc: bind-us...@isc.org
Subject: Re: DNSSEC validation on 9.7.4 not working
In message <003d01d0ae24$682fc080$388f4180$@iname.com>, "Frank Bulk" writes:
> I'm running BIND 9.7.3 on Debian and having trouble configuring DNSSEC
> validation.
>
> I'm using the excellent guides at
>
http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#easy-start-guide-
> for-recursive-servers and
>
https://www.surf.nl/binaries/content/assets/surf/en/knowledgebase/2012/rappo
> rt_Deploying_DNSSEC_v20.pdf and http://dnssec.vs.uni-due.de/ which provide
> 9.7.x configuration instructions and so I'm feeling a bit slow that I
can't
> make this work.
>
> I'm have a copy of bind.keys from
> https://www.isc.org/downloads/bind/bind-keys/ in /etc/bind/
>
> This statement in /etc/bind/bind.conf:
>
> managed-keys {
> "." initial-key 257 3 8
> "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
> FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
> bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
> X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
> W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
> Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
> };
>
> and the following in /etc/bind/bind.conf.options:
>
> options {
>
>dnssec-enable yes;
>dnssec-validation yes;
>
> }
>
> But when I issue "rdnc reconifg" I immediately get repeated log lines
about
> the following and then similar statements for each domains:
>
> 23-Jun-2015 20:43:47.402 dnssec: info: validating @0x7fcec948ce40: com
DS:
> no valid signature found
> 23-Jun-2015 20:43:47.402 dnssec: info: validating @0x7fcec8c41bf0: com
DS:
> no valid signature found
> 23-Jun-2015 20:43:47.438 dnssec: info: validating @0x7fcec8c39b80: . NS:
no
> valid signature found
>
> 23-Jun-2015 20:43:48.750 dnssec: info: validating @0x7fced04fd9e0: . NS:
no
> valid signature found
> 23-Jun-2015 20:43:48.754 dnssec: info: validating @0x7fcee55996a0:
> a1075.dscg.akamai.net : bad cache hit (net/DS)
> 23-Jun-2015 20:43:48.757 dnssec: info: validating @0x7fceca621970:
> wwwp.wip.rackspace.com : bad cache hi
DNSSEC validation on 9.7.4 not working
I'm running BIND 9.7.3 on Debian and having trouble configuring DNSSEC
validation.
I'm using the excellent guides at
http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#easy-start-guide-
for-recursive-servers and
https://www.surf.nl/binaries/content/assets/surf/en/knowledgebase/2012/rappo
rt_Deploying_DNSSEC_v20.pdf and http://dnssec.vs.uni-due.de/ which provide
9.7.x configuration instructions and so I'm feeling a bit slow that I can't
make this work.
I'm have a copy of bind.keys from
https://www.isc.org/downloads/bind/bind-keys/ in /etc/bind/
This statement in /etc/bind/bind.conf:
managed-keys {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};
and the following in /etc/bind/bind.conf.options:
options {
dnssec-enable yes;
dnssec-validation yes;
}
But when I issue "rdnc reconifg" I immediately get repeated log lines about
the following and then similar statements for each domains:
23-Jun-2015 20:43:47.402 dnssec: info: validating @0x7fcec948ce40: com DS:
no valid signature found
23-Jun-2015 20:43:47.402 dnssec: info: validating @0x7fcec8c41bf0: com DS:
no valid signature found
23-Jun-2015 20:43:47.438 dnssec: info: validating @0x7fcec8c39b80: . NS: no
valid signature found
23-Jun-2015 20:43:48.750 dnssec: info: validating @0x7fced04fd9e0: . NS: no
valid signature found
23-Jun-2015 20:43:48.754 dnssec: info: validating @0x7fcee55996a0:
a1075.dscg.akamai.net : bad cache hit (net/DS)
23-Jun-2015 20:43:48.757 dnssec: info: validating @0x7fceca621970:
wwwp.wip.rackspace.com : bad cache hit (com/DS)
23-Jun-2015 20:43:48.759 dnssec: info: validating @0x7fceca621970:
a1526.dscg.akamai.net : bad cache hit (net/DS)
23-Jun-2015 20:43:48.759 dnssec: info: validating @0x7fced04fd9e0:
a1784.dscg.akamai.net : bad cache hit (net/DS)
23-Jun-2015 20:43:48.761 dnssec: info: validating @0x7fced04fd9e0:
e1181.dscb.akamaiedge.net : bad cache hit (net/DS)
Of course, once the TLDs aren't considered valid everything goes south.
What am I doing wrong?
Regards,
Frank Bulk
___
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: rndc flushname not working
On Mon, Apr 13, 2015 at 11:10 AM, Evan Hunt wrote: > On Mon, Apr 13, 2015 at 11:05:05AM -0700, Frank Even wrote: >> ...and where could I find info on what is stored in ADB and any other >> particular items that flushname might not deal with? That's where my >> frustration largely is, that I can't find clear documentation on this >> point. > > I believe "rndc dumpdb -all" will give you that. > > Note, "rndc flushname" always took care of the ADB and the bad cache for a > given name. "rndc flushtree" is the one that used to be a problem -- it > would recursively clear all the names below the specified one from the > DNS cache, but it wasn't touching the ADB or the bad cache. Ah...it does appear I was confusing flushtree and flushname in the most specific doc I could find - https://kb.isc.org/article/AA-01002/0/How-do-I-flush-or-delete-incorrect-records-from-my-recursive-server-cache.html I have to apologize for that. I'd still definitely be curious to know what info is stored in the ADB though since according to the docs ADB was never intended to be flushed with a "flushtree" (although that has now apparently been addressed in a new version as stated earlier in the thread). Thanks. ___ 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: rndc flushname not working
On Sat, Apr 11, 2015 at 6:49 AM, Tony Finch wrote: > There was a bug in 9.9 and earlier that rndc flushtree only flushed the main > cache, not adb or bad cache. This was fixed in 9.10 - see item 3606 in the > CHANGES file. ...and where could I find info on what is stored in ADB and any other particular items that flushname might not deal with? That's where my frustration largely is, that I can't find clear documentation on this point. ___ 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: rndc flushname not working
On Thu, Apr 9, 2015 at 1:48 PM, Matus UHLAR - fantomas wrote: > On 09.04.15 13:25, Frank Even wrote: >> >> Is there any place I can look to get a definitive answer in what cases >> "flushname" will and will not work? > > > it will work if you have old entries in the cache. > that will NOT help you if any of the servers that are supposed to be > authoritative for a domain will return invalid answers for the domain. > >> I've been digging around in lists >> and docs and can't seem to find any definitive answers. I've been >> having odd troubles clearing a name from a cache and after even >> clearing the name and the name that the name servers was attached to, >> still had to flush the entire cache to get resolution working properly >> on that domain again. > > > this indicates that any of NS records the domain points to returns NXDOMAIN > for the domain. > > hard to tell without more info, but some web DNS checkers are able to trace > this kind of issues... > -- So flushname does not address NXDOMAIN responses? That's the point I'm getting at, there is no good documentation on this that I can find. All the responses in the lists seem to be around "well it depends on your situation, need more data, etc." I'd like to just be able to find documentation on the specific behaviors of these options so I can understand properly what they do to maintain my environment properly without properly understanding what command will do or not do for me. The closest I have found is this - https://kb.isc.org/article/AA-01002/0/How-do-I-flush-or-delete-incorrect-records-from-my-recursive-server-cache.html - but it does not tgo on to tell what is or is not stored in the ADB (or give a link to figure that out) to properly understand what I can and cannot get dumped from cache by executing an "rndc flushname" command. I no longer have the data regardless, a full flush "fixed" the issue. We have some automation around running a "flushname" on the servers though and that addresses a large number of issues with cache weirdness, so when I got pulled in for something where it wasn't working I was curious as to why. It seems this is a recurring question on the lists, but I can't find where there are any definitive answers anywhere. If there is something that I'm missing I would be highly appreciative of being pointed towards that information. Thanks, Frank ___ 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: rndc flushname not working
Is there any place I can look to get a definitive answer in what cases "flushname" will and will not work? I've been digging around in lists and docs and can't seem to find any definitive answers. I've been having odd troubles clearing a name from a cache and after even clearing the name and the name that the name servers was attached to, still had to flush the entire cache to get resolution working properly on that domain again. Thanks, Frank On Tue, Dec 9, 2014 at 8:31 PM, Mark Andrews wrote: > > Nameservers being down does not result in NXDOMAIN responses. I > suspect that some of the auth servers were producing NXDOMAIN > incorrectly. Flushing the name won't help in those cases. > > In message <001001d01429$1c857f70$55907e50$@iname.com>, "Frank Bulk" writes: >> Our ISP operations are running a mixture of 9.7.3 and 9.8.4 on several >> Debian servers and we've noticed that rndc flushname doesn't work many >> times. >> >> This weekend we had a local institution whose own authoritative DNS servers >> [all of them] were offline for 48+ hours and so there were several >> negatively cached entries in our resolvers' caches from customers who were >> querying for their institutions website and MX record. After the >> institution restored connectivity to their DNS servers this afternoon I >> checked all our resolvers and a few returned NXDOMAIN for the www and MX >> record. Issuing rndc flushname and rndc flushname >> didn't clear out the NXDOMAIN. I had to use "rndc flush" to resolve the >> issue. >> >> Is this expected behavior? The next time I see what, what troubleshoot >> steps should I take diagnose the issue? Dump the DB? >> >> Frank >> >> ___ >> 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 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > 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 ___ 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 not loading into memory on first transfer
On Fri, Mar 27, 2015 at 8:25 AM, Barry Margolin wrote: > In article , > /dev/rob0 wrote: > >> On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote: >> > In this particular instance, the masters ended up under maintenance >> > shortly after these boxes rebooted, so they were unable to transfer >> > the zone from them for another 2 hours. These boxes were serving >> > stale data after boot despite being able to accomplish one zone >> > transfer after boot. It seems that failing the first zone transfer >> > did NOT load the zone into memory (but subsequent zone transfers >> > while still failing to write the tmp file DID load the zone into >> > memory). >> > >> > I guess the question really is, is this expected behavior or a bug? >> >> The bug is a misconfiguration bug, where contrary to documented >> requirements, you have not given named write privilege in its >> directory. >> >> I think you're saying named should fail to load the stale zones, >> which at startup it cannot know are stale. That does not sound >> correct to me. >> >> Perhaps you're suggesting that named should SERVFAIL the zone when >> the first zone transfer has happened, and while this sounds more >> reasonable, I am not sure that the zone transfer actually does take >> place if named is unable to open a temporary file to write. (What >> would be the point in talking to the master when you know you are >> unable to handle the data?) > > He's not suggesting either of these. He's saying that when it > successfully transferred the zone, it should update the in-memory > version, and serve that, even though it wasn't able to save it to disk. > That's what it does on the SECOND transfer, it just doesn't do it on the > FIRST transfer. ^^^ THIS! Exactly! I REALIZE I had a configuration problem that prevented writing the zone file locally that snuck in as it turns out on the bind-chroot package update. That's irrelevant to the issue I noticed after that. It DOES load up in memory and serve it up generally. It's just that what I've seen in this particular instance is that it failed to do this on the first successful zone transfer, then loaded it up in memory on the 2nd try (which sadly in this instance, was 2 hours later due to other issues, which of course caused it to be noticed in this instance where it might not have been in previous instances). Thanks. ___ 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 not loading into memory on first transfer
On Thu, Mar 26, 2015 at 1:00 PM, Matus UHLAR - fantomas wrote: >> On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas >> wrote: >>> >>> What's the SOA? It's possible that the zones were not expired, so they >>> were >>> provided as saved on disk. Since BIND wasn't able to transfer newer >>> versions, it continued providing old versions. > > > On 26.03.15 12:48, Frank Even wrote: >> >> Yes, the old versions were provided on disk on initial load. But that >> was then followed up with a SUCCESSFUL zone transfer minutes later, >> but the server was unable to save the tmp file in the working >> directory and served stale content until about 2 hours later when the >> server was able to get another successful zone transfer from the >> master and then loaded the new zone in memory (despite being unable to >> write the tmp file to update the local copy of the zone). > > > what didthe logs say? > Looks like the first transfer wasn't really successful (or the zone was > rejected) Logs indicated successful transfer, permission denied writing the tmp-x file that happens prior to writing it out to the zone file itself. ___ 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 not loading into memory on first transfer
On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas wrote: > On 26.03.15 11:34, Frank Even wrote: >> >> Zone files were in place for the necessary domains, but were outdated >> (assuming one of our updates broke something somewhere, they were all >> on average 3 months old). > > >> Here is where the issue is. I've generally found if BIND fails to >> write the zone, it generally loads it into memory (masking the fact >> that there is an issue here for an extended period of time). In this >> particular instance, the masters ended up under maintenance shortly >> after these boxes rebooted, so they were unable to transfer the zone >> from them for another 2 hours. These boxes were serving stale data >> after boot despite being able to accomplish one zone transfer after >> boot. It seems that failing the first zone transfer did NOT load the >> zone into memory (but subsequent zone transfers while still failing to >> write the tmp file DID load the zone into memory). >> >> I guess the question really is, is this expected behavior or a bug? > > > What's the SOA? It's possible that the zones were not expired, so they were > provided as saved on disk. Since BIND wasn't able to transfer newer > versions, it continued providing old versions. > Yes, the old versions were provided on disk on initial load. But that was then followed up with a SUCCESSFUL zone transfer minutes later, but the server was unable to save the tmp file in the working directory and served stale content until about 2 hours later when the server was able to get another successful zone transfer from the master and then loaded the new zone in memory (despite being unable to write the tmp file to update the local copy of the zone). ___ 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
BIND not loading into memory on first transfer
The subject is about the only way I can think to describe a situation we've run into recently. First here is the system: [root@dns]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@dns]# rpm -q bind bind-9.8.2-0.30.rc1.el6_6.2.x86_64 So, we got bit by a chroot permissions issue (unsure exactly how it got introduced), where the chroot was owned by root, but had named as the group owner. Perms were 750 on the dir (rwxr-x---) Zone files were in place for the necessary domains, but were outdated (assuming one of our updates broke something somewhere, they were all on average 3 months old). We updated some of the boxes, and on restart, named started. It initially started loading the 3 month old zone (one frequently updated I might add). The boxes then did a zone transfer from the master. Failing to be able to write the tmp file to the working directory, it moved on. Here is where the issue is. I've generally found if BIND fails to write the zone, it generally loads it into memory (masking the fact that there is an issue here for an extended period of time). In this particular instance, the masters ended up under maintenance shortly after these boxes rebooted, so they were unable to transfer the zone from them for another 2 hours. These boxes were serving stale data after boot despite being able to accomplish one zone transfer after boot. It seems that failing the first zone transfer did NOT load the zone into memory (but subsequent zone transfers while still failing to write the tmp file DID load the zone into memory). I guess the question really is, is this expected behavior or a bug? Thanks, Frank ___ 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: Finding authoritative server and last update
There are free ones: http://www.frankb.us/dns/ http://networking.ringofsaturn.com/Unix/freednsservers.php Regards, Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Moskowitz Sent: Tuesday, February 03, 2015 4:43 PM To: Jeremy C. Reed Cc: bind-users@lists.isc.org Subject: Re: Finding authoritative server and last update On 02/03/2015 05:09 PM, Jeremy C. Reed wrote: > On Tue, 3 Feb 2015, Robert Moskowitz wrote: > >> I am trying to find out which comcast server is authoritative for >> >> 4.254.253.50.in-addr.arpa >> >> and when the zone file for the ptr rr was last updated. >> >> I was told a week ago that the ptr would be updated, but I am still >> not seeing any change... >> >> I am not really good at keeping good notes on using dig. > Have a look at output from: > > dig +trace 4.254.253.50.in-addr.arpa PTR > > dig 254.253.50.in-addr.arpa SOA Thanks this shows that the supposed update over the weekend probably did not occur and that is why I am still seeing the default ptr RR. I was assured 24 hour turn around time one month ago. I suppose if you buy their domain hosting, it 'just works'. I suspect I will not want them to be the secondary NS for my domain, so I am again looking for secondary DNS service that I can afford... ___ 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 ___ 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: Finding authoritative server and last update
Rob, I like to use DNSstuff because it can check each path: http://www.dnsstuff.com/tools#dnsTraversal|type=domain&&value=4.254.253.50.i n-addr.arpa&&recordType=PTR Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Moskowitz Sent: Tuesday, February 03, 2015 4:01 PM To: bind-users@lists.isc.org Subject: Finding authoritative server and last update I am trying to find out which comcast server is authoritative for 4.254.253.50.in-addr.arpa and when the zone file for the ptr rr was last updated. I was told a week ago that the ptr would be updated, but I am still not seeing any change... I am not really good at keeping good notes on using dig. thanks for help ___ 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 ___ 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: Is there any reverse proxy software for dns or udp?
Have a look at relayd from OpenBSD, the last time I checked it had the capability you are looking for. Another option might be pfSense, as I recall they ported relayd and include the functionality in their firewall. Frank Pikelner - Original Message - From: "WXR" <474745...@qq.com> To: "bind邮件组" Sent: Thursday, January 29, 2015 9:07:20 PM Subject: Is there any reverse proxy software for dns or udp? Is there any reverse proxy software for dns , which can do load balance、cache for dns service, just like squid for http service? ___ 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 ___ 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: Unable to get AAAA for www.revk.uk from some of our servers
Phil, I'm embarrassed that I didn't check that file earlier. Yes, those four DNS resolvers sitting behind the load-balancer use 96.31.0.20: mail1:~# dig -t txt o-o.myaddr.l.google.com +short "96.31.0.20" mail1:~# It's been many moons since that backlist has been brought up, and when I opened a "ticket" with Google regarding the issue their own staff didn't say anything about that blacklist. And when those four resolvers did get the I assumed the issue was resolved. But I just checked now and they're not resolving again. I will revisit that "ticket". At a minimum, I wish one could request de-listing from Google's blacklist. Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Phil Mayers Sent: Monday, January 05, 2015 5:52 AM To: bind-users@lists.isc.org Subject: Re: Unable to get for www.revk.uk from some of our servers On 24/12/14 17:08, Frank Bulk wrote: > Except queries from 96.31.0.5 and 199.120.69.24 reliably return the > while queries from 96.31.0.20 do not. And we're all the same ISP, and in > the one case, from the same /24. I don't think Google is that granular. And > we do have good IPv6 connectivity. Yes, Google are that granular. See: http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_.txt ...which currently lists: 96.31.0.20/32# AS53347 United States 96.31.0.31/32# AS53347 United States Google have been, AFAICT, silent on the specifics of how they generate their blacklisting. Presumably it's the fairly standard approach of correlating a web-bug to a unique hostname embedded in the google search page, received http requests, and received DNS queries. Google undoubtedly then do some stats magic - that is their thing, after all - and down-score resolvers which make the query but whose clients don't finish the HTTP request, above some threshold. We had persistent problems in the past with our resolvers appearing in the Google blacklist, despite having excellent IPv6 connectivity. Google were unwilling to provide us any details that would have allowed us to identify the cause(s). We eventually stopped paying any attention to it, and the problem went away by itself. Possibly there are one or more clients with broken IPv6 using your resolvers, but without Google specifying the criteria which gets a resolver blacklisted, it's hard to know. Frankly, I wish Google would ditch the blacklist. It is hiding problems that responsible operators would like to see and fix, just so that Google don't lose eyeballs (and ad revenue) :o/ ___ 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 ___ 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: Unable to get AAAA for www.revk.uk from some of our servers
Except queries from 96.31.0.5 and 199.120.69.24 reliably return the while queries from 96.31.0.20 do not. And we're all the same ISP, and in the one case, from the same /24. I don't think Google is that granular. And we do have good IPv6 connectivity. Regards, Frank Bulk -Original Message- From: Stuart Henderson [mailto:s...@spacehopper.org] Sent: Wednesday, December 24, 2014 11:05 AM To: Frank Bulk Cc: 'Mark Andrews'; bind-us...@isc.org Subject: Re: Unable to get for www.revk.uk from some of our servers On 2014/12/23 21:33, Frank Bulk wrote: > So the question seems to come down to: "why does Google's name server not > return the when I query it from some IPs?" Didn't google have some kind of ISP whitelisting for handing out s? Ah yes... https://developers.google.com/speed/public-dns/faq mentions it: "Note that you may not receive IPv6 results for Google properties. To optimize the user experience, Google only serves records to clients behind ISPs with good IPv6 connectivity." ___ 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: Unable to get AAAA for www.revk.uk from some of our servers
So the question seems to come down to: "why does Google's name server not return the when I query it from some IPs?" == dig +norecurse ghs.l.google.com @ns1.google.com ; <<>> DiG 9.7.3 <<>> +norecurse ghs.l.google.com @ns1.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55349 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ghs.l.google.com. IN ;; AUTHORITY SECTION: l.google.com. 600 IN SOA ns1.google.com. dns-admin.google.com. 1577101 900 900 1800 60 ;; Query time: 30 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Tue Dec 23 21:29:53 2014 ;; MSG SIZE rcvd: 84 == Frank -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, December 23, 2014 6:38 PM To: Frank Bulk Cc: bind-us...@isc.org Subject: Re: Unable to get for www.revk.uk from some of our servers In message <001e01d01f0e$980b6070$c8222150$@iname.com>, "Frank Bulk" writes: > Thanks, Mark. > > When I queried for the of ghs.l.google.com from ns[1-4].google.com the > Google servers reported they don't do recursive queries. Why would you expect them to offer recursion? They don't need to for the role they are performing. > Which Google namserver does in fact carry the authoritative records > for ghs.l.google.com? l.google.com. 86400 IN NS ns3.google.com. l.google.com. 86400 IN NS ns1.google.com. l.google.com. 86400 IN NS ns4.google.com. l.google.com. 86400 IN NS ns2.google.com. > On a side note, I thought that Google's DNS servers were dual-stacked, but > that does not seem to be the case. None of the ns[1-4].google.com servers > return an for me. When I query the IPv6 interface of our recursive DNS > servers using "dig ghs.l.google.com +trace @[IPv6_address]" they all > return "connection timed out; no servers could be reached. Here's an > example: Google hasn't yet made their DNS servers dual stacked though lots of their other servers are dual stacked. It would be nice of them to do so as it is forcing clients behind IPv6 only connections to use transition mechanisms to get to the legacy IPv4 only servers. > > DNS server: 2607:fe28:0:1000::8 > > ; <<>> DiG 9.7.3 <<>> -6 ghs.l.google.com +trace @2607:fe28:0:1000::8 > ;; global options: +cmd > . 420917 IN NS c.root-servers.net. > . 420917 IN NS k.root-servers.net. > . 420917 IN NS f.root-servers.net. > . 420917 IN NS b.root-servers.net. > . 420917 IN NS g.root-servers.net. > . 420917 IN NS a.root-servers.net. > . 420917 IN NS d.root-servers.net. > . 420917 IN NS j.root-servers.net. > . 420917 IN NS i.root-servers.net. > . 420917 IN NS h.root-servers.net. > . 420917 IN NS l.root-servers.net. > . 420917 IN NS e.root-servers.net. > . 420917 IN NS m.root-servers.net. > ;; Received 496 bytes from 2607:fe28:0:1000::8#53(2607:fe28:0:1000::8) in 0 > ms > > com.172800 IN NS e.gtld-servers.net. > com.172800 IN NS f.gtld-servers.net. > com.172800 IN NS k.gtld-servers.net. > com.172800 IN NS a.gtld-servers.net. > com.172800 IN NS l.gtld-servers.net. > com.172800 IN NS i.gtld-servers.net. > com.172800 IN NS g.gtld-servers.net. > com.172800 IN NS b.gtld-servers.net. > com.172800 IN NS h.gtld-servers.net. > com.172800 IN NS d.gtld-servers.net. > com.172800 IN NS c.gtld-servers.net. > com.172800 IN NS j.gtld-servers.net. > com.172800 IN NS m.gtld-servers.net. > ;; Received 506 bytes from 2001:7fe::53#53(i.root-servers.net) in 113 ms > > google.com. 172800 IN NS ns2.google.com. > google.com. 172800 IN NS ns1.goog
RE: Unable to get AAAA for www.revk.uk from some of our servers
Thanks, Mark. When I queried for the of ghs.l.google.com from ns[1-4].google.com the Google servers reported they don't do recursive queries. Which Google namserver does in fact carry the authoritative records for ghs.l.google.com? On a side note, I thought that Google's DNS servers were dual-stacked, but that does not seem to be the case. None of the ns[1-4].google.com servers return an for me. When I query the IPv6 interface of our recursive DNS servers using "dig ghs.l.google.com +trace @[IPv6_address]" they all return "connection timed out; no servers could be reached. Here's an example: DNS server: 2607:fe28:0:1000::8 ; <<>> DiG 9.7.3 <<>> -6 ghs.l.google.com +trace @2607:fe28:0:1000::8 ;; global options: +cmd . 420917 IN NS c.root-servers.net. . 420917 IN NS k.root-servers.net. . 420917 IN NS f.root-servers.net. . 420917 IN NS b.root-servers.net. . 420917 IN NS g.root-servers.net. . 420917 IN NS a.root-servers.net. . 420917 IN NS d.root-servers.net. . 420917 IN NS j.root-servers.net. . 420917 IN NS i.root-servers.net. . 420917 IN NS h.root-servers.net. . 420917 IN NS l.root-servers.net. . 420917 IN NS e.root-servers.net. . 420917 IN NS m.root-servers.net. ;; Received 496 bytes from 2607:fe28:0:1000::8#53(2607:fe28:0:1000::8) in 0 ms com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. ;; Received 506 bytes from 2001:7fe::53#53(i.root-servers.net) in 113 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 170 bytes from 2001:503:a83e::2:30#53(a.gtld-servers.net) in 150 ms ;; connection timed out; no servers could be reached -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, December 23, 2014 6:01 PM To: Frank Bulk Cc: bind-us...@isc.org Subject: Re: Unable to get for www.revk.uk from some of our servers In message <001301d01f06$aa1c7180$fe555480$@iname.com>, "Frank Bulk" writes: > I dumped the database of one failing server and found this entry: > > ; authauthority > ghs.l.google.com. 331 \- ;-$NXRRSET > ; l.google.com. SOA ns4.google.com. dns-admin.google.com. 1577084 900 900 > 1800 60 > ; authanswer > 289 A 74.125.201.121 > ; > > What does the "\- ;-$NXRRSET" mean? It means that there is a negative cache entry for lookup. The SOA record that will be returned is in the comment. For responses from signed zones you will also see NSEC / NSEC3 records in the comments as well as RRSIG. NXRRSET (No Such RRset). NXDOMAIN (No Such Domain). > Working server shows this in the dump: > ; authanswer > ghs.l.google.com. 287 2607:f8b0:4001:c08::79 > ; > > Regards, > > Frank Bulk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Unable to get AAAA for www.revk.uk from some of our servers
I dumped the database of one failing server and found this entry: ; authauthority ghs.l.google.com. 331 \- ;-$NXRRSET ; l.google.com. SOA ns4.google.com. dns-admin.google.com. 1577084 900 900 1800 60 ; authanswer 289 A 74.125.201.121 ; What does the "\- ;-$NXRRSET" mean? Working server shows this in the dump: ; authanswer ghs.l.google.com. 287 2607:f8b0:4001:c08::79 ; Regards, Frank Bulk -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, December 23, 2014 2:53 PM To: Frank Bulk Cc: bind-us...@isc.org Subject: Re: Unable to get for www.revk.uk from some of our servers I would suspect that the instance of the google servers you are talking to has a bad copy of l.google.com. The serial in the soa records is 1577052. I currently see 1577063. There is also a possibilty that you are getting spoofed answers by as the zone is not signed there is no way to know. Mark In message <000201d01ec7$47f99ad0$d7ecd070$@iname.com>, "Frank Bulk" writes: > >From time to time there are certain domains that don't properly resolve on > our corporate Windows DNS servers, but flushing the Windows DNS server cache > resolves that. But yesterday I ran into an issue with resolving the > for www.revk.uk on just some our ISP DNS servers and I have time to dig into > it. > > They're mostly running BIND 9.7.3 (Debian-patched) or 9.8.4 (Debian > patched), some of them behind a load-balancer. In each case if the DNS > server can't resolve the for www.revk.uk it's also because it can't > resolve the for ghs.l.google.com, which is the last CNAME in the chain > for www.revk.uk. > > How do I go about tracking this down? (Sorry, most of the servers have ACLs > that prevent the public from resolving them, so you won't be able to test > remotely.) > > Regards, > > Frank > > > I have a script that checks against the IPv4 and IPv6 of each DNS server > (identical), both the IPs that are behind the load-balancer and in front. > > root@nagios:/tmp# dig-all www.revk.uk > > DNS server: 10.20.0.10 (server1 behind load-balancer) > > ; <<>> DiG 9.7.3 <<>> www.revk.uk @10.20.0.10 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46710 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.revk.uk. IN > > ;; ANSWER SECTION: > www.revk.uk.3600IN CNAME ghs.google.com. > ghs.google.com. 21000 IN CNAME ghs.l.google.com. > > ;; AUTHORITY SECTION: > l.google.com. 469 IN SOA ns4.google.com. > dns-admin.google.com. 1577052 900 900 1800 60 > > ;; Query time: 108 msec > ;; SERVER: 10.20.0.10#53(10.20.0.10) > ;; WHEN: Tue Dec 23 09:04:25 2014 > ;; MSG SIZE rcvd: 127 > > > DNS server: 2607:fe28:0:4000::10 (server1 behind load-balancer) > > ; <<>> DiG 9.7.3 <<>> -6 www.revk.uk @2607:fe28:0:4000::10 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43711 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.revk.uk. IN > > ;; ANSWER SECTION: > www.revk.uk.3600IN CNAME ghs.google.com. > ghs.google.com. 21000 IN CNAME ghs.l.google.com. > > ;; AUTHORITY SECTION: > l.google.com. 469 IN SOA ns4.google.com. > dns-admin.google.com. 1577052 900 900 1800 60 > > ;; Query time: 0 msec > ;; SERVER: 2607:fe28:0:4000::10#53(2607:fe28:0:4000::10) > ;; WHEN: Tue Dec 23 09:04:25 2014 > ;; MSG SIZE rcvd: 127 > > > DNS server: 10.20.0.20 (server2 behind load-balancer) > > ; <<>> DiG 9.7.3 <<>> www.revk.uk @10.20.0.20 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37596 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.revk.uk. IN > > ;; ANSWER SECTION: > www.revk.uk.3600IN CNAME ghs.google.com. > ghs.google.com. 21042 IN CNAME ghs.l.google.com. > > ;; AUTHORITY SECTION: > l.google.com. 437 IN SOA ns3.google.com. > dns-admin.google.com. 1577052 900 900 1800 60 > >
Unable to get AAAA for www.revk.uk from some of our servers
>From time to time there are certain domains that don't properly resolve on our corporate Windows DNS servers, but flushing the Windows DNS server cache resolves that. But yesterday I ran into an issue with resolving the for www.revk.uk on just some our ISP DNS servers and I have time to dig into it. They're mostly running BIND 9.7.3 (Debian-patched) or 9.8.4 (Debian patched), some of them behind a load-balancer. In each case if the DNS server can't resolve the for www.revk.uk it's also because it can't resolve the for ghs.l.google.com, which is the last CNAME in the chain for www.revk.uk. How do I go about tracking this down? (Sorry, most of the servers have ACLs that prevent the public from resolving them, so you won't be able to test remotely.) Regards, Frank I have a script that checks against the IPv4 and IPv6 of each DNS server (identical), both the IPs that are behind the load-balancer and in front. root@nagios:/tmp# dig-all www.revk.uk DNS server: 10.20.0.10 (server1 behind load-balancer) ; <<>> DiG 9.7.3 <<>> www.revk.uk @10.20.0.10 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46710 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.revk.uk. IN ;; ANSWER SECTION: www.revk.uk.3600IN CNAME ghs.google.com. ghs.google.com. 21000 IN CNAME ghs.l.google.com. ;; AUTHORITY SECTION: l.google.com. 469 IN SOA ns4.google.com. dns-admin.google.com. 1577052 900 900 1800 60 ;; Query time: 108 msec ;; SERVER: 10.20.0.10#53(10.20.0.10) ;; WHEN: Tue Dec 23 09:04:25 2014 ;; MSG SIZE rcvd: 127 DNS server: 2607:fe28:0:4000::10 (server1 behind load-balancer) ; <<>> DiG 9.7.3 <<>> -6 www.revk.uk @2607:fe28:0:4000::10 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43711 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.revk.uk. IN ;; ANSWER SECTION: www.revk.uk.3600IN CNAME ghs.google.com. ghs.google.com. 21000 IN CNAME ghs.l.google.com. ;; AUTHORITY SECTION: l.google.com. 469 IN SOA ns4.google.com. dns-admin.google.com. 1577052 900 900 1800 60 ;; Query time: 0 msec ;; SERVER: 2607:fe28:0:4000::10#53(2607:fe28:0:4000::10) ;; WHEN: Tue Dec 23 09:04:25 2014 ;; MSG SIZE rcvd: 127 DNS server: 10.20.0.20 (server2 behind load-balancer) ; <<>> DiG 9.7.3 <<>> www.revk.uk @10.20.0.20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37596 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.revk.uk. IN ;; ANSWER SECTION: www.revk.uk.3600IN CNAME ghs.google.com. ghs.google.com. 21042 IN CNAME ghs.l.google.com. ;; AUTHORITY SECTION: l.google.com. 437 IN SOA ns3.google.com. dns-admin.google.com. 1577052 900 900 1800 60 ;; Query time: 109 msec ;; SERVER: 10.20.0.20#53(10.20.0.20) ;; WHEN: Tue Dec 23 09:04:25 2014 ;; MSG SIZE rcvd: 127 DNS server: 2607:fe28:0:4000::20 (server2 behind load-balancer) ; <<>> DiG 9.7.3 <<>> -6 www.revk.uk @2607:fe28:0:4000::20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20244 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.revk.uk. IN ;; ANSWER SECTION: www.revk.uk.3600IN CNAME ghs.google.com. ghs.google.com. 21042 IN CNAME ghs.l.google.com. ;; AUTHORITY SECTION: l.google.com. 437 IN SOA ns3.google.com. dns-admin.google.com. 1577052 900 900 1800 60 ;; Query time: 0 msec ;; SERVER: 2607:fe28:0:4000::20#53(2607:fe28:0:4000::20) ;; WHEN: Tue Dec 23 09:04:25 2014 ;; MSG SIZE rcvd: 127 DNS server: 10.20.0.100 (server3 behind load-balancer) ; <<>> DiG 9.7.3 <<>> www.revk.uk @10.20.0.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60172 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.revk.uk. IN ;; ANSWER SECTION: www.revk.uk.3600IN CNAME ghs.google.com. ghs.google.com. 196602 IN CNAME ghs.l.google.com. ;; AUTHORITY SECTION: l.goog
RE: still have named memory leak
Here’s some suggestions from ISC on capturing information on this memory growth issue: https://kb.isc.org/article/AA-01208 Frank From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Oberman Sent: Saturday, December 13, 2014 12:07 PM To: Mukund Sivaraman Cc: bind-users@lists.isc.org Subject: Re: still have named memory leak On Fri, Dec 12, 2014 at 8:12 AM, Mukund Sivaraman mailto:m...@isc.org> > wrote: Hi Len On Fri, Dec 12, 2014 at 09:52:23AM -0600, lcon...@go2france.com <mailto:lcon...@go2france.com> wrote: > binary upgraded Freebsd 10 to Freebsd 10.1 > > named 9.10.1, compiled from source > > at named start, 305 MB memory > > after several hours of running named is approaching 800 MB. I'm sure after a > couple of days, as before, it will head towards 2000 MB > > suggestions? > > this is a recursive only NS, about 20M q/day restricted by ACL to > "ournetworks" This tells us that the named process size grows large, but more information is needed to discover why. Can you send us the following? 1. Your named configuration. 2. Regular dumps over time of the statistics that are available via HTTP, as the named process grows. See the "statistics-channels" documentation in the manual. You can use curl or wget to dump them to a file. The standard tool for this on FreeBSD is fetch(1). E.g. fetch -o FILE "URL" In a script I usually also use '-q' to eliminate noise, but YMMV. I suspect most systems have wget and/or curl installed, but fetch is always present on FreeBSD. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com <mailto:rkober...@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: rndc flushname not working
Next time I'll dump the db. Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Thursday, December 11, 2014 10:32 AM To: bind-users@lists.isc.org Subject: Re: rndc flushname not working >> On 09.12.14 21:36, Frank Bulk wrote: >>> Perhaps it wasn't NXDOMAIN -- I didn't capture the output. But there >>> definitely was not answer. The institution only has two authoritative >>> nameserver entries, both pointing to the same IP, so all it was all down. >>> >>> In any case, why doesn't flushing the name work? >On Wed, Dec 10, 2014 at 3:36 AM, Matus UHLAR - fantomas >wrote: >> I'm afraid we can't tell you without precise information. >> However, the institution should get at least one backup DNS server... On 11.12.14 09:35, Bob Harold wrote: >If a DNS server does not respond, I believe that BIND caches that fact, but >it is tied to the DNS server IP (or name?) and not to the domain, so >flushing the domain name would not affect it. ...and this cache is very short, 5 minutes IIRC. it's really hard to tell without more info... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.* ___ 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 ___ 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: rndc flushname not working
Perhaps it wasn't NXDOMAIN -- I didn't capture the output. But there definitely was not answer. The institution only has two authoritative nameserver entries, both pointing to the same IP, so all it was all down. In any case, why doesn't flushing the name work? Frank -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, December 09, 2014 9:32 PM To: Frank Bulk Cc: bind-us...@isc.org Subject: Re: rndc flushname not working Nameservers being down does not result in NXDOMAIN responses. I suspect that some of the auth servers were producing NXDOMAIN incorrectly. Flushing the name won't help in those cases. In message <001001d01429$1c857f70$55907e50$@iname.com>, "Frank Bulk" writes: > Our ISP operations are running a mixture of 9.7.3 and 9.8.4 on several > Debian servers and we've noticed that rndc flushname doesn't work many > times. > > This weekend we had a local institution whose own authoritative DNS servers > [all of them] were offline for 48+ hours and so there were several > negatively cached entries in our resolvers' caches from customers who were > querying for their institutions website and MX record. After the > institution restored connectivity to their DNS servers this afternoon I > checked all our resolvers and a few returned NXDOMAIN for the www and MX > record. Issuing rndc flushname and rndc flushname > didn't clear out the NXDOMAIN. I had to use "rndc flush" to resolve the > issue. > > Is this expected behavior? The next time I see what, what troubleshoot > steps should I take diagnose the issue? Dump the DB? > > Frank > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
rndc flushname not working
Our ISP operations are running a mixture of 9.7.3 and 9.8.4 on several Debian servers and we've noticed that rndc flushname doesn't work many times. This weekend we had a local institution whose own authoritative DNS servers [all of them] were offline for 48+ hours and so there were several negatively cached entries in our resolvers' caches from customers who were querying for their institutions website and MX record. After the institution restored connectivity to their DNS servers this afternoon I checked all our resolvers and a few returned NXDOMAIN for the www and MX record. Issuing rndc flushname and rndc flushname didn't clear out the NXDOMAIN. I had to use "rndc flush" to resolve the issue. Is this expected behavior? The next time I see what, what troubleshoot steps should I take diagnose the issue? Dump the DB? Frank ___ 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: forwarding zone to another DNS server problem
houguanghua wrote: > >> Can bind support forwarding zone to another DNS server? In my testing, >> for loacl name servers, it can. But for authority name servers, it >> can't. >Use "stub" or "static-stub" to forward to an authoritative server. What is the advantage of using a "stub" or "static-stub" to using a slave? Thanks, Frank ___ 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: Digging to the final IP
Dave, Thanks for the input, but what I was looking for was a dig command that returns the IP(s) or a fail. It looks like the host command is the right solution in this case, not dig. Kind regards, Frank -Original Message- From: Dave Knight [mailto:d...@knig.ht] Sent: Tuesday, October 21, 2014 8:21 PM To: Frank Bulk Cc: bind-users Subject: Re: Digging to the final IP On Oct 19, 2014, at 1:26, Frank Bulk wrote: > Is there a dig option that will list out the final (IPs) or query result?? > By default, even with +short, it can list intermediate CNAME(s) and not what > IP(s) that CNAME may have. > > For example, > root@nagios:/tmp# dig mail.automatedwastesystems.net +short > mail3.sandhills.com. > root@nagios:/tmp# > > I'd rather know that mail3.sandhills.com is NXDOMAIN. > > Regards, > > Frank How about. $ dig +noall +answer mail.automatedwastesystems.net in a | egrep 'IN\tA\t' | cut -f6 which correctly returns nothing in this case, but when there's a CNAME chain ending in addresses it returns them $ dig +noall +answer dave.knig.ht in a | egrep 'IN\tA\t' | cut -f6 216.235.14.46 and surely you want IPv6 support. $ dig +noall +answer dave.knig.ht in a dave.knig.ht in | egrep 'IN\t(A|)\t' | cut -f6 216.235.14.46 2001:4900:1:393::2 dave ___ 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: Digging to the final IP
That feature runs on our system, but it doesn't digging through to a final IP or failure: getent ahosts mail.automatedwastesystems.net returns nothing. Regards, Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Phil Mayers Sent: Monday, October 20, 2014 8:39 AM To: bind-users@lists.isc.org Subject: Re: Digging to the final IP On 20/10/14 14:22, Frank Bulk (iname.com) wrote: > We're using this in a bash shell script. I don't think there's a native > shell command to get the IP, so I'll use a mixture of host and dig as > necessary. If your system has it, try "getent" e.g. getent ahosts hostname ___ 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 ___ 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: Digging to the final IP
We’re using this in a bash shell script. I don’t think there’s a native shell command to get the IP, so I’ll use a mixture of host and dig as necessary. Thanks, Frank From: Fajar A. Nugraha [mailto:w...@fajar.net] Sent: Sunday, October 19, 2014 11:04 PM To: Frank Bulk Cc: comp-protocols-dns-b...@isc.org Subject: Re: Digging to the final IP What are you using this for? If it's part of a script, it might be easier to just use gethostbyname. For example, in php: http://php.net/manual/en/function.gethostbyname.php , Returns the IPv4 address or a string containing the unmodified hostname on failure. -- Fajar On Mon, Oct 20, 2014 at 10:43 AM, Frank Bulk mailto:frnk...@iname.com> > wrote: Thanks, what I ended up using. Didn't think that there was anything host could do that dig couldn't do. Frank -Original Message- From: bind-users-boun...@lists.isc.org <mailto:bind-users-boun...@lists.isc.org> [mailto:bind-users-boun...@lists.isc.org <mailto:bind-users-boun...@lists.isc.org> ] On Behalf Of Barry Margolin Sent: Sunday, October 19, 2014 5:00 AM To: comp-protocols-dns-b...@isc.org <mailto:comp-protocols-dns-b...@isc.org> Subject: Re: Digging to the final IP In article mailto:mailman.1097.1413711142.26362.bind-us...@lists.isc.org> >, Sten Carlsen mailto:st...@s-carlsen.dk> > wrote: > Would "host" be closer to what you want? Host also tells you about aliases it encounters along the way. > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > > "MALE BOVINE MANURE!!!" > > > On 19 Oct 2014, at 08:05, Karl Auer > <mailto:ka...@biplane.com.au> > wrote: > > > >> On Sun, 2014-10-19 at 00:26 -0500, Frank Bulk wrote: > >> Is there a dig option that will list out the final (IPs) or query result?? > >> By default, even with +short, it can list intermediate CNAME(s) and not > >> what > >> IP(s) that CNAME may have. > > > > Not great, but might be enough to be helpful: > > > > dig +nonssearch $1 | egrep -i "STATUS|^$1" > > > > Regards, K. > > > > -- > > ~~~ > > Karl Auer (ka...@biplane.com.au <mailto:ka...@biplane.com.au> ) > > http://www.biplane.com.au/kauer > > http://twitter.com/kauer389 > > > > GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > > > > > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> > > https://lists.isc.org/mailman/listinfo/bind-users -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users ___ 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: Digging to the final IP
Thanks, what I ended up using. Didn't think that there was anything host could do that dig couldn't do. Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry Margolin Sent: Sunday, October 19, 2014 5:00 AM To: comp-protocols-dns-b...@isc.org Subject: Re: Digging to the final IP In article , Sten Carlsen wrote: > Would "host" be closer to what you want? Host also tells you about aliases it encounters along the way. > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > > "MALE BOVINE MANURE!!!" > > > On 19 Oct 2014, at 08:05, Karl Auer wrote: > > > >> On Sun, 2014-10-19 at 00:26 -0500, Frank Bulk wrote: > >> Is there a dig option that will list out the final (IPs) or query result?? > >> By default, even with +short, it can list intermediate CNAME(s) and not > >> what > >> IP(s) that CNAME may have. > > > > Not great, but might be enough to be helpful: > > > > dig +nonssearch $1 | egrep -i "STATUS|^$1" > > > > Regards, K. > > > > -- > > ~~~ > > Karl Auer (ka...@biplane.com.au) > > http://www.biplane.com.au/kauer > > http://twitter.com/kauer389 > > > > GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > > > > > > ___ > > 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 -- Barry Margolin Arlington, MA ___ 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 ___ 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
Digging to the final IP
Is there a dig option that will list out the final (IPs) or query result?? By default, even with +short, it can list intermediate CNAME(s) and not what IP(s) that CNAME may have. For example, root@nagios:/tmp# dig mail.automatedwastesystems.net +short mail3.sandhills.com. root@nagios:/tmp# I'd rather know that mail3.sandhills.com is NXDOMAIN. Regards, Frank ___ 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
FreeBSD ports 9.8.7 problem with transfert to slave
Hello Since I upgraded to 9.8.7 on my two DNS the automated zones transfert from master to slave does not occurs automatically , I haven't change configuration files, serials are well incremented by a script that works for years BIND is installed from FreeBSD ports on the two machines, I wonder if something has changed from 9.8.6 and 9.8.7 in configuration of BIND ? Thank you ___ 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
Difference between BIND 9.8 and 9.9
Hello is there a link to a documentation that lists the main differences between BIND 9.8 and 9.9 ? I would like to read it before swiching from 9.8 thank you ___ 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: Secondary DNS question...
Do you have a box such as a firewall or load-balancer sitting in front of ns1? Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of SH Development Sent: Tuesday, June 25, 2013 8:35 PM To: bind-users@lists.isc.org Subject: Re: Secondary DNS question... All very interesting, but I'm afraid at my level of expertise on DNS, I'm not following. If I'm broken, how do I attempt to fix? Someone mentioned that our ns1.starionhost.net was not authoritative. How does one even decide that? As far as I know I haven't had any issues until now... Jeff On Jun 25, 2013, at 6:26 AM, Matus UHLAR - fantomas wrote: >> On 24.06.13 07:41, Frank Bulk wrote: >>> Interesting to note that querying for ANY does return an SOA. I can't >>> explain that behavior. > > On 24.06.13 14:54, Matus UHLAR - fantomas wrote: >> I can guess a kind of DNS filter/firewall. Some l3 switches or load >> balancers tend to produce strange results too... > > aa! I am getting response packets but they are somehoe not accepted by dig: > > % dig +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > ... in the meantime: > > 13:21:38.837415 IP (tos 0x0, ttl 64, id 9452, offset 0, flags [none], proto UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:39.009098 IP (tos 0x10, ttl 50, id 15611, offset 0, flags [none], proto UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > 13:21:43.837389 IP (tos 0x0, ttl 64, id 9453, offset 0, flags [none], proto UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:44.009780 IP (tos 0x10, ttl 50, id 4231, offset 0, flags [none], proto UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > 13:21:48.837515 IP (tos 0x0, ttl 64, id 9454, offset 0, flags [none], proto UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:49.011060 IP (tos 0x10, ttl 50, id 38531, offset 0, flags [none], proto UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xf531!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns2.starionhost.net., starionline.com. [1d] NS ns1.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > > >>> stariononline.com has two NSes listed, ns1.starionhost.net [74.87.108.83] >>> and ns2.starionhost.net [64.136.200.138]. But the first one does not seem >>> to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and >>> http://www.zonecut.net/dns/index.cgi are just a few examples) to a few of >>> the online checkers. I checked with some others and it looks like you have >>> no SOA set for for ns1.starionhost.net: > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > I don't have lysdexia. The Dog wouldn't allow 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 > ___ Please visit
RE: Secondary DNS question...
Interesting to note that querying for ANY does return an SOA. I can't explain that behavior. C:\>dig ANY starionline.com @ns1.starionhost.net ; <<>> DiG 9.8.0-P1 <<>> ANY starionline.com @ns1.starionhost.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64321 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;starionline.com. IN ANY ;; ANSWER SECTION: starionline.com.86400 IN SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 starionline.com.86400 IN NS ns2.starionhost.net. starionline.com.86400 IN NS ns1.starionhost.net. starionline.com.86400 IN MX 20 mailfoundry.starionhost.net. starionline.com.86400 IN MX 10 canit.starionhost.net. starionline.com.86400 IN A 74.87.108.83 ;; ADDITIONAL SECTION: ns1.starionhost.net.86400 IN A 74.87.108.83 ns2.starionhost.net.86400 IN A 64.136.200.138 canit.starionhost.net. 86400 IN A 74.62.79.198 mailfoundry.starionhost.net. 86400 IN A 74.87.108.85 ;; Query time: 86 msec ;; SERVER: 74.87.108.83#53(74.87.108.83) ;; WHEN: Mon Jun 24 07:38:33 2013 ;; MSG SIZE rcvd: 255 C:\> -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Frank Bulk Sent: Saturday, June 22, 2013 8:56 PM To: 'SH Development'; bind-users@lists.isc.org Subject: RE: Secondary DNS question... stariononline.com has two NSes listed, ns1.starionhost.net [74.87.108.83] and ns2.starionhost.net [64.136.200.138]. But the first one does not seem to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and http://www.zonecut.net/dns/index.cgi are just a few examples) to a few of the online checkers. I checked with some others and it looks like you have no SOA set for for ns1.starionhost.net: C:\>dig SOA starionline.com @ns1.starionhost.net ; <<>> DiG 9.8.0-P1 <<>> SOA starionline.com @ns1.starionhost.net ;; global options: +cmd ;; connection timed out; no servers could be reached C:\> Though the second one has one: C:\>dig SOA starionline.com @ns2.starionhost.net ; <<>> DiG 9.8.0-P1 <<>> SOA starionline.com @ns2.starionhost.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7010 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;starionline.com. IN SOA ;; ANSWER SECTION: starionline.com.86400 IN SOA ns1.starionhost.net. info.starionhost.net. 2008 3600 ;; AUTHORITY SECTION: starionline.com.86400 IN NS ns1.starionhost.net. starionline.com.86400 IN NS ns2.starionhost.net. ;; ADDITIONAL SECTION: ns1.starionhost.net.86400 IN A 74.87.108.83 ns2.starionhost.net.86400 IN A 64.136.200.138 ;; Query time: 74 msec ;; SERVER: 64.136.200.138#53(64.136.200.138) ;; WHEN: Sat Jun 22 20:51:12 2013 ;; MSG SIZE rcvd: 157 C:\> And confirmed here: http://dns.squish.net/traverses/79b8efe4a31e6ddfce28f6abac444601 Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of SH Development Sent: Thursday, June 20, 2013 10:03 PM To: bind-users@lists.isc.org Subject: Secondary DNS question... Our secondary DNS machine went down (and unnoticed for 24 hours). Today, we had multiple people calling about email that hadn't come in, and trouble with outgoing emails not going out. Our primary DNS was up the whole time. So my question is, why would my secondary being down, and only my primary being up cause so many problems? I thought the whole idea behind having two DNS servers on different networks was to never have a failure like this. My understanding was that when DNS is queried, the one that responds fastest is the information that is used. If the secondary is down, then the primary would by default always be fastest (and only). I think I reasonably understand basic DNS and the setup, but this has me thinking that something isn't set up right. Can anyone shed any light on what might have happened here? Could my primary not be responding as it should? All the tests I have run on it show that it is responding normally. Jeff ___ Please visit https://list
RE: Secondary DNS question...
stariononline.com has two NSes listed, ns1.starionhost.net [74.87.108.83] and ns2.starionhost.net [64.136.200.138]. But the first one does not seem to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and http://www.zonecut.net/dns/index.cgi are just a few examples) to a few of the online checkers. I checked with some others and it looks like you have no SOA set for for ns1.starionhost.net: C:\>dig SOA starionline.com @ns1.starionhost.net ; <<>> DiG 9.8.0-P1 <<>> SOA starionline.com @ns1.starionhost.net ;; global options: +cmd ;; connection timed out; no servers could be reached C:\> Though the second one has one: C:\>dig SOA starionline.com @ns2.starionhost.net ; <<>> DiG 9.8.0-P1 <<>> SOA starionline.com @ns2.starionhost.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7010 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;starionline.com. IN SOA ;; ANSWER SECTION: starionline.com.86400 IN SOA ns1.starionhost.net. info.starionhost.net. 2008 3600 ;; AUTHORITY SECTION: starionline.com.86400 IN NS ns1.starionhost.net. starionline.com.86400 IN NS ns2.starionhost.net. ;; ADDITIONAL SECTION: ns1.starionhost.net.86400 IN A 74.87.108.83 ns2.starionhost.net.86400 IN A 64.136.200.138 ;; Query time: 74 msec ;; SERVER: 64.136.200.138#53(64.136.200.138) ;; WHEN: Sat Jun 22 20:51:12 2013 ;; MSG SIZE rcvd: 157 C:\> And confirmed here: http://dns.squish.net/traverses/79b8efe4a31e6ddfce28f6abac444601 Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of SH Development Sent: Thursday, June 20, 2013 10:03 PM To: bind-users@lists.isc.org Subject: Secondary DNS question... Our secondary DNS machine went down (and unnoticed for 24 hours). Today, we had multiple people calling about email that hadn't come in, and trouble with outgoing emails not going out. Our primary DNS was up the whole time. So my question is, why would my secondary being down, and only my primary being up cause so many problems? I thought the whole idea behind having two DNS servers on different networks was to never have a failure like this. My understanding was that when DNS is queried, the one that responds fastest is the information that is used. If the secondary is down, then the primary would by default always be fastest (and only). I think I reasonably understand basic DNS and the setup, but this has me thinking that something isn't set up right. Can anyone shed any light on what might have happened here? Could my primary not be responding as it should? All the tests I have run on it show that it is responding normally. Jeff ___ 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 ___ 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: forwarder is ignored when authoritative zone is added
On Fri, Oct 26, 2012 at 7:27 AM, Barry Margolin wrote:
> In article ,
> Frank Even wrote:
>
>> I've recently had an issue that I'm having some issues finding
>> information on solving.
>>
>> I have internal DNS resolvers...they act as recursive name servers for
>> general internet queries, but we have forwarders explicitly defined
>> for specific internal zones being served by other name servers.
>>
>> My configuration has one particular zone configured as such:
>>
>> zone "internal.organization.com" IN { type forward; forward only;
>> forwarders {172.x.x.x; 172.x.x.x; }; };
>>
>> I have our main zone, organization.com, hosted in an external area
>> outside of a firewall with a wildcard record contained in it for
>> anything that is not explicitly defined. I have some services that I
>> need to reach using names that are in this external zone internally.
>> What I'm trying to do is to slave the organization.com zone to my
>> internal recursive resolver to mitigate any possible network issues.
>>
>> So I setup the internal resolver as a slave for the "organization.com"
>> zone and found that queries against "internal.organization.com" were
>> getting answered with the wildcard for the external "organization.com"
>> zone. I can't seem to figure out why the forwarders are getting
>> ignored. Is it an order of precedence, say authoritative zones are
>> respected over forwarders...or something else??
>>
>> Thanks for any assistance anyone can provide, or point me to some
>> documentation I'm missing,
>> Frank
>
> Forwarders are only used when the server needs to recurse in the first
> place. They tell it "Instead of following the NS records, ask the
> forwarder(s)." If the server is authoritative for the zone, and there
> are no NS records delegating the subdomain away, it doesn't need to
> recurse and just returns what it has (in this case the record
> synthesized from the wildcard).
>
> Why not configure your resolvers as slaves or stubs for the internal
> subdomain?
Now that you put it that way the behavior makes perfect sense. Thanks!
I'd rather not do that to avoid having any internal records in
external DNS. I'm thinking of maybe running views on the internal box
instead, and putting the authoritative zone in an external view and
the rest of the current config in the internal view and forwarding
lookups to "organization.com" to the "external" view. Seems like the
only real way around it without a delegation of some some sort from
the master zone.
___
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
forwarder is ignored when authoritative zone is added
I've recently had an issue that I'm having some issues finding
information on solving.
I have internal DNS resolvers...they act as recursive name servers for
general internet queries, but we have forwarders explicitly defined
for specific internal zones being served by other name servers.
My configuration has one particular zone configured as such:
zone "internal.organization.com" IN { type forward; forward only;
forwarders {172.x.x.x; 172.x.x.x; }; };
I have our main zone, organization.com, hosted in an external area
outside of a firewall with a wildcard record contained in it for
anything that is not explicitly defined. I have some services that I
need to reach using names that are in this external zone internally.
What I'm trying to do is to slave the organization.com zone to my
internal recursive resolver to mitigate any possible network issues.
So I setup the internal resolver as a slave for the "organization.com"
zone and found that queries against "internal.organization.com" were
getting answered with the wildcard for the external "organization.com"
zone. I can't seem to figure out why the forwarders are getting
ignored. Is it an order of precedence, say authoritative zones are
respected over forwarders...or something else??
Thanks for any assistance anyone can provide, or point me to some
documentation I'm missing,
Frank
___
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: error (unexpected RCODE REFUSED) resolving
There's more: both ns1.netbcp.com and ns2.netbcp.net don't respond to
queries about nbc.com and ns1.netbcp.com doesn't respond over TCP.
Frank
From: bind-users-bounces+frnkblk=iname@lists.isc.org
[mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of
Kevin Darcy
Sent: Friday, October 12, 2012 12:48 PM
Cc: bind-users@lists.isc.org
Subject: Re: error (unexpected RCODE REFUSED) resolving
OK, so your nbc.com/A resolving error doesn't really have anything to do
with the nameservers you included in your original post.
It does appear, however, that ns2.netbcp.net (205.173.93.213) is refusing
requests generally for the nbc.com domain:
$ dig nbc.com +buf=4096 +norec @ns2.netbcp.net
; <<>> DiG 9.4.3-P3 <<>> nbc.com +buf=4096 +norec @ns2.netbcp.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1019
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nbc.com. IN A
;; Query time: 30 msec
;; SERVER: 205.173.93.213#53(205.173.93.213)
;; WHEN: Fri Oct 12 13:44:56 2012
;; MSG SIZE rcvd: 36
ns1.netbcp.com appears to be doing the same thing.
Not known whether this is something temporary (performing maintenance?), or
something permanent (provider's contract lapsed, but customer never updated
delegations).
In any case, you have enough working authoritative nameservers for the
domain, so it'll continue to resolve for you...
- Kevin
On 10/12/2012 1:35 PM, James Tingler wrote:
I don't think that I am. I only define internal forwarders for internal
zones as needed. For my root hint, standard configuration:
Named.conf
zone "." {
type hint;
file "named.ca";
Named.ca:
; <<>> DiG 9.5.0b2 <<>> +bufsize=1200 +norec NS . @a.root-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34420
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 360 IN 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 360 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 360 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 360 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 360 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 360 IN A 192.5.5.241
F.ROOT-SERVERS.NET. 360 IN 2001:500:2f::f
G.ROOT-SERVERS.NET. 360 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 360 IN A 128.63.2.53
H.ROOT-SERVERS.NET. 360 IN 2001:500:1::803f:235
I.ROOT-SERVERS.NET. 360 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 360 IN A 192.58.128.30
J.ROOT-SERVERS.NET. 360 IN 2001:503:c27::2:30
K.ROOT-SERVERS.NET. 360 IN A 193.0.14.129
K.ROOT-SERVERS.NET. 360 IN 2001:7fd::1
L.ROOT-SERVERS.NET. 360 IN A 199.7.83.42
M.ROOT-SERVERS.NET. 360 IN A 202.12.27.33
M.ROOT-SERVERS.NET. 360 IN 2001:dc3::35
;; Query time: 147 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 18 13:29:18 2008
;; MSG SIZE rcvd: 615
"named.ca" 52L, 1892C
>>> "Kevin Darcy" <mailto:k...@chrysler.com> 10/12/2012
1:20 PM >>>
On 10/12/2012 12:28 PM, James Tingler wrote:
Hello,
I'm getting what appears to be a common "error (unexpected RCODE REFUSED)
resolving" error. My research has lead me to disable IPv6 when starting the
named service with "named -4" as it could be related to IPv6 broken
connect
RE: Delegation bit-rot detection?
For the domains that we're primary and authoritative we check the listing of each customer's WHOIS record to confirm they're using the right DNS servers and then query our upstream's DNS server (which is slaving it) to make sure they're responding authoritatively. We also query a public DNS server to make sure the NS records that it returns for the domain are the right DNS servers. This has caught countless customers who let their domain registrations expire or whose third-party website developer moved DNS records to their preferred website host. I can't tell you how many times SMB/SME customers think that their DNS records need to reside with the company that hosts or manages their website. If a customer lets their domain expire and does not respond in a few days to our outreach we just remove the domain. No reason to give our customers different information than the rest of the world (yes, our recursive and authoritative somewhat overlap). Frank From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Fr34k Sent: Thursday, June 14, 2012 8:54 AM To: Phil Mayers; bind-users@lists.isc.org Subject: Re: Delegation bit-rot detection? We are exploring similar audits and opportunities for cleanup. For domains we delegate PTRs, we track NS hostnames (e.g. IN NS ns1.bogus.customer.tld) that have gone NXDOMAIN. If ns1.bogus.customer.tld remains NXDOMAIN for 30+ days, we remove the delegation. The idea behind 30+ days is to allow for a grace period. Why? If the domain expired and caught the owner by surprise, then 30 days allows time for the domain owner to renew before we make any changes (so that we do not waste time removing the delegation to only have to reinstate it). Perhaps a similar approach be worthwhile for auditing the secondary services. That is, parse BIND's config file (source of truth) for all secondary configs, run dedicated auditing tests (e.g. AXFR), record the outcomes, and act upon the defunct configurations per Policy. All that said, I am also interested in what others are doing. I am sure there are better methods out there. Thanks. _ From: Phil Mayers To: "bind-users@lists.isc.org" Sent: Thursday, June 14, 2012 9:19 AM Subject: Delegation bit-rot detection? All, Over the years, we have offered DNS secondary services to various organisations. Some of those organisations are (ahem) fairly small, and lots of the delegations and zone transfers have suffered bit-rot - there are zones delegated to us that I have no records on, and certainly can't AXFR from the masters (in some cases, the masters answer REFUSED as well). I'm wondering if anyone knows of a script that will process our logs looking for "refused" queries, and then post-process these by tracing the delegations and telling me what the nearest enclosing zone is, the NS records that led inbound queries to us, and (if any of the other NS records are responding) the SOA. I could write something, but there are a lot of corner cases, and I'm feeling lazy! OTOH if anyone has any suggestions (other than "ignore the refused", which is what we're currently doing) for dealing with these kinds of things... Cheers, Phil ___ 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 ___ 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: Choosing max-journal-size
One possible default setting is to say a certain percentages or volume of disk space free. Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Anand Buddhdev Sent: Wednesday, November 30, 2011 4:51 AM To: Phil Mayers Cc: bind-users@lists.isc.org Subject: Re: Choosing max-journal-size On 30/11/2011 10:32, Phil Mayers wrote: > We sort of did this accidentally. "max-journal-size" wasn't being set on > our servers - the .jnl file for "imperial.ac.uk" was nearly 2Gb... oops. > > The value I set it to eventually was pretty big - 128M globally - which > on our biggest zones seems to give ~2 months of history. This is almost > certainly overkill of a huge magnitude, but disk is relatively cheap! We had a similar issue. One one server, with hundreds of zones, several of which are updated frequently, we began getting disk space warnings from our monitoring system. The .jnl files were the culprits. We have a rather low setting of 10M for our journal size, but it's not ideal since the rate of change of the zones isn't the same. I think the default setting of "unlimited" for this option in BIND isn't a very good one. It can catch a system administrator unaware. On the other hand, I can't think what default setting the ISC folk could apply. Anand Buddhdev RIPE NCC ___ 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 ___ 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 9.7.3-P3 crash on multiple cashing servers
We had the same thing, affected only one of our DNS servers (behind a load-balancer). Here's the relevant log snippet: Nov 15 23:03:33 mail1 named[4601]: query.c:1781: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed, back trace Nov 15 23:03:33 mail1 named[4601]: #0 0x7f1b1e97686f in ?? Nov 15 23:03:33 mail1 named[4601]: #1 0x7f1b1d346b1a in ?? Nov 15 23:03:33 mail1 named[4601]: #2 0x7f1b1e982f8a in ?? Nov 15 23:03:33 mail1 named[4601]: #3 0x7f1b1e237e93 in ?? Nov 15 23:03:33 mail1 named[4601]: #4 0x7f1b1e263e9d in ?? Nov 15 23:03:33 mail1 named[4601]: #5 0x7f1b1e97aa1e in ?? Nov 15 23:03:33 mail1 named[4601]: #6 0x7f1b1e98036d in ?? Nov 15 23:03:33 mail1 named[4601]: #7 0x7f1b1e981bb7 in ?? Nov 15 23:03:33 mail1 named[4601]: #8 0x7f1b1d365439 in ?? Nov 15 23:03:33 mail1 named[4601]: #9 0x7f1b1c74a8ba in ?? Nov 15 23:03:33 mail1 named[4601]: #10 0x7f1b1c16202d in ?? Nov 15 23:03:33 mail1 named[4601]: exiting (due to assertion failure) All times are U.S. Central Time and we're running on Debian (Linux mail1 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux). server:/etc/rc3.d# /usr/sbin/named -v BIND 9.7.3 server:/ Frank From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Samer Khattab Sent: Wednesday, November 16, 2011 2:09 AM To: bind-users@lists.isc.org Subject: BIND 9.7.3-P3 crash on multiple cashing servers 8 of our cashing-only name servers crashed in a random sequence, and the crash happened in a 10 minutes time. The servers are running BIND 9.7.3-P3. The crash produced a core dump for the named process. Does anybody has a similar case recently? Is this a security issue ? Regards, Samer ___ 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: rndc: 'addzone' failed: permission denied
Would be nice if the error output or log would indicate such failures. Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Tony Finch Sent: Wednesday, August 17, 2011 9:31 AM To: Fredrik Poller Cc: bind-users@lists.isc.org Subject: RE: rndc: 'addzone' failed: permission denied To use `rndc addzone`, named needs to be able to write to the zone configuration file in its working directory, called 3bf305731dd26307.nzf for the _default view. Both named and the user invoking rndc need to be able to read the rndc.key file which is usually in /etc. You need to create the zone's master file on disk (and any keys etc.) before running `rndc addzone`. Tony. -- f.anthony.n.finchhttp://dotat.at/ South-east Iceland: Cyclonic 3 or 4, increasing 5 or 6 for a time in north. Slight or moderate. Rain. Moderate or good, occasionally poor. ___ 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 ___ 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: Compromised BIND?
Yes, this message arrived in my Inbox 44 minutes after it was sent. Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Warren Kumari Sent: Tuesday, May 31, 2011 4:59 PM To: Warren Kumari Cc: bind-users@lists.isc.org Subject: Re: Compromised BIND? Does anyone else find the bind-users list to be very slow? webster.isc.org (localhost [IPv6:::1]) Tue, 31 May 2011 19:48:30 + -> webster.isc.org (webster.isc.org) Tue, 31 May 2011 20:52:09 + Or is it just me seeing this? W On May 31, 2011, at 4:17 PM, Warren Kumari wrote: > > On May 31, 2011, at 3:22 PM, Kevin Darcy wrote: > >> On 5/31/2011 2:38 PM, Supersonic wrote: >>> I have a BIND 9.8.0-P2 server instance running on a production server. >> >> Doing what, exactly? Resolving internal names only? Resolving Internet names? Acting as an authoritative server for internal clients? Internet clients? Some combination of the above? >> >>> My firewall is showing repeated attempts by named.exe to connect to IP addresses in foreign countries on ports , 6667 and 6669 - common IRC ports used by worms/trojans/zombies. Checking my named.exe file, it shows that it is unchanged from the installation source. Is this connection normal? Should I be allowing it? >>> >> TCP connections or UDP packets? >> >> If you're serving authoritative data to Internet clients, then my guess is your firewall simply isn't "stateful" enough to realize that these are responses to DNS queries that originally came in from Internet clients using those port numbers. Just because they are "common IRC ports used by worms/trojans/zombies" doesn't preclude them from also being chosen at random as the source ports of incoming queries to your nameserver. Responses go back to the same port from which the query was received. > > > Can you make a distribution of ports and see if it contacts other port numbers with approximately the same frequency? I'm guessing this is just the FW / IDS being "helpful" > > W > >> >> If they're outgoing TCP connections, I'd be worried. Offhand, I can't think of any legitimate reason why named would be trying to TCP-connect to any port other than 53. >> >> - Kevin >> >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Compromised BIND?
Yes, this message arrived in my Inbox 44 minutes after it was sent. Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Warren Kumari Sent: Tuesday, May 31, 2011 4:59 PM To: Warren Kumari Cc: bind-users@lists.isc.org Subject: Re: Compromised BIND? Does anyone else find the bind-users list to be very slow? webster.isc.org (localhost [IPv6:::1]) Tue, 31 May 2011 19:48:30 + -> webster.isc.org (webster.isc.org) Tue, 31 May 2011 20:52:09 + Or is it just me seeing this? W On May 31, 2011, at 4:17 PM, Warren Kumari wrote: > > On May 31, 2011, at 3:22 PM, Kevin Darcy wrote: > >> On 5/31/2011 2:38 PM, Supersonic wrote: >>> I have a BIND 9.8.0-P2 server instance running on a production server. >> >> Doing what, exactly? Resolving internal names only? Resolving Internet names? Acting as an authoritative server for internal clients? Internet clients? Some combination of the above? >> >>> My firewall is showing repeated attempts by named.exe to connect to IP addresses in foreign countries on ports , 6667 and 6669 - common IRC ports used by worms/trojans/zombies. Checking my named.exe file, it shows that it is unchanged from the installation source. Is this connection normal? Should I be allowing it? >>> >> TCP connections or UDP packets? >> >> If you're serving authoritative data to Internet clients, then my guess is your firewall simply isn't "stateful" enough to realize that these are responses to DNS queries that originally came in from Internet clients using those port numbers. Just because they are "common IRC ports used by worms/trojans/zombies" doesn't preclude them from also being chosen at random as the source ports of incoming queries to your nameserver. Responses go back to the same port from which the query was received. > > > Can you make a distribution of ports and see if it contacts other port numbers with approximately the same frequency? I'm guessing this is just the FW / IDS being "helpful" > > W > >> >> If they're outgoing TCP connections, I'd be worried. Offhand, I can't think of any legitimate reason why named would be trying to TCP-connect to any port other than 53. >> >> - Kevin >> >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Split DNS Configuration in BIND
Point taken, and I should have mentioned that it's NAT in play. I agree, it's a problem that not all firewalls can hairpin public IPs back to their private IPs, but when working with what you got sometimes the solution isn't ideal. Frank -Original Message- From: Doug Barton [mailto:do...@dougbarton.us] Sent: Monday, May 30, 2011 2:19 PM To: frnk...@iname.com Cc: 'babu dheen'; bind-users@lists.isc.org Subject: Re: Split DNS Configuration in BIND On 05/30/2011 09:15, Frank Bulk wrote: > Not all firewalls can hairpin a public IP back to a private IP. We've > had to do this, too. First, firewalls don't do routing. :) > Yes, we could have create a separate zone, but that would requiring > training our staff to use on FQDN internally and another with the > customers. Easier to teach one thing to the staff and push the > complexity back on the configuration. Second, s/configuration/DNS/, which I would argue is the wrong layer. Solve routing problems at the routing layer. But I realize that there are differing opinions on this. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Split DNS Configuration in BIND
Not all firewalls can hairpin a public IP back to a private IP. We've had to do this, too. Yes, we could have create a separate zone, but that would requiring training our staff to use on FQDN internally and another with the customers. Easier to teach one thing to the staff and push the complexity back on the configuration. Frank From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of babu dheen Sent: Monday, May 30, 2011 1:17 AM To: Doug Barton Cc: bind-users@lists.isc.org Subject: Re: Split DNS Configuration in BIND Dear Doug, Appreciate your quick response. Actually this setup is very much required for us. Let me tell you the scenario: We have DNS record called "mail.company.com" which is hosted in internal company LAN network. When any users try to access mail.company.com in browser, they will get private IP address and immediately they will get mail.company.com website home page whereas if any of my company users try to access the mail.company.com website from internet(outside company), they should get public IP address which should be pointed to mail.company.com website. Kindly let me know solution for the same. Regards Babu --- On Mon, 30/5/11, Doug Barton wrote: From: Doug Barton Subject: Re: Split DNS Configuration in BIND To: "babu dheen" Cc: bind-users@lists.isc.org Date: Monday, 30 May, 2011, 11:15 AM On 05/29/2011 21:59, babu dheen wrote: > Hi, > Would like to know how to configure split DNS in BIND running in RHEL > 5.0 version. Below is our setup and requirement. > " We have a zone called "mycompany.com" . So whenever my company users > sitting in LAN try to access mycompany.com domain in explorer, they > should get internal IP address(private IP address) whereas whenever > users from internet should get public IP for mycompany.com domain" Better yet, re-examine the reasons you want to do this, and consider not doing it. It's incredibly rare that using split DNS is a solution to a real problem, it's almost always something that people do because they think they need to. On the other hand, if you really need/want to have internal addresses to access company resources, consider placing them in a separate zone. Something like int.mycompany.com. You have to put these addresses in a separate zone _file_ anyway, why not make it a separate zone? It will reduce complexity for you in the long run. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND Security Advisory May 2011: Large RRSIG RRsets and Negative Caching can crash named
Hello, I would want to say thank you very much for the wonderful work of the ISC team and the quick solution of the problem and a very professional appearance. Happy patching & a nice weekend Frank -- +----+ Frank Kloeker Operations and Optimization of Internet Solutions (TZO) Vodafone D2 GmbH / Main Office Eschborn / Terminal B ++ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bug in bind 9.7.3?
Hi, I using bind 9.7.3 as resolver in a slightly larger server farm with some mail servers that use domain key validation. If a try # host -t TXT _adsp._domainkey.federalreserve.gov bind dies with May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1 <= b->length) failed May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure) This is reproducible and should only affected in 9.7.3. Can this be possible? kind regards Frank -- +----+ Frank Kloeker Operations and Optimization of Internet Solutions (TZO) Vodafone D2 GmbH / Main Office Eschborn / Terminal B ++ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
"Good" TTL value for DDNS clients ?
Hello I'm setting up a DDSN server , following the ISC documentation it is working nicely. But I would like some guidance on setting up the TTL value for DHCP/DDNS clients. We use a lot of dual boot machines WINDOWS/LINUX and with default parameters the DDNS record isn't removed from the DDNS when a user switch from one OS to another. Any info help welcome. Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Some hosts not resolving from No-IP by our DNS servers
Yes, thank you. The user entered the domain incorrectly. The oa.no-ip.info +trace resolves correctly. -Original Message- From: Dan Durrer [mailto:d...@vitalwerks.com] Sent: Wed 3/9/2011 1:46 PM To: Chuck Swiger Cc: Frank Pikelner; bind-users@lists.isc.org Subject: Re: Some hosts not resolving from No-IP by our DNS servers Yeah.. in-ip.info is probably supposed to be no-ip.info? Dan Durrer No-IP On Mar 9, 2011, at 10:38 AM, Chuck Swiger wrote: > Hi-- > > On Mar 9, 2011, at 10:25 AM, Frank Pikelner wrote: >> I'm having a problem resolving several hosts from NO-IP. When I attempt to >> resolve them from our DNS servers I get no reply (we can resolve other >> hosts). I'm not certain why the resolution stops. If I force a resolution >> using external DNS servers using dig (i.e. Google 8.8.8.8) the hosts resolve >> without problem. Here is the trace from our DNS server: >> >> dig oa.in-ip.info +trace > > I see NXDOMAIN for oa.in-ip.info here, and whois doesn't seem to believe that > in-ip.info exists > > Regards, > -- > -Chuck > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Some hosts not resolving from No-IP by our DNS servers
Hello, I'm having a problem resolving several hosts from NO-IP. When I attempt to resolve them from our DNS servers I get no reply (we can resolve other hosts). I'm not certain why the resolution stops. If I force a resolution using external DNS servers using dig (i.e. Google 8.8.8.8) the hosts resolve without problem. Here is the trace from our DNS server: dig oa.in-ip.info +trace ; <<>> DiG 9.6-ESV-R1 <<>> oa.in-ip.info +trace ;; global options: +cmd . 25973 IN NS j.root-servers.net. . 25973 IN NS e.root-servers.net. . 25973 IN NS m.root-servers.net. . 25973 IN NS k.root-servers.net. . 25973 IN NS b.root-servers.net. . 25973 IN NS d.root-servers.net. . 25973 IN NS f.root-servers.net. . 25973 IN NS g.root-servers.net. . 25973 IN NS h.root-servers.net. . 25973 IN NS c.root-servers.net. . 25973 IN NS i.root-servers.net. . 25973 IN NS a.root-servers.net. . 25973 IN NS l.root-servers.net. ;; Received 436 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS c0.info.afilias-nst.info. ;; Received 434 bytes from 192.58.128.30#53(j.root-servers.net) in 230 ms info. 900 IN SOA a0.info.afilias-nst.info. noc.afilias-nst.info. 2009263081 3600 1800 604800 3600 ;; Received 91 bytes from 199.249.113.1#53(a2.info.afilias-nst.info) in 3 ms Would appreciate any pointers. Thank you, Frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Need infos to setup a subdomain with DDNS + DHCP
Hello I have to set up a subdomain that will works with DDNS and DHCP Our domain does not have DHCP or DDNS so I would like to setup a delegate DNS acting for the subdomain. Any infos, links , howto , configurations examples , welcome ! Thanks a lot. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: new webserver ip
Which DNS server are you digging? It's possible that (by default) you're digging against a server that has the old entry still cached. Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of dhottin...@harrisonburg.k12.va.us Sent: Tuesday, August 03, 2010 7:08 AM To: bind-users@lists.isc.org Subject: new webserver ip My employer decided to host our website on another server off-site. My problem is getting our dns to point from our old server to the new. Currently we own all the ip's and host our own website. Here is the zone file for harrisonburg.k12.va.us: $ORIGIN . $TTL 259200 ; 3 days harrisonburg.k12.va.us IN SOA ns1.harrisonburg.k12.va.us. rlineweaver.harrisonburg.k12.va.us. ( 201080503 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 2419200; expire (4 weeks) 86400 ; minimum (1 day) ) NS ns1.harrisonburg.k12.va.us. NS ns2.harrisonburg.k12.va.us. $TTL 144000 ; 40 hours harrisonburg.k12.va.us. MX 10 plum.harrisonburg.k12.va.us. mail.harrisonburg.k12.va.us.MX 10 plum.harrisonburg.k12.va.us. student.harrisonburg.k12.va.us. MX 10 plum.harrisonburg.k12.va.us. harrisonburg.k12.va.us. IN TXT "v=spf1 ip4:204.111.40.0/24 a:mail.harrisonburg.k12.va.us a:student.harrisonburg.k12.va.us ~all" $ORIGIN harrisonburg.k12.va.us. $TTL 259200; 3 days harrisonburg.k12.va.us. A 174.143.193.47 I made the entry for the new website's ip (174.143.193.47). But when I do a dig, it still comes back with 204.111.40.10. What do I need to do in order to get this ip to point to the newserver offsite? Or is it even possible for me to do this? ddh -- Dwayne Hottinger Network Administrator Harrisonburg City Public Schools "Everything should be made as simple as possible, but not simpler." -- Albert Einstein "The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality." -- Dante ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how do I get a slave to send NOTIFY messages?
On 1/31/10 10:08 PM -0500 Joseph S D Yao wrote: I suspect that the notify option is set to 'no' either in your global options or in your view or in your zone. Indeed, I had a global "notify no" option. I misunderstood the way that zone-specific also-notify and the global notify option interact. thanks -frank ps I'll send a note to zytrax about the error in their docs. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Having multiple name servers - is it really necessary
On February 2, 2010 2:25:50 PM -0800 Rob Tanner wrote: cached (i.e. Is no data treated the same as bad data by upstream bind servers? I didn't entirely follow your ramble (paragraphs would have helped), but it's not BIND or other nameservers that would be the real problem, it's the applications that depend on name services. For example, if your link goes down and instead of a DNS lookup which results in an answer of an MX server that doesn't respond, someone trying to send you mail would (after cache timeout) get back a non-result DNS answer and might bounce a mail instead of queueing it for later delivery. That's perhaps not a good example because actually MTAs should handle this case as a transient error and queue any mail, but you get my point. Consider also that folks just browsing your website will get a different kind of error which might lead them to believe that your site doesn't even exist. That would definitely be worse than "connection timed out". Other applications may result in similar types of disconcerting errors instead of just connection timeouts. You really do need multiple nameservers, and you absolutely need to make your DNS zone transfers reliable. I do sympathize with you. Old data is often worse than no data. -frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY logging problem
On February 1, 2010 1:12:56 PM +1100 Mark Andrews wrote: In message , Frank Cusack writes: On February 1, 2010 11:35:15 AM +1100 Mark Andrews wrote: > You need to be looking a debug 3. > > notify_log(notify->zone, ISC_LOG_DEBUG(3), "sending notify to > %s", addrbuf); ouch, debug 3 is probably way TMI. I guess I'll just patch the above to log at info. Why isn't that the default anyway? Seems to me that you aren't likely to have "too many" servers and the "info" level is already pretty verbose so you would expect (or at least *I* would expect) to have that amount of information. When you have 10+ zones with 10's of servers it gets noisy. quite. I hadn't considered there would be a log entry per zone. -frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTIFY logging problem
On February 1, 2010 11:35:15 AM +1100 Mark Andrews wrote: You need to be looking a debug 3. notify_log(notify->zone, ISC_LOG_DEBUG(3), "sending notify to %s", addrbuf); ouch, debug 3 is probably way TMI. I guess I'll just patch the above to log at info. Why isn't that the default anyway? Seems to me that you aren't likely to have "too many" servers and the "info" level is already pretty verbose so you would expect (or at least *I* would expect) to have that amount of information. As it is, and I mean without turning on debug logging, I have to infer what servers notify was sent to based on AXFR/IXFR requests. (I try not to trust looking at config files when debugging because you can't be sure that the running config is the same as the on-disk config.) Anyway thanks for the pointer, it looks trivial to update. -frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
how do I get a slave to send NOTIFY messages?
I have also-notify configured for a slave zone. The real master is a so-called stealth master and all other slaves must consult this slave nameserver that has also-notify configured. The slave doesn't appear to be sending NOTIFY messages to the also-notify hosts. zytrax does say that also-notify only applies to type master servers however I can't find confirmation of that anywhere else. Note that I do not want to send NOTIFY messages to the NS servers for the zone, I want to send them to different servers. thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
NOTIFY logging problem
How can I get logs of all NOTIFY messages sent?
logging {
// use local0 instead of daemon
channel local0_syslog {
syslog local0;
severity info;
};
category notify{ local0_syslog; default_debug; };
};
The above only generates a summary log:
zone XXX/IN/internet: sending notifies (serial 2010012700)
I'd like to see a verification of every host a NOTIFY message was sent to.
-frank
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
AW: Disabling recursion causes browser hangs on clients with auto proxy config
Thanks very much to everyone who replied and explained this set
of problems in such detail to me. It's now clear as day and of
course you are correct. You have made my day. :-)
As for "allow-query" instead of "allow-recursion" - I see what
you mean, the stub resolvers seem to react differently to
"recursion not available" than they do for flat out "refused",
especially when there are more than one name servers configured.
However I cannot refuse because the clients still need to be
able to resolve our zones. I will work something out for this,
so thanks for that hint as well.
Regards
Frank
- Originalnachricht -
Von: "Kevin Darcy"
Gesendet: Die, 26.1.2010 00:08
An: bind-users@lists.isc.org
Betreff: Re: AW: Disabling recursion causes browser hangs on clients with auto
proxy config
On 1/25/2010 2:47 PM, Niall O'Reilly wrote:
> Frank Stanek wrote:
>> I'm sorry but I don't quite understand what you mean. Could you
>> please elaborate this on the basis of this excerpt from our pac
>> file?
>>
>> function FindProxyForURL(url, host)
>> {
>> var proxy1 = "PROXY 192.168.240.29:8080";
>> var proxy2 = "PROXY 172.16.1.30:8080";
>> if ( dnsDomainIs(host, ".intern")
>> || shExpMatch(url, "*//localhost*")
>> || shExpMatch(url, "*//127*")
>
> So far so good: you've tried to match part of the text of the
> URL against each of those rules.
>
>> || isInNet(host, "192.168.1.0", "255.255.255.0")
>> // more lines with subnets
>
> Before applying this rule, your browser has to convert the
> domain name given in the URL to an address, in order to check
> whether the address belongs to the subnet. Since you've
> chosen to block recursive name resolution, this rule will fail
> except for domain names for which your name server is
> authoritative; likewise for "more lines with subnets".
>
Good analysis.
More generally,
1) isInNet() or any other function which causes constant DNS lookups is
bad from a DNS infrastructure point of view, and can run into caching
complications
2) any form of access control which involves turning off recursion for
particular clients is iffy, since stub resolvers don't react
consistently to unexpected lookup results such as referrals. It is
generally better to give a definitive REFUSED response, in order to make
one's intent clear. In BIND terms, that would be "allow-query" rather
than "allow-recursion".
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
AW: Disabling recursion causes browser hangs on clients with auto proxy config
Thank you for your reply.
> the browser apparently needs to resolve the IP before itdesides whether to
> use proxy or not. It may be a problem of the .pac file.
I have also suspected the pac file some time ago. We have tried
to use !(isResolvable(host)) to try and make the browser give up
faster, with mixed results. In general this made things a little
faster but we still saw between 2 and 12 tries before the browser
gave up trying to resolve. This was still very noticable on sites
with lots of external content.
> check the .pac content. If you use IP's in it, they are probably going to
> get resolved from given hostname.
I'm sorry but I don't quite understand what you mean. Could you
please elaborate this on the basis of this excerpt from our pac
file?
function FindProxyForURL(url, host)
{
var proxy1 = "PROXY 192.168.240.29:8080";
var proxy2 = "PROXY 172.16.1.30:8080";
if ( dnsDomainIs(host, ".intern")
|| shExpMatch(url, "*//localhost*")
|| shExpMatch(url, "*//127*")
|| isInNet(host, "192.168.1.0", "255.255.255.0")
// more lines with subnets
|| isPlainHostName(host)
)
{
return "DIRECT";
// Internal
}
else if ( shExpMatch (host, "int1.fujitsu.co.jp")
|| shExpMatch(host, "int2.fujitsu.co.jp")
// more lines with WAN domains
)
{
return proxy2;
// WAN
}
else
{
return proxy1;
// Internet
}
Basically what we do is return one proxy for WAN sites (depending on the
domain name), another proxy for normal internet traffic or DIRECT for local
sites.
Regards
Frank
- Originalnachricht -
Von: "Matus UHLAR - fantomas"
Gesendet: Mon, 25.1.2010 17:56
An: bind-users@lists.isc.org
Betreff: Re: Disabling recursion causes browser hangs on clients with auto
proxy config
On 25.01.10 17:14, Frank Stanek wrote:
> we want to set up a DNS server (bind-9.4.3-P3) for the internal LAN only.
> However for security reasons we need to only allow a few trusted systems
> to resolve external host names (ie names we are not authoritative for):
> * Trusted systems can resolve names from our zones _and_ external names
> * All other systems can only resolve names from our zones
> However when we use a pac file or automatic proxy detection, the browsers
> continually try to resolve the URL, receive "refused (recursion not
> available)",
the browser apparently needs to resolve the IP before itdesides whether to
use proxy or not. It may be a problem of the .pac file.
> Is there something fundamentally flawed with this configuration, ie is there
> a better way to do this? We have tried using views but essentially we only
> put recursion no; in one view and recursion yes; in the other which comes
> down to the same thing. I have also inquired on the Firefox mailing list
> about why the browsers behave this way (try to resolve forever when they
> shouldn't need to) but have not received a reply yet.
check the .pac content. If you use IP's in it, they are probably going to
get resolved from given hostname.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Disabling recursion causes browser hangs on clients with auto proxy config
Hello,
we want to set up a DNS server (bind-9.4.3-P3) for the internal LAN only.
However for security reasons we need to only allow a few trusted systems
to resolve external host names (ie names we are not authoritative for):
* Trusted systems can resolve names from our zones _and_ external names
* All other systems can only resolve names from our zones
The "untrusted" systems do not need to resolve external names since everything
is done via HTTP and SOCKS proxies.
We tried to do this by setting a forwarder and only enabling recursion for
an ACL that contains the trusted systems. This is what we came up with:
options {
directory "/var/lib/named";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
allow-query { 0/0; };
allow-recursion { acl_recurseallow; };
# allow-query-cache { none; }; # Is also allowed to acl_recurseallow by
default
# recursion no; # Is disabled for all but acl_recurseallow by default
forward only;
forwarders { 192.168.199.97; };
listen-on-v6 { none; };
pid-file "/var/lib/named/var/run/named/named.pid";
};
include "/etc/named.d/zones.conf";
acl acl_recurseallow { 127.0.0.1; 127.0.0.0/8; 192.168.1.1; 192.168.1.2;
192.168.1.3; };
logging {
# ...
};
Now there is a problem with web browsers on the "untrusted" systems. In
principle they could leave resolving to the HTTP proxy. When the proxy
server is configured manually into the browser, this is what they do and
everything works fine. I see no DNS queries in a packet capture.
However when we use a pac file or automatic proxy detection, the browsers
continually try to resolve the URL, receive "refused (recursion not available)",
then try again for up to many minutes depending on the browser and operating
system. This is what I get:
16:34:20.418896 IP 192.168.1.132.61298 > 192.168.1.1.53: 24052+ A?
www.google.de. (31)
16:34:20.418945 IP 192.168.1.1.53 > 192.168.1.132.61298: 24052 Refused- 0/0/0
(31)
16:34:22.693730 IP 192.168.1.132.60804 > 192.168.1.1.53: 54268+ A?
www.google.de. (31)
16:34:22.693914 IP 192.168.1.1.53 > 192.168.1.132.60804: 54268 Refused- 0/0/0
(31)
16:34:24.970093 IP 192.168.1.132.51107 > 192.168.1.1.53: 30500+ A?
www.google.de. (31)
16:34:24.970218 IP 192.168.1.1.53 > 192.168.1.132.51107: 30500 Refused- 0/0/0
(31)
16:34:27.249565 IP 192.168.1.132.50621 > 192.168.1.1.53: 12951+ A?
www.google.de. (31)
16:34:27.249764 IP 192.168.1.1.53 > 192.168.1.132.50621: 12951 Refused- 0/0/0
(31)
16:34:29.519069 IP 192.168.1.132.59523 > 192.168.1.1.53: 11653+ A?
www.google.de. (31)
16:34:29.519178 IP 192.168.1.1.53 > 192.168.1.132.59523: 11653 Refused- 0/0/0
(31)
The browser usually freezes completely while this is happening.
This continues forever until the browser finally gives up trying and lets
the proxy resolve. It then renders the page. We have tried Firefox, IE, Safari
and
some variant of Chrome and they all exhibit this behavior. We cannot find
a way to get rid of this problem.
Is there something fundamentally flawed with this configuration, ie is there
a better way to do this? We have tried using views but essentially we only
put recursion no; in one view and recursion yes; in the other which comes
down to the same thing. I have also inquired on the Firefox mailing list
about why the browsers behave this way (try to resolve forever when they
shouldn't need to) but have not received a reply yet.
I'd be glad for any insights.
Regards
Frank
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
