Re: Random nx name queries, anyone see this before?
ponga2...@gmail.com wrote on 15 Dec 2008 16:34: > I'd be very interested in what others find. I do have an update and > correction to my original post: > > The format is 9chars.8chars - as an example: > qjnqrtfun.wxsifmgj > Sometimes a colon appears, so the char list seems to be [a-z:] > Also, I was wrong about the FQDN - they do appear in named/bind logs - > so whatever app it is, the suffix search order is being used. My > apologies for the incorrect info the first time. > > Thre are a couple clients that do this - so thanks for the tip AlanC, > I will look for a pattern. Other than that, I'm stumped. Thanks for > any hints provided!! Is it possible that a bot net tries to connect? http://www.heise-online.co.uk/security/Botnet-rises-again--/news/112118 I don't want to make a panic, it's an idea only... -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MIME garbage in comp.protocols.dns.bind
In message <_aednq2trrolj9runz2dnuvz_tlin...@posted.hiwaay2>, Chris Adams write s: > Once upon a time, Mark Andrews said: > > I've raised a ticket with our ops people. > > While you are at it, could you see about fixing the Usenet threading? > It appears messages from the mail-to-news gateway get the Message-ID: > changed (often a bad idea) BUT the gateway doesn't update the > References: header at the same time. > > Any time the Message-ID header is changed, the gateway should keep a > list of old->new Message-IDs. On future posts, the References header > should be split and any known old Message-IDs should be changed to the > new Message-IDs. > > Alternately, don't change Message-IDs in the first place. Raised second ticket. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Random nx name queries, anyone see this before?
I'd be very interested in what others find. I do have an update and correction to my original post: The format is 9chars.8chars - as an example: qjnqrtfun.wxsifmgj Sometimes a colon appears, so the char list seems to be [a-z:] Also, I was wrong about the FQDN - they do appear in named/bind logs - so whatever app it is, the suffix search order is being used. My apologies for the incorrect info the first time. Thre are a couple clients that do this - so thanks for the tip AlanC, I will look for a pattern. Other than that, I'm stumped. Thanks for any hints provided!! ponga On Dec 15, 3:05 pm, Alan Clegg wrote: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --===8205490644561799063== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="enigFED1ACD7ADB6EFE6DBD2651F" > > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --enigFED1ACD7ADB6EFE6DBD2651F > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > ponga2...@gmail.com wrote: > > I'm seeing name queries from a couple clients on the network that > > occur around every two minutes - the queries are evidently random and > > are looking for A IN records of this form, as an example: > >=20 > > ungzbvyf.lzghmccim > >=20 > > They always look like this, 8 lowercase chars, dot, then 9 lowercase > > chars - never an FQDN. > > I can't find what this might be - has anyone seen this before or have > > any ideas? > > I've seen this and told a couple of people, but nobody has really shown > interest. > > In addition to the regular format that you see, I've also picked up a > pattern when you start seeing the queries from multiple sources... > > I'll be more than happy to start collecting data again if anyone has > interest. > > AlanC > > --enigFED1ACD7ADB6EFE6DBD2651F > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAklG1K4ACgkQcKpYUrUDCYfXbACgqRz5Fun88QI4Vd5cT+HkDfoM > 4vYAnAkWYFdminMBqCzD/bIuPZ58zqA3 > =eO8g > -END PGP SIGNATURE- > > --enigFED1ACD7ADB6EFE6DBD2651F-- > > --===8205490644561799063== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > bind-users mailing list > bind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users > --===8205490644561799063==-- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MIME garbage in comp.protocols.dns.bind
Once upon a time, Mark Andrews said: > I've raised a ticket with our ops people. While you are at it, could you see about fixing the Usenet threading? It appears messages from the mail-to-news gateway get the Message-ID: changed (often a bad idea) BUT the gateway doesn't update the References: header at the same time. Any time the Message-ID header is changed, the gateway should keep a list of old->new Message-IDs. On future posts, the References header should be split and any known old Message-IDs should be changed to the new Message-IDs. Alternately, don't change Message-IDs in the first place. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stuck glue records in the GTLD servers??
Thanks for the tip. I've asked those with the proper authority to verify the registrar's records. I must admit that I find it unusual that this needs to be done. In my experience, the glue records automatically change when a domain's name servers are altered. However, I have never worked with this particular registrar before, so perhaps they do things differently. Regardless, thanks again. :) -- Milo Hyson Chief Scientist CyberLife Labs On Dec 15, 2008, at 16:05, Mark Andrews wrote: You need to contact the registar for netdentalcare.com and update the HOST record for ns.netdentalcare.com to have the new address record. This changes what GLUE is published in the COM zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stuck glue records in the GTLD servers??
You need to contact the registar for netdentalcare.com and update the HOST record for ns.netdentalcare.com to have the new address record. This changes what GLUE is published in the COM zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND Windows?
In message <029c7576bb4b4f1480bf8cf9d125a...@nc4010>, "Jukka Pakkanen" writes: > Sorry I've lost track of the different versions, which works in Windows and > which don't. > > So... what is the latest version, working in W2K3? See the "immediate downloads" on https://www.isc.org/software/bind. > And Is W2K still abandoned? Until Microsoft back port the missing functionality, yes. > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stuck glue records in the GTLD servers??
They've been changed for days: > ns.netdentalcare.com. Server: ns1.idaserver.com. Address:207.178.132.75#53 QUESTIONS: ns.netdentalcare.com, type = A, class = IN ANSWERS: -> ns.netdentalcare.com internet address = 207.178.132.75 AUTHORITY RECORDS: ADDITIONAL RECORDS: Name: ns.netdentalcare.com Address: 207.178.132.75 -- Milo Hyson Chief Scientist CyberLife Labs On Dec 15, 2008, at 15:43, Mark Andrews wrote: You need to update the HOST records for the nameservers. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND Windows?
> Sorry I've lost track of the different versions, which works in Windows and > which don't. > > So... what is the latest version, working in W2K3? And Is W2K still > abandoned? 9.3.6, 9.4.3, or 9.5.0-P2-W2 (which is soon to be supplanted by 9.5.1, currently in release-candidate status, as is 9.6.0). And yes, win2k is still unsupported. -- Evan Hunt -- evan_h...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stuck glue records in the GTLD servers??
Absolutely. Note the listed authoritative servers in the snippet I included. Those are the new ones. -- Milo Hyson Chief Scientist CyberLife Labs On Dec 15, 2008, at 15:40, David Ford wrote: did you update the ns records with your registrar? Milo Hyson wrote: I'm seeing what looks like a stuck glue record in the GTLD servers and I'm hoping I've just overlooked something simple. There are several domains which list the following as their nameservers: ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stats collection script for BIND 9.5 (and greater?)
At Mon, 15 Dec 2008 17:18:21 +0100, Alexander Gall wrote: > > http://members.iinet.com.au/~pyard...@ihug.com.au/#%5B%5BBIND%209.5%20DNS%20Stats%5D%5D > > This looks useful, thanks. However, ISC has chosen to change some > tags in 9.6.0rc1 (nsstats -> nsstat, zonestats -> zonestat, resstats -> > resstat). Unfortunately, they didn't bump the version of their XML > schema (it's still reported as 1.0 in the tag), so it's hard to > do right. I hope this is going to be fixed in the final 9.6.0 > release. 9.6.0rc2 (and 9.5.1rc2) will soon be released (and I don't think we can make a change to these versions unless it's a fatal bug). So, if this is a crucial fix to be incorporated in the final release we don't have much time. Just out of curiosity, how crucial do you think it is to bump the version? My understanding is that bumping the version will help if we keep supporting the first version for a reasonably long period, while chasing newer versions. Realistically, however, I suspect most users (especially those using advanced management tools like this script) will move to 9.5.1 (or 9.6.0) anyway, since 9.5.0 and its P1/P2 variants have other problems: vulnerability to the Kaminsky attack (in case of vanilla 9.5.0), performance issues due to file descriptor limitations, ACL crash/memory leak, cache memory management bug, etc. *If* we could assume no one realistically continues to stick to 9.5.0, wouldn't it be simpler just to drop the old format and migrate to the new one? (I understand the migration itself is a pain, and I apologize for the inconvenience. As I said in a response to a different thread, we'll try to avoid happening in future releases). --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC BIND Windows?
Sorry I've lost track of the different versions, which works in Windows and which don't. So... what is the latest version, working in W2K3? And Is W2K still abandoned? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stuck glue records in the GTLD servers??
In message , Milo Hyson writes: > I'm seeing what looks like a stuck glue record in the GTLD servers and > I'm hoping I've just overlooked something simple. There are several > domains which list the following as their nameservers: > > ns.netdentalcare.com > ns2.netdentalcare.com > > The zone for these (netdentalcare.com) was moved to a new ISP several > days ago. The new servers are properly resolving the names and the old > servers no longer are. Unfortunately, nobody can seem to resolve these > names unless they directly ask the new servers. Upon investigation, I > discovered the GTLD servers seem to be holding onto a stale glue > record for the zone's prior server: > > > ns.netdentalcare.com. > Server: h.gtld-servers.net. > Address: 192.54.112.30#53 > > > QUESTIONS: > ns.netdentalcare.com, type = A, class = IN > ANSWERS: > -> ns.netdentalcare.com > internet address = 64.84.39.197 > AUTHORITY RECORDS: > -> netdentalcare.com > nameserver = ns1.idaserver.com. > -> netdentalcare.com > nameserver = ns2.idaserver.com. > ADDITIONAL RECORDS: > -> ns1.idaserver.com > internet address = 207.178.132.75 > -> ns2.idaserver.com > internet address = 207.178.132.76 > > Non-authoritative answer: > Name: ns.netdentalcare.com > Address: 64.84.39.197 > > I assumed this would have timed-out after two-days, but it hasn't. > Nobody is resolving the name to that address anymore. I checked the > old zone file to ensure it didn't have a long TTL and it didn't > (86,400 seconds). > > If anybody has any insight into this issue it would be greatly > appreciated. You need to update the HOST records for the nameservers. > -- > Milo Hyson > Chief Scientist > CyberLife Labs > > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stuck glue records in the GTLD servers??
did you update the ns records with your registrar? Milo Hyson wrote: > I'm seeing what looks like a stuck glue record in the GTLD servers and > I'm hoping I've just overlooked something simple. There are several > domains which list the following as their nameservers: ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Stuck glue records in the GTLD servers??
I'm seeing what looks like a stuck glue record in the GTLD servers and I'm hoping I've just overlooked something simple. There are several domains which list the following as their nameservers: ns.netdentalcare.com ns2.netdentalcare.com The zone for these (netdentalcare.com) was moved to a new ISP several days ago. The new servers are properly resolving the names and the old servers no longer are. Unfortunately, nobody can seem to resolve these names unless they directly ask the new servers. Upon investigation, I discovered the GTLD servers seem to be holding onto a stale glue record for the zone's prior server: > ns.netdentalcare.com. Server: h.gtld-servers.net. Address:192.54.112.30#53 QUESTIONS: ns.netdentalcare.com, type = A, class = IN ANSWERS: -> ns.netdentalcare.com internet address = 64.84.39.197 AUTHORITY RECORDS: -> netdentalcare.com nameserver = ns1.idaserver.com. -> netdentalcare.com nameserver = ns2.idaserver.com. ADDITIONAL RECORDS: -> ns1.idaserver.com internet address = 207.178.132.75 -> ns2.idaserver.com internet address = 207.178.132.76 Non-authoritative answer: Name: ns.netdentalcare.com Address: 64.84.39.197 I assumed this would have timed-out after two-days, but it hasn't. Nobody is resolving the name to that address anymore. I checked the old zone file to ensure it didn't have a long TTL and it didn't (86,400 seconds). If anybody has any insight into this issue it would be greatly appreciated. -- Milo Hyson Chief Scientist CyberLife Labs ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.0b1 xml stats - changes?
At Thu, 20 Nov 2008 19:12:49 -0800,
"D. Stussy" wrote:
> Using the same .xls page to format as I did with 9.5.1b1, some of the
> sections don't have data. Something was altered between these two
> versions, but the release notes say NOTHING about any change to the
> statistics web server feature.
>
> I found these affected statistics:
> - server/nsstats/*- renamed as /nsstat/
> - server/zonestats/* - renamed as /zonestat/
> - [views/view]/resstats/* - renamed as /resstat/
>
> Not everyone uses or necessarily wants to use the "bind9.xsl" file that
> comes with BIND as the display formatter.
>
> Please, if the XML data changes in the future, it should be documented in
> the release notes.
You're absolutely right, and I apologize for your inconvenience.
Moreover, we understand it's very important to keep backward
compatibility for users of this type of published interfaces. So,
we'll try to avoid introducing incompatible changes as much as
possible in future versions in the first place.
Regarding this change, it's a result of this fix:
2388. [bug] Avoid using tables for layout purposes in
statistics XSL [RT #18159].
as indicated by the change category ('[bug]'), we thought fixing this
issue was not just a style change, and it seemed to be the cleanest
way to change the data structure as part of the fix. Ideally we
should have done such an incompatible try-and-error fix in a beta
version phase before a point-0 release, but in reality not many people
try to use pre-0 beta versions to identify problems like this one.
Again, we'll try to avoid incompatible changes as much as possible in
future versions of 9.5 (and probably in other 9.x versions). It would
be highly appreciated if you could point it out in a beta or RC phase
in case we accidentally introduce incompatibility.
Thanks,
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Random nx name queries, anyone see this before?
ponga2...@gmail.com wrote: > I'm seeing name queries from a couple clients on the network that > occur around every two minutes - the queries are evidently random and > are looking for A IN records of this form, as an example: > > ungzbvyf.lzghmccim > > They always look like this, 8 lowercase chars, dot, then 9 lowercase > chars - never an FQDN. > I can't find what this might be - has anyone seen this before or have > any ideas? I've seen this and told a couple of people, but nobody has really shown interest. In addition to the regular format that you see, I've also picked up a pattern when you start seeing the queries from multiple sources... I'll be more than happy to start collecting data again if anyone has interest. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Random nx name queries, anyone see this before?
I'm seeing name queries from a couple clients on the network that occur around every two minutes - the queries are evidently random and are looking for A IN records of this form, as an example: ungzbvyf.lzghmccim They always look like this, 8 lowercase chars, dot, then 9 lowercase chars - never an FQDN. I can't find what this might be - has anyone seen this before or have any ideas? TIA, ponga ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with case changing from master on BIND 9 to slave on BIND 8
Mark Andrews writes: > > > > In message <9fc47420fb263da9eda170166fd4d...@cornell.edu>, John Wobus writes: > > Some years ago, I had that issue. The problem was that the > > zone transfer compression mechanism could change the case > > of individual names. This was fixed in some release of bind > > (after 9.2.1, if I remember correctly), and bind release notes > > would pinpoint the exact version with the change. > > You will need BIND 9.4.0 or later for the master. > > 1811. [func] Preserve the case of domain names in rdata during > zone transfers. [RT #13547] > > Or you can specify many-answers as the transfer format > on the master. Correction one-answer as the transfer format but there is still a small risk if the a compression pointer can be found in the owner name of the record with differing case, > > The problem was that the compression mechanism would compress > > a.example.COM and b.example.com by using a pointer to a single string, > > in one specific instance, "example.COM". When uncompressed > > at at the secondary end, the names came out as a.example.COM and > > b.example.COM. > > > > John Wobus > > Cornell University CIT > > > > > > On Dec 15, 2008, at 10:51 AM, Ben Croswell wrote: > > > > > I reaching out to the list on what appears to be a very odd issue that = > > > > > happened over the weekend. > > > We had an issue where some internal domains had the TLD capitalized = > > > > > after the zone transfer. > > > i.e. foo.bar.com on the master became foo.bar.COM on the slave. > > > I know that DNS is case insensitive but it caused an issue with apps = > > > > > that were misbehaving. > > > > > > The master is BIND 9.2.1 and the slaves in question are 8.2.3. > > > The master zone has everything lower case, and BIND 9 slaves show them = > > > > > as lower case as well. > > > A manual zone xfer on the 8.2.3 boxes to a different local directory = > > > > > than the actual named directory shows .COM. > > > > > > I was wondering if anyone had experienced an issue like this. > > > > > > And I understand both of those version are ancient and need to be = > > > > > removed=A0 from the environment. > > > > > > -- = > > > > > -Ben Croswell > > > ___ > > > 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 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with case changing from master on BIND 9 to slave on BIND 8
In message <9fc47420fb263da9eda170166fd4d...@cornell.edu>, John Wobus writes: > Some years ago, I had that issue. The problem was that the > zone transfer compression mechanism could change the case > of individual names. This was fixed in some release of bind > (after 9.2.1, if I remember correctly), and bind release notes > would pinpoint the exact version with the change. You will need BIND 9.4.0 or later for the master. 1811. [func] Preserve the case of domain names in rdata during zone transfers. [RT #13547] Or you can specify many-answers as the transfer format on the master. > The problem was that the compression mechanism would compress > a.example.COM and b.example.com by using a pointer to a single string, > in one specific instance, "example.COM". When uncompressed > at at the secondary end, the names came out as a.example.COM and > b.example.COM. > > John Wobus > Cornell University CIT > > > On Dec 15, 2008, at 10:51 AM, Ben Croswell wrote: > > > I reaching out to the list on what appears to be a very odd issue that = > > > happened over the weekend. > > We had an issue where some internal domains had the TLD capitalized = > > > after the zone transfer. > > i.e. foo.bar.com on the master became foo.bar.COM on the slave. > > I know that DNS is case insensitive but it caused an issue with apps = > > > that were misbehaving. > > > > The master is BIND 9.2.1 and the slaves in question are 8.2.3. > > The master zone has everything lower case, and BIND 9 slaves show them = > > > as lower case as well. > > A manual zone xfer on the 8.2.3 boxes to a different local directory = > > > than the actual named directory shows .COM. > > > > I was wondering if anyone had experienced an issue like this. > > > > And I understand both of those version are ancient and need to be = > > > removed=A0 from the environment. > > > > -- = > > > -Ben Croswell > > ___ > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MIME garbage in comp.protocols.dns.bind
In message , Sam Wilson wri tes: > In article , > Chris Buxton wrote: > > > On Dec 11, 2008, at 10:57 PM, Barry Margolin wrote: > > > The old mail-to-news gateway either got this right or > > > extracted the plain text alternative before forwarding. > > > > The old mail server stripped messages down to their plaintext values. > > The new one does not - it allows both formatted text and attachments. > > This is no doubt the change that's causing this problem with usenet. > > But it's doing it wrong - it's removing some MIME headers that it > shouldn't. (I will defer to other people if there is a mismatch in what > is acceptable in MIME headers on Usenet, but the old one worked and the > new one creates unreadable news postings.) > > Sam > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users I've raised a ticket with our ops people. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 50 million records under one domain using Bind
Out of curiosity, if one zone is to hold 50 million records, what would they all be for? I can't even imagine blogspot or godaddy being in that league. Perhaps with this many records just using a wldcard would be simpler? Then again maybe this is a new tld, or old one being consolidated? -- Scott Iphone says hello. On Dec 15, 2008, at 11:37 AM, JINMEI Tatuya / 神明達哉 @isc.org> wrote: At Sat, 13 Dec 2008 17:09:57 +0530, "Vinay Y S" wrote: I am studying the scalability and performance characteristics of different DNS servers. Goal is to find the best suitable server to host a single domain with 50 million records. I am planning to install Fedora 10 x86_64 on a 32GB RAM machine and use the Bind that comes with it for this experiment. If you have any suggestions or comments regarding how to accomplish this with Bind, it would be greatly helpful. Specifically, I would like to know what build or config options I would have to tweak to make it work best for this scale. If you plan to use a plain zone file for the 50 million records, rather than using a separate backend database, you may want to precompile your zone file by named-compilezone. It will make load time twice as short as it is with the plain text format. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ 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: 50 million records under one domain using Bind
At Sat, 13 Dec 2008 17:09:57 +0530, "Vinay Y S" wrote: > I am studying the scalability and performance characteristics of > different DNS servers. Goal is to find the best suitable server to > host a single domain with 50 million records. I am planning to install > Fedora 10 x86_64 on a 32GB RAM machine and use the Bind that comes > with it for this experiment. > > If you have any suggestions or comments regarding how to accomplish > this with Bind, it would be greatly helpful. > > Specifically, I would like to know what build or config options I > would have to tweak to make it work best for this scale. If you plan to use a plain zone file for the 50 million records, rather than using a separate backend database, you may want to precompile your zone file by named-compilezone. It will make load time twice as short as it is with the plain text format. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with case changing from master on BIND 9 to slave on BIND 8
Some years ago, I had that issue. The problem was that the zone transfer compression mechanism could change the case of individual names. This was fixed in some release of bind (after 9.2.1, if I remember correctly), and bind release notes would pinpoint the exact version with the change. The problem was that the compression mechanism would compress a.example.COM and b.example.com by using a pointer to a single string, in one specific instance, "example.COM". When uncompressed at at the secondary end, the names came out as a.example.COM and b.example.COM. John Wobus Cornell University CIT On Dec 15, 2008, at 10:51 AM, Ben Croswell wrote: I reaching out to the list on what appears to be a very odd issue that happened over the weekend. We had an issue where some internal domains had the TLD capitalized after the zone transfer. i.e. foo.bar.com on the master became foo.bar.COM on the slave. I know that DNS is case insensitive but it caused an issue with apps that were misbehaving. The master is BIND 9.2.1 and the slaves in question are 8.2.3. The master zone has everything lower case, and BIND 9 slaves show them as lower case as well. A manual zone xfer on the 8.2.3 boxes to a different local directory than the actual named directory shows .COM. I was wondering if anyone had experienced an issue like this. And I understand both of those version are ancient and need to be removed from the environment. -- -Ben Croswell ___ 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: bind memory usage
In article , sch...@adi.com (Thomas Schulz) wrote: > In article , > =?UTF-8?B?TGVvbmFyZG8gUm9kcmlndWVzIE1hZ2FsaMOjZXM=?= > wrote: > >[base64 guff] > > > You know, the above is not very usefull. Can someone please fix the > newsgroup gateway. The content is below. I forward it only because it's actually concrete result that might be useful to someone. Sam I just test bind 9.5.0-P2 and 9.5.1-rc1 Bind 9.5.0-P2 allocate over 2Gb per 10 minutes of work. Bind 9.5.1 allocate 2Gb per 30 hours. 14.12.2008, 2:15, JINMEI Tatuya / <9E><98><8E><81><94> <93><89> <81>(): > At Sat, 13 Dec 2008 11:50:52 -0200, > Leonardo Rodrigues Magalhes wrote: > >>i'm trying to run bind 9.5.0-P2 on a very low memory system. >> It's a >> RouterBoard 450 with 32Mb RAM running OpenWRT. >> >> r...@sede:~# cat /proc/meminfo >> MemTotal:29920 kB >> >>the problem is that bind seems to consume a LOT of memory ... >> well, >> a lot for low memory devices, i never noticed that on machines with >> BS >> of RAM. > > [snip] > >>question is is there something i can do to low bind's memory >> usage and successfully run it on those very low embedded devices ??? > > Admittedly, BIND9 tends to require a lot of memory. I'm not sure if > it can reasonably function with a total system memory of 32MB. > > Some related points: > - if you enable threads, disable them. With the thread support BIND9 > will require even more memory. > - "max-cache-size 1048576" is a meaningless configuration: > Any positive values less than 2MB will be ignored reset > to 2MB. > (from ARM) > - 'rndc flush' doesn't release allocated system memory. It just > frees all cache entries within the BIND9 process, so it's not > surprising that you didn't see the memory footprint decrease after > the flush operation. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > ___ > 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: Stats collection script for BIND 9.5 (and greater?)
On Fri, 12 Dec 2008 17:12:21 +1100, Peter Yardley said: > I have written a script to collect data from the XML stats channel of a > Bind 9.5+ DNS server. It works with Cricket and should work with MRTG > and Cacti. > You can get it here... > http://members.iinet.com.au/~pyard...@ihug.com.au/ > in the projects section under 'Bind 9.5 DNS Stats', or this is the > direct link... > http://members.iinet.com.au/~pyard...@ihug.com.au/#%5B%5BBIND%209.5%20DNS%20Stats%5D%5D This looks useful, thanks. However, ISC has chosen to change some tags in 9.6.0rc1 (nsstats -> nsstat, zonestats -> zonestat, resstats -> resstat). Unfortunately, they didn't bump the version of their XML schema (it's still reported as 1.0 in the tag), so it's hard to do right. I hope this is going to be fixed in the final 9.6.0 release. -- Alex ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Issue with case changing from master on BIND 9 to slave on BIND 8
I reaching out to the list on what appears to be a very odd issue that happened over the weekend. We had an issue where some internal domains had the TLD capitalized after the zone transfer. i.e. foo.bar.com on the master became foo.bar.COM on the slave. I know that DNS is case insensitive but it caused an issue with apps that were misbehaving. The master is BIND 9.2.1 and the slaves in question are 8.2.3. The master zone has everything lower case, and BIND 9 slaves show them as lower case as well. A manual zone xfer on the 8.2.3 boxes to a different local directory than the actual named directory shows .COM. I was wondering if anyone had experienced an issue like this. And I understand both of those version are ancient and need to be removed from the environment. -- -Ben Croswell ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind memory usage
In article , =?UTF-8?B?TGVvbmFyZG8gUm9kcmlndWVzIE1hZ2FsaMOjZXM=?= wrote: >CgpQZXRlciBEYW1iaWVyIGVzY3JldmV1Ogo+IEkgY2FuIGNvbmZpcm0gYmluZCA5LjQgZG9lcyBy >dW4gb24gYW4gKElCTSwgbm90IEludGVsKSA0ODYtU0NMLzIgd2l0aCAxNiBNQi4KPiBUaGF0IGNw >dSBjYW4gYWRkcmVzcyBubyBtb3JlIHRoYW4gMTYgTUIuCj4KPiAkIGNhdCAvcHJvYy9tZW1pbmZv >Cj4gICAgICAgICB0b3RhbDogICAgdXNlZDogICAgZnJlZTogIHNoYXJlZDogYnVmZmVyczogIGNh >Y2hlZDoKPiBNZW06ICAxNDU0MDgwMCAxMDU5NjM1MiAgMzk0NDQ0OCAgMzE5NDg4MCAgMTAwMzUy >MCAgMzUxODQ2NAo+ICAgCgogICAgdmVyeSBnb29kIHRvIGtub3cgdGhhdCA5LjQgaXMgcnVubmlu >ZyBPSyBvbiBhIDE2TWIgbWFjaGluZSwgYSAKc2l0dWF0aW9uIGV2ZW4gd29yc3QgdGhhbiBtaW5l >LCB3aGljaCBpcyAzMk1iIDopICAuLi4uIGknbGwgdHJ5IHRvIAppbnN0YWxsIDkuNCB0aGlzIHdl >ZWsgaW5zdGVhZCBvZiA5LjUgYW5kIGNoZWNrIGlmIGl0IGhhcyBhIHNsb3dlciBtZW1vcnkgCmZv >b3RwcmludC4KCiAgICB0aGFua3MgZm9yIHRoZSB0aXAgISEhCgotLSAKCgoJQXRlbmNpb3NhbWVu >dGUgLyBTaW5jZXJpbHksCglMZW9uYXJkbyBSb2RyaWd1ZXMKCVNvbHV0dGkgVGVjbm9sb2dpYQoJ >aHR0cDovL3d3dy5zb2x1dHRpLmNvbS5icgoKCU1pbmhhIGFybWFkaWxoYSBkZSBTUEFNLCBOw4NP >IG1hbmRlbSBlbWFpbAoJZ2VydHJ1ZGVzQHNvbHV0dGkuY29tLmJyCglNeSBTUEFNVFJBUCwgZG8g >bm90IGVtYWlsIGl0CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f >X19fX19fXwpiaW5kLXVzZXJzIG1haWxpbmcgbGlzdApiaW5kLXVzZXJzQGxpc3RzLmlzYy5vcmcK >aHR0cHM6Ly9saXN0cy5pc2Mub3JnL21haWxtYW4vbGlzdGluZm8vYmluZC11c2Vycw== You know, the above is not very usefull. Can someone please fix the newsgroup gateway. -- Tom Schulz sch...@adi.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind memory usage
I just test bind 9.5.0-P2 and 9.5.1-rc1 Bind 9.5.0-P2 allocate over 2Gb per 10 minutes of work. Bind 9.5.1 allocate 2Gb per 30 hours. 14.12.2008, в 2:15, JINMEI Tatuya / 神明達哉 написал(а): At Sat, 13 Dec 2008 11:50:52 -0200, Leonardo Rodrigues Magalhães wrote: i'm trying to run bind 9.5.0-P2 on a very low memory system. It's a RouterBoard 450 with 32Mb RAM running OpenWRT. r...@sede:~# cat /proc/meminfo MemTotal:29920 kB the problem is that bind seems to consume a LOT of memory ... well, a lot for low memory devices, i never noticed that on machines with BS of RAM. [snip] question is is there something i can do to low bind's memory usage and successfully run it on those very low embedded devices ??? Admittedly, BIND9 tends to require a lot of memory. I'm not sure if it can reasonably function with a total system memory of 32MB. Some related points: - if you enable threads, disable them. With the thread support BIND9 will require even more memory. - "max-cache-size 1048576" is a meaningless configuration: Any positive values less than 2MB will be ignored reset to 2MB. (from ARM) - 'rndc flush' doesn't release allocated system memory. It just frees all cache entries within the BIND9 process, so it's not surprising that you didn't see the memory footprint decrease after the flush operation. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ 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: MIME garbage in comp.protocols.dns.bind
In article , Chris Buxton wrote: > On Dec 11, 2008, at 10:57 PM, Barry Margolin wrote: > > The old mail-to-news gateway either got this right or > > extracted the plain text alternative before forwarding. > > The old mail server stripped messages down to their plaintext values. > The new one does not - it allows both formatted text and attachments. > This is no doubt the change that's causing this problem with usenet. But it's doing it wrong - it's removing some MIME headers that it shouldn't. (I will defer to other people if there is a mismatch in what is acceptable in MIME headers on Usenet, but the old one worked and the new one creates unreadable news postings.) Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MIME garbage in comp.protocols.dns.bind
In article , sch...@adi.com (Thomas Schulz) wrote: > I was wondering what was going on. Some messages are just base64 and are > completely useless/unreadable. If you have mimencode you could try this: $ mimencode -u > /tmp/weird ; less /tmp/weird On Mac OS X and other systems with the right perl module this works (make sure there's no line break): $ perl -MMIME::Base64 -ne 'print decode_base64($_)' > /tmp/weird ; less /tmp/weird Run the command, copy and paste the text of the duff message and then ctrl-D it and, hey presto, a readable message. If you already have a /tmp/weird on your system then change the file name. Yes, I know you shouldn't have to... :-) Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
Thank's to JINMEI Tatuya for support.
I have over 40 views, defined in named.conf, max-memory for cache -
32Mb. Named daemon allocate over 2 Gb per 24 hours of work.
Have you any ideas how to limit memory usage?
Dmitry Rybin wrote:
> max-cache-size 64M;
> # /usr/bin/limits -v 1200M /usr/local/sbin/named-test -c
> /etc/namedb/named.conf
>
> Over 10 minutes of work and core dumped:
>
> (gdb) bt
> #0 0x0058c3fc in thr_kill ()
> #1 0x005c5a68 in abort ()
> #2 0x00597af7 in malloc ()
> #3 0x0056645a in isc_mem_createx2 (init_max_size=0, target_size=0,
> memalloc=0x564400 , memfree=0x563320
> , arg=0x0,
> ctxp=0xcb29b978, flags=Variable "flags" is not available.
> ) at mem.c:790
> #4 0x00566730 in isc_mem_create (init_max_size=Variable
> "init_max_size" is not available.
> ) at mem.c:859
> #5 0x004d83ae in dns_resolver_create (view=0xca46e800,
> taskmgr=0x80828000,
> ntasks=31, socketmgr=Variable "socketmgr" is not available.
> ) at resolver.c:6514
> #6 0x004ee860 in dns_view_createresolver (view=0xca46e800,
> taskmgr=0x80828000,
> ntasks=31, socketmgr=0x8082b000, timermgr=0x80829000, options=0,
> dispatchmgr=0x8083c000,
> dispatchv4=0x864c9000, dispatchv6=0x864c9800) at view.c:580
> #7 0x0041bba2 in configure_view (view=0xca46e800,
> config=0x80abb4c0,
> vconfig=0x8085ada8, mctx=0x8080d140, actx=0x7eff8860,
> need_hints=isc_boolean_true)
> at server.c:1290
> #8 0x00420f42 in load_configuration (filename=Variable
> "filename" is not available.
> ) at server.c:3285
> #9 0x00422095 in loadconfig (server=0x8082f000) at server.c:4121
> #10 0x00422426 in reload (server=0x8082f000) at server.c:4141
> #11 0x004225c2 in ns_server_reloadcommand (server=0x8082f000,
> args=Variable "args" is not available.
> ) at server.c:4334
> #12 0x00407682 in ns_control_docommand (message=Variable
> "message" is not available.
> ) at control.c:102
> #13 0x0040a8b7 in control_recvmessage (task=0x80839000,
> event=Variable "event" is not available.
> ) at controlconf.c:456
> #14 0x0057052c in run (uap=Variable "uap" is not available.
> ) at task.c:862
> #15 0x005868a7 in thread_start ()
> #16 0x in ?? ()
> Cannot access memory at address 0x7eff9000
>
>
>
> JINMEI Tatuya / 神明達哉 wrote:
>
>> At Wed, 10 Dec 2008 15:50:22 +0300,
>> Dmitry Rybin wrote:
>>
>>> JINMEI Tatuya / 神明達哉 wrote:
>>>
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin wrote:
> I test patch, add to bind95/Makefile
> .if (${ARCH} == "amd64")
> ARCH= x86_64
> .endif
>
Future versions of BIND9 will support amd64 in its configure script to
workaround the FreeBSD port for amd64.
Regarding the memory leak, I believe it's already solved in 9.5.1rc1
(even with threads and without atomic).
>>> I just make port bind 9.5.1rc1. It has same problem with memory leak.
>>> It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
>>>
>> Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
>> port) so that we can separate FreeBSD-port specific issue and BIND9
>> specific leak?
>>
>> Second, what if you stop named by 'rndc stop'? If there's memory leak
>> in BIND9, it normally detects it during a cleanup process and
>> indicates the bug by aborting (core dumping) itself.
>>
>> If it doesn't cause an abort, please then try the diagnosing I
>> suggested before:
>> http://marc.info/?l=bind-users&m=121811979629090&w=2
>>
>> To summarize it:
>>
>> 1. create a symbolic link from "/etc/malloc.conf" to "X":
>># ln -s X /etc/malloc.conf
>> 2. - start named with a moderate limitation of virtual memory size, e.g.
>># /usr/bin/limits -v 384m $path_to_named/named
>> (note that "384m" should be reasonably large compared with
>> max-cache-size. I'd suggest setting max-cache-size to 128M and
>> setting 'limits -v' to 512m).
>> 3. Then the named process will eventually abort itself with a core dump
>>due to malloc failure. Please show us the stack trace at that point.
>>Hopefully it will reveal the malloc call that keeps consuming memory.
>>
>> In fact, I myself successfully identified one leak in 9.5.0-P2 with
>> FreeBSD port this way.
>>
>> ---
>> JINMEI, Tatuya
>> Internet Systems Consortium, Inc.
>>
>
> ___
> 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: Where is the open recursion test?
> Date: Mon, 15 Dec 2008 11:52:01 +0100 > From: Peter Dambier > To: bind-users@lists.isc.org > Subject: Re: Where is the open recursion test? > X-FuHaFi: 0.62 > > just try > > dig -t any peter-dambier.de @ > > If it tells you something about denic it is not recursive. > If you get the complete answer it is very likely recursive. > > Something internal could have triggered the query but only > if your server is in /etc/resolv.conf. Peter: Thanks! I ran that and got a full response back. Then I remembered that you cannot check on recursiveness from a trusted interface... I went to my ISP (alt email provider) and ran well% dig -t any peter-dambier.de @64.139.55.108 ; <<>> DiG 2.0 <<>> -t peter-dambier.de @64.139.55.108 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_send to server 64.139.55.108: Connection timed out "Connection timed out" is expected. Means that the ACLs are working. Just to make sure, lets test for something that CAN be resolved: well% dig metis.hicks-net.net @64.139.55.108 ; <<>> DiG 2.0 <<>> metis.hicks-net.net @64.139.55.108 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; Ques: 1, Ans: 1, Auth: 3, Addit: 1 ;; QUESTIONS: ;; metis.hicks-net.net, type = A, class = IN ;; ANSWERS: metis.hicks-net.net.3600A 64.139.55.108 ;; AUTHORITY RECORDS: hicks-net.net. 3600NS ns1.xname.org. hicks-net.net. 3600NS ns0.xname.org. hicks-net.net. 3600NS ns.hicks-net.net. ;; ADDITIONAL RECORDS: ns.hicks-net.net. 3600A 64.139.55.108 ;; FROM: well to SERVER: 64.139.55.108 ;; WHEN: Mon Dec 15 02:57:50 2008 ;; MSG SIZE sent: 37 rcvd: 131 well% That worked also. (I got the expected results... Yay!) Again, thanks! Regards, Gregory Hicks > > Kind regards > Peter > > > Gregory Hicks wrote: > >> Date: Mon, 15 Dec 2008 06:44:18 -0200 > >> From: Leonardo Rodrigues Magalhães > >> > >> Gregory Hicks escreveu: > >>> Greetings: > >>> > >>> Seeing in my named.log entries for "too many timeouts resolving > >>> ''..." makes me wonder if my server is an > >>> open recursive server. > >>> > >>> Where is the test please for open recursion so I can check? > >> http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl > > > > Thanks! But I tried that about 6 hours earlier today. It said address > > 64.139.55.108 had status "untested". It also said that if I wanted my > > address retested, make a TCP connection to > > dns-surveyor.measurement-factory.com port 999 (e.g., with telnet) from > > the address to be tested. I did THAT also. So far, nothing. > > > > Any other ideas? [...] - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Where is the open recursion test?
just try dig -t any peter-dambier.de @ If it tells you something about denic it is not recursive. If you get the complete answer it is very likely recursive. Something internal could have triggered the query but only if your server is in /etc/resolv.conf. Kind regards Peter Gregory Hicks wrote: >> Date: Mon, 15 Dec 2008 06:44:18 -0200 >> From: Leonardo Rodrigues Magalhães >> >> Gregory Hicks escreveu: >>> Greetings: >>> >>> Seeing in my named.log entries for "too many timeouts resolving >>> ''..." makes me wonder if my server is an >>> open recursive server. >>> >>> Where is the test please for open recursion so I can check? >> http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl > > Thanks! But I tried that about 6 hours earlier today. It said address > 64.139.55.108 had status "untested". It also said that if I wanted my > address retested, make a TCP connection to > dns-surveyor.measurement-factory.com port 999 (e.g., with telnet) from > the address to be tested. I did THAT also. So far, nothing. > > Any other ideas? > > - > Gregory Hicks | Principal Systems Engineer > | Direct: 408.569.7928 > > People sleep peaceably in their beds at night only because rough men > stand ready to do violence on their behalf -- George Orwell > > The price of freedom is eternal vigilance. -- Thomas Jefferson > > "The best we can hope for concerning the people at large is that they > be properly armed." --Alexander Hamilton > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Where is the open recursion test?
> Date: Mon, 15 Dec 2008 06:44:18 -0200 > From: Leonardo Rodrigues Magalhães > > Gregory Hicks escreveu: > > Greetings: > > > > Seeing in my named.log entries for "too many timeouts resolving > > ''..." makes me wonder if my server is an > > open recursive server. > > > > Where is the test please for open recursion so I can check? > > http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl Thanks! But I tried that about 6 hours earlier today. It said address 64.139.55.108 had status "untested". It also said that if I wanted my address retested, make a TCP connection to dns-surveyor.measurement-factory.com port 999 (e.g., with telnet) from the address to be tested. I did THAT also. So far, nothing. Any other ideas? - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Where is the open recursion test?
Gregory Hicks escreveu: Greetings: Seeing in my named.log entries for "too many timeouts resolving ''..." makes me wonder if my server is an open recursive server. Where is the test please for open recursion so I can check? http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
