Re: How to enable EDNS for an authoritative name server?
On Thu, Jan 22, 2015 at 03:25:38PM +0800, Jackie Lui wrote: > I have installed bind 9.10.1 and enable GeoIP features. This works fine > except the EDNS feature. > > When I dig Google DNS server with +subnet parameter, Google DNS server can > respond the CLIENT-SUBNET value. However, when I dig my DNS server, it > can't show the CLIENT-SUBNET value. It seems that my server cannot > handle ECS query? BIND 9.10 only has support for the client-subnet option in dig, not in the name server. Authoritative server support for client-subnet will be in BIND 9.11. You can try it now by cloning the git repository at source.isc.org, if you like (I'd be happy to have your feedback on it). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
How to enable EDNS for an authoritative name server?
I have installed bind 9.10.1 and enable GeoIP features. This works fine except the EDNS feature. When I dig Google DNS server with +subnet parameter, Google DNS server can respond the CLIENT-SUBNET value. However, when I dig my DNS server, it can't show the CLIENT-SUBNET value. It seems that my server cannot handle ECS query? Is there any step I missed to enable EDNS feature? 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: long lived tcp
In message <00b101d035f0$ff0d76c0$fd286440$@aliyun.com>, "RunxiaWan" writes: > > Hi everyone, > I am writing to ask if bind support long lived tcp connection which can be > reused by multiple transactions? Named has always supported multiple queries over TCP sockets. Mark -- 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
long lived tcp
Hi everyone, I am writing to ask if bind support long lived tcp connection which can be reused by multiple transactions? --- Runxia Wan(Brian) Research Engineer BII Lab Beijing Internet Institute(BII) rx...@biigroup.cn ___ 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: Automatic flushing of the jnl files
Bob, Some date and record number details from one of my systems, with 'max-journal-size: 100m'. Yes, I've changed the zone names.. ;) NOTE: Add/Del numbers show total / non-dnssec-or-soa related update numbers. 'zone1' is a monitoring test zone that has sub-zone delegation changes a few times a minute: dnssec signed: Yes, NSEC3 with Optout zone1 size: 127k one1.jnl size: 63M date now: Wed Jan 21 22:12:15 UTC 2015 oldest jnl soa: Tue Jan 20 20:42:29 UTC 2015 total records: 1,233 no. SOA del's: 52,964 no. del's: 236,556 / 79,716 no. add's: 236,604 / 79,713 'zone2' is a public delegation zone that changes as customers demand: dnssec signed: Yes, NSEC3 with Optout zone2 size: 176M zone2.jnl size: 100M date now: Wed Jan 21 22:15:15 UTC 2015 oldest jnl soa: Fri Dec 19 17:22:20 UTC 2014 total records: 5,917,482 no. SOA del's: 138,752 no. del's: 456,870 / 172,427 no. add's: 478,940 / 194,541 'zone3' is a public authoritative zone that rarely changes: dnssec signed: Yes, NSEC3 with Optout zone3 size: 1.6M zone3.jnl size: 69M date now: Wed Jan 21 22:27:53 UTC 2015 oldest jnl soa: Mon Oct 27 21:19:38 UTC 2014 total records: 6,984 no. SOA del's: 35,144 no. del's: 175,832 / 0 no. add's: 175,832 / 0 So the journal files can live for quite a while ;) Stuart > -Original Message- > From: bind-users-boun...@lists.isc.org [mailto:bind-users- > boun...@lists.isc.org] On Behalf Of Tony Finch > Sent: Thursday, 22 January 2015 6:34 AM > To: Bob Harold > Cc: bind-users@lists.isc.org > Subject: Re: Automatic flushing of the jnl files > > Yes, an IXFR is a series of deletes and adds, which both quote whole > records. If you re-sign a zone the IXFR can be nearly twice what an AXFR > would be! But in fact the factor of two in my patch comes from the journal > compaction logic, which halves the size of the journal. So my patch allows > the journal to oscillate between the size of the zone and twice that. > Smaller journals may mean you have to AXFR when IXFR would be better. > > If you use serial-update-method unixtime or date-based serial numbers then > you might be able to get the information you want from the journal. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at > > > On 21 Jan 2015, at 18:37, Bob Harold wrote: > > > > I like that solution. > > > > I assume that "twice the zone file size" is because half of the entries > are deletes? Do deletes get sent in IXFR? Or is it that typically half > of the journal entries are SOA records? > > > > I just took a peek at my journal files and I see one that is 100 times > the zone file size. I wish the entries had dates, even if just as a > comment - it would be a good log of changes, and I would be able to see > how far back in history the journal went. > > > ___ > 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: Automatic flushing of the jnl files
Yes, an IXFR is a series of deletes and adds, which both quote whole records. If you re-sign a zone the IXFR can be nearly twice what an AXFR would be! But in fact the factor of two in my patch comes from the journal compaction logic, which halves the size of the journal. So my patch allows the journal to oscillate between the size of the zone and twice that. Smaller journals may mean you have to AXFR when IXFR would be better. If you use serial-update-method unixtime or date-based serial numbers then you might be able to get the information you want from the journal. Tony. -- f.anthony.n.finchhttp://dotat.at > On 21 Jan 2015, at 18:37, Bob Harold wrote: > > I like that solution. > > I assume that "twice the zone file size" is because half of the entries are > deletes? Do deletes get sent in IXFR? Or is it that typically half of the > journal entries are SOA records? > > I just took a peek at my journal files and I see one that is 100 times the > zone file size. I wish the entries had dates, even if just as a comment - it > would be a good log of changes, and I would be able to see how far back in > history the journal went. > ___ 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: Automatic flushing of the jnl files
I like that solution. I assume that "twice the zone file size" is because half of the entries are deletes? Do deletes get sent in IXFR? Or is it that typically half of the journal entries are SOA records? I just took a peek at my journal files and I see one that is 100 times the zone file size. I wish the entries had dates, even if just as a comment - it would be a good log of changes, and I would be able to see how far back in history the journal went. -- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) rharo...@umich.edu 734-647-6524 desk On Wed, Jan 21, 2015 at 12:50 PM, Tony Finch wrote: > I got annoyed by having to manually tune max-journal-size so I had a hack > at the problem: > > https://git.csx.cam.ac.uk/x/ucs/ipreg/bind9.git/commitdiff/c8f083b797f9810f > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Viking: Southeast, veering south or southwest later, 4 or 5, increasing 6 > at > times. Moderate or rough. Wintry showers. 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: Automatic flushing of the jnl files
I got annoyed by having to manually tune max-journal-size so I had a hack at the problem: https://git.csx.cam.ac.uk/x/ucs/ipreg/bind9.git/commitdiff/c8f083b797f9810f Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking: Southeast, veering south or southwest later, 4 or 5, increasing 6 at times. Moderate or rough. Wintry showers. 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
Re: Automatic flushing of the jnl files
Oh, well that's good to know. :) -Christopher On 1/21/15, 12:18 PM, "Chris Thompson" wrote: >On Jan 21 2015, Howard, Christopher wrote: > >>The journal files get flushed to the zone file periodically, but old >>transactions don't get removed so the journal file will continue to grow >>forever. If you're like me and on virtual machines with limited hard >>disk >>capacity, you can limit the journal file size with the max-journal-size >>configuration statement. Just make sure that the size is large enough to >>hold all of the transactions between flushes (I believe that's around >>every 15 minutes). Otherwise, after a crash you would be missing >>records. > >I am fairly sure you are wrong on that last point. BIND will not flush >journal file entries that have not yet been committed to the master file, >even if they make the journal bigger than max-journal-size. If you specify >"max-journal-size 512;" you will find the journal gets emptied completely, >but only after the master file has been updated. (Of course, as Phil >Mayers >points out, this would cause downstream IXFRs to become AXFRs,) > >-- >Chris Thompson >Email: c...@cam.ac.uk > >___ >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: Automatic flushing of the jnl files
On Jan 21 2015, Howard, Christopher wrote: The journal files get flushed to the zone file periodically, but old transactions don't get removed so the journal file will continue to grow forever. If you're like me and on virtual machines with limited hard disk capacity, you can limit the journal file size with the max-journal-size configuration statement. Just make sure that the size is large enough to hold all of the transactions between flushes (I believe that's around every 15 minutes). Otherwise, after a crash you would be missing records. I am fairly sure you are wrong on that last point. BIND will not flush journal file entries that have not yet been committed to the master file, even if they make the journal bigger than max-journal-size. If you specify "max-journal-size 512;" you will find the journal gets emptied completely, but only after the master file has been updated. (Of course, as Phil Mayers points out, this would cause downstream IXFRs to become AXFRs,) -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Automatic flushing of the jnl files
The journal files get flushed to the zone file periodically, but old transactions don't get removed so the journal file will continue to grow forever. If you're like me and on virtual machines with limited hard disk capacity, you can limit the journal file size with the max-journal-size configuration statement. Just make sure that the size is large enough to hold all of the transactions between flushes (I believe that's around every 15 minutes). Otherwise, after a crash you would be missing records. -Christopher On 1/21/15, 11:46 AM, "Phil Mayers" wrote: >On 21/01/15 15:46, eric.berthiaume.exter...@banque-france.fr wrote: > >> So it it does seem to be rolling the changes but jnl files still >> persist. It¹s not terribly bothering but I would like to know if this >> is the normal behavior. > >It's normal. The .jnl files contain the data required to perform >incremental outbound zone transfers. >___ >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: Automatic flushing of the jnl files
On 21/01/15 15:46, eric.berthiaume.exter...@banque-france.fr wrote: So it it does seem to be rolling the changes but jnl files still persist. It’s not terribly bothering but I would like to know if this is the normal behavior. It's normal. The .jnl files contain the data required to perform incremental outbound zone transfers. ___ 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
Automatic flushing of the jnl files
Hello bind-users, Tried to find the info on my own but couldn’t get accurate understanding of jnl files flushing mechanism. Bind-9.10.0-02.P2 RHEL 5.7 Master DNS server, Chrooted env, receiving updates via nsupdate. Maybe I didn’t catch the memo but I thought the standard way bind handled the dynamic journal (.jnl) files was this way: All changes made to a zone using dynamic update are written to the zone's journal file. The server will periodically flush the complete contents of the updated zone to its zone file this happens approximately every 15 minutes. NOTE this is from zytrax.com dns documentation so I’m pretty sure this is not from bind 9.10 Doesn’t seem to be the case right now and I’m wondering if my server conf is to blame. I’m able to sync to flat files using rndc: rndc sync –clean That I see in my logs: named[3001]: received control channel command 'sync -clean' named[3001]: dumping all zones, removing journal files: success But the next day I’m seeing tons of jnl files again. From updates of course. I do have these journal messages in my logs: general: debug 1: zone XX.128.in-addr.arpa/IN: journal rollforward completed successfully: no journal general: debug 3: no journal file, but that's OK general: debug 1: zone XX.XX.10.in-addr.arpa/IN: journal rollforward completed successfully: no journal general: debug 3: no journal file, but that's OK general: debug 1: zone XX.XX.10.in-addr.arpa/IN: journal rollforward completed successfully: no journal general: debug 3: no journal file, but that's OK general: debug 1: zone XX.168.192.in-addr.arpa/IN: journal rollforward completed successfully: no journal So it it does seem to be rolling the changes but jnl files still persist. It’s not terribly bothering but I would like to know if this is the normal behavior. I do not have dnssec-enable of managed-keys-directory set in named.conf Thanks for your help. E. Berthiaume ** Ce courrier électronique, y compris les pièces jointes, est à l'attention exclusive des destinataires désignés et revêt un caractère confidentiel. Si vous recevez ce courrier électronique par erreur, merci d'en informer sans délai l'expéditeur et de supprimer son contenu et ses pièces jointes. Le contenu de ce courrier électronique ne pourrait engager la responsabilité de la Banque de France que s'il a été émis par une personne dûment habilitée agissant dans le strict cadre des fonctions auxquelles elle est employée et à des fins non étrangères à ses attributions. L'expéditeur de ce courrier électronique ne peut pas garantir la sécurité de l'acheminement par voie électronique et ne saurait dès lors encourir une quelconque responsabilité en cas d'altération de son contenu. ** This e-mail, attachments included, is intended solely for the addressees and should be considered as confidential. Should you receive this message by error, please notify the sender immediately and destroy this e-mail and its attachments. Banque de France cannot be considered as liable for the content of this message unless the sender has been duly authorized and has acted strictly in the course of his/her tasks as an employee. The sender of this e-mail cannot ensure the security of its electronic transmission and consequently will not be liable should its content be altered. ** ___ 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
