Re: [dns-operations] The Decline and Fall of BIND 10
Mark Andrews (marka) writes: In message CAMm+LwgwmFXmFsr0=JkMY=rHKNDuyC29h=12-vql3+ibvum...@mail.gmail.com , Phillip Hallam-Baker writes: What is the next edition of BIND going to be called then, 10 or 11? Well BIND 9.10.0 is already released and work has started on BIND 9.11.0. BIND 10 exists so that is taken. If we were to start a new re-write I would expect it would be BIND 11. It's a fitting release number. http://www.youtube.com/watch?v=4xgx4k83zzc http://www.youtube.com/watch?v=5FFRoYhTJQQ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] The Decline and Fall of BIND 10
On 15 May 2014, at 04:26, Paul Vixie p...@redbarn.org wrote: Wayne MacLaurin wrote: Bind 9.11 Can’t imagine we’ll see another attempt at a ground up rebuild anytime soon….. maybe not by ISC. but based on the success of BIND9, NSD, Knot, Unbound, Yadifa, and PowerDNS, i think we will see more implementations of DNS as time goes on. because, you guessed it, DNS is sexy. Agreed, the next big step in DNS implementations looks to be coming from sources other than ISC at this time. based on the fact that BIND 9.10 has a map file type that cuts startup time to de minimis or less even for large zones, in the same style long employed by NSD, The map file type is great (I still need to open a bug report with ISC about data corruption, but that is always expected from a .0 round, no biggy), however it is not the same as NSD does, at all. The map file type is basically a memory dump of BIND’s memory representation which, as you say, is totally awesome in terms of startup time but it is not the pre-compiled answer approach of NSD. i think it's safe to say that BIND9 did not need a total rewrite as much as i thought it did when i launched that project. Tend to agree, but for different reasons. Having been immersed in various DNS reports here at the RIPE Meeting it seems to me, as a consumer of DNS software/systems that Knot DNS is actually delivering each of the BIND 10 promises one by one, with wicked speed, the new Dynamic modules, hooks for processing, etc. It is totally awesome. BIND9 will continue to be the main staple for quite some time as it has been proven to work throughout its long history and as Mark and Evan now master the art of banging the metal into any shape they want but I am still worried that it is showing signs of metal fatigue, same as when we decided that we needed a real refresh. Pity that went so pear-shaped, though as Shane so clearly pointed out, there were very valuable lessons in the process. base diversity, and i do notice that some implementors want to work on a common management interface so they can configure their name service in a standard language or protocol, This is another good goal, particularly if we can see this be done in an incremental and modular way. Start with a few key operations that we all need and let there be vendor extensions for features that are specific to each of the servers. Trying to go to an all-encompassing solution hasn’t been working all that well so far. Joao ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] The Decline and Fall of BIND 10
If it is 9.11, it might be good number to make attack resilience the focus of that version (a good code audit, more robust error-condition response, evolution of RRL and related features, logging that doesn't kill you, etc) Joao On 15 May 2014, at 01:19, Phillip Hallam-Baker hal...@gmail.com wrote: What is the next edition of BIND going to be called then, 10 or 11? On Wed, May 14, 2014 at 2:25 PM, staticsafe m...@staticsafe.ca wrote: This might be of interest: https://ripe68.ripe.net/presentations/208-The_Decline_and_Fall_of_BIND_10.pdf -- staticsafe https://asininetech.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Website: http://hallambaker.com/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Weirdness with glue for old (gone) DNS servers
On 14 May 2014, at 23:18, Mark Andrews ma...@isc.org wrote: Then why does't the registry remove all the records below a delegation and any records that refer to them from the published zone when a delegation is removed? You're conflating a DNS zone (published from a database) from the registry (which is the database). You need to think in terms of (a) the data model and associated constraints in the database, which relates (perhaps indirectly, via a registrar) with the instructions received from a registrant, and (b) the scheme by which a zone is produced. For example, in (some? all?) gTLD registries there's a constraint on removing a domain object that has subordinate host object dependencies, and there's a constraint on removing host objects that have non-superordinate domain object dependencies. The way people work around this in practice is with hacks, as was seen at the top of this thread. Once the data constraints are worked around, you publish a zone. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] The Decline and Fall of BIND 10
On May 15, 2014, at 3:55 AM, João Damas j...@bondis.org wrote: If it is 9.11, it might be good number to make attack resilience the focus of that version (a good code audit, more robust error-condition response, evolution of RRL and related features, logging that doesn't kill you, etc) I heard they are skipping number 11, the next release would be 9.12. - Jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Weirdness with glue for old (gone) DNS servers
On Thu, May 15, 2014 at 06:52:16AM +0200, Patrik Fältström wrote: One have to remember that if example.com have an ns in ns.example.net and example.net is not renewed, there are already problems between example.com and example.net that can not really be resolved by adding technical/engineering algorithms on it. Yes, and I've tried to say that more than once. Nothing in Registry1 can do anything at all about something in the completely other Registry2. There's no link. I once suggested (I think it might have been in a hallway, even) that maybe DNSOP could express an opinion that for the simplest cases, in-zone glue was more likely to be kept up to date than anything else; an entire flock of ducks immediately appeared and nibbled me to death, so I decided that idea wasn't worth pursuing either. I think in the example you list Andrew, where you have example.com with NS ns.example.com and then example2.com with NS ns.example.com, first of all ns.example.com is not needed as an object for example2.com as the name is not in the delegated zone. I.e. we should use same rules as for glue. The problem is _not on the child side_, it's on the parent side. On the parent side, you absolutely do need glue for ns.example.com. It's an internal host object -- DNS geeks pronounce this in-baliwick glue in the .com zone -- and at any given moment, even if that glue is not needed right then, it might be needed in the next (consider the case where example.com is changing its name servers. The glue should be created just before the change. Therefore, the registry should publish the glue in the zone, even if example.com is not at that instant using ns.example.com). glue be needed, and in that case I think ns.example.com should be removed when example.com is removed. Reason for this is that I do see larger problems if ns.example.com exists and someone else is then registering example.com and inherits the ns.example.com object. The protocol won't permit you to remove example.com when ns.example.com exists. That's how the OP's problem arose. Registrars rename the subordinate object (rename ns.example.com in our case) so that it's no longer subordinate to example.com. That makes the protocol problem go away. Maybe Joe's other explanation in this thread makes it clearer, since I'm obviously not making this apparent. (Therefore, I'll shut up on the topic now :-) ) A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] The Decline and Fall of BIND 10
On Thu, May 15, 2014 at 07:12:53AM -0400, Jared Mauch wrote: I heard they are skipping number 11, the next release would be 9.12. It's on our roadmap as 9.11. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] The Decline and Fall of BIND 10
On 05/15/2014 05:12 PM, Evan Hunt wrote: On Thu, May 15, 2014 at 07:12:53AM -0400, Jared Mauch wrote: I heard they are skipping number 11, the next release would be 9.12. It's on our roadmap as 9.11. Thanks for being reasonable. Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] The Decline and Fall of BIND 10
On Thu, May 15, 2014 at 03:12:07PM +, Evan Hunt wrote: On Thu, May 15, 2014 at 07:12:53AM -0400, Jared Mauch wrote: I heard they are skipping number 11, the next release would be 9.12. It's on our roadmap as 9.11. Apparently i misheard. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Problems with the IPv6 verification support through tldmon
On 5/15/2014 16:27, Eduardo Mendez wrote: Regards, Today i´ve realized that for everytime i´ve checked IPv6 for all cctlds, they are in warning. Now for a little more than a day. https://tldmon.dns-oarc.net/nagios/ Hugs. Looks like the IPv6 connectivity on the host has failed. HOST: ivy Loss% Snt Last Avg Best Wrst StDev 1.|-- 2600:3c03::8678:acff:fe57:aac10.0%100.8 0.7 0.6 0.8 0.1 2.|-- 2600:3c03::8678:acff:fe57:a8410.0%100.7 0.7 0.6 0.7 0.0 3.|-- Vlan480.esd2.mmu.nac.net 0.0%103.7 0.9 0.4 3.7 1.1 4.|-- e1.1.tbr2.tl9.nac.net 0.0%101.4 1.6 1.3 3.5 0.7 5.|-- 2001:518:5001:10::2 0.0%103.1 1.8 1.4 3.1 0.6 6.|-- nyk-tlx-r1-g-1-3.bb.belgacom-ics.net 0.0%101.5 15.8 1.5 144.0 45.0 7.|-- ??? 100.0100.0 0.0 0.0 0.0 0.0 -- staticsafe https://asininetech.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
