[01:10] anyone tried upgrading to OpenBSD 4.8? [01:18] *** LT has joined #arpnetworks [01:20] *** schmir has quit IRC (Remote host closed the connection) [01:40] *** Ehtyar has joined #arpnetworks [01:40] *** schmir has joined #arpnetworks [02:41] *** Sunil has quit IRC (Quit: leaving) [04:49] *** schmir has quit IRC (Remote host closed the connection) [05:08] *** schmir has joined #arpnetworks [05:12] *** schmir has quit IRC (Remote host closed the connection) [05:36] *** nesta has quit IRC (Ping timeout: 265 seconds) [05:38] *** nesta has joined #arpnetworks [05:39] *** tuv has quit IRC (Read error: Connection reset by peer) [05:41] *** tuv has joined #arpnetworks [06:21] Sunil: 4.8 and current works fine, just recall to 'disable mpbios' [06:48] *** kitkatbar has joined #arpnetworks [06:50] i was wondering, if i can nslookup -type=aaaa six.nullbnc.com from my localbox but ping6 six.nullbnc.com on my local box says "network is unreachable", however, it ping6 fine on my server and i can connect to irc with it... something must be configured incorrectly :( [06:51] i'm running debian, any hints or help would be nice :D [06:52] *** andrewnemeth has joined #arpnetworks [06:52] hey guys [06:52] need some help with my freebsd [06:52] how can I resize the root partition? [07:08] *** ziyourenxiang has joined #arpnetworks [07:18] ahh looks like my localhost doesn't support ipv6 at home, no wonder i got network is unreachable [07:18] :> [07:22] *** andrewnemeth has quit IRC (Quit: andrewnemeth) [07:23] ipv6 is nice [07:23] i hear it is the future of the internet!! [07:23] ye [07:24] can you see if you can "ping6 six.nullbnc.com" ? [07:36] nvm [07:38] *** BarberRonny has quit IRC (Quit: leaving) [07:38] *** BarberRonny has joined #arpnetworks [07:38] *** BarberRonny has quit IRC (Client Quit) [07:39] *** kitkatbar has quit IRC (Quit: leaving) [07:47] *** BarberRonny has joined #arpnetworks [07:48] *** BarberRonny has quit IRC (Client Quit) [07:49] *** BarberRonny has joined #arpnetworks [07:53] *** BarberRonny has quit IRC (Client Quit) [07:55] *** BarberRonny has joined #arpnetworks [07:55] *** BarberRonny has quit IRC (Client Quit) [07:55] up_the_irons: How do you share your libvirt config files? Storage, network, VM config, etc across your host servers? [07:55] I was considering using git as we do with Xen but that seems to be frowned upon. [07:56] *** BarberRonny has joined #arpnetworks [08:00] mhoran: iscsi? [08:00] * ww hides [08:01] Sure, we use iSCSI for block devices, but /etc/libvirt is what I want to share. [08:01] And sharing that directory (or at least /etc/libvirt/qemu) is frowned upon -- https://www.redhat.com/archives/libvir-list/2009-October/msg00033.html [08:01] Really, all I need shared is /etc/libvirt/storage, since that's where my storage pools live (which are iSCSI). [08:02] But to migrate a domain that lives on an iSCSI block devices, the pool must first exist and be started on the remote end, which isn't always the case. [08:02] So really, libvirt should just have better support for migrating iSCSI pools. And should start them up automatically when a domain is migrated (though I see why it doesn't do that). [08:02] So in the meantime I have to find a way to share my storage pools, and to do that I've checked everything in /etc/libvirt save qemu dir into git. [08:10] mhoran: i was being facetious... [08:10] ... i've not actually looked into the details of qemu much [08:16] So I think I'm just going to write a wrapper around iscsiadm that automatically creates the poolsfor the available targets ... that seems the best way to do this ... and then let libvirt migrate the domain configs when it wants to. [08:16] Unless up_the_irons has a better option for me. :) [08:19] mhoran: up_the_irons doesn't do auto distribution, from what I can see it is a manual migration process [08:38] *** schmir has joined #arpnetworks [08:39] and he doesn't do iscsi, he has found physical disks on the servers to be more reliable [08:39] toddf: do you know what OS is used to host the virtual machines? [08:39] Ubuntu. [08:40] nesta: Linux is all I need to know. ;-) [08:40] hehe [08:40] * nesta prefers a good ole BSD [08:40] I've found iSCSI to be just as reliable as physical disks, it's just more expensive. Though our iSCSI vendor blows. [08:40] It's nice for e.g. live migration. [08:40] nesta: a good ole BSD doesn't do kvm just yet [08:40] Replication and failover as well. [08:41] toddf: I imagine not :) [08:41] mhoran: check the old logs about iscsi [08:41] I know, just stating my opinion. [08:42] aka regarding up_the_irons experiences with it [08:43] Live migration (or even migrating betwen hosts -- what about failed disks) just seems so impossible without iSCSI. Granted, we don't currently have live migration even with Xen, but we do have iSCSI backed storage and can easily move VMs between host servers with no data loss. [08:43] Our iSCSI infrastructure is also fully redundant, we've got N+1 replication and then RAID-5 on each cluster node. [08:43] We've lost entire iSCSI systems and remained fully available. [08:43] Not to mention losing a single disk and being fine. [08:43] as soon as live migration is a requirement, iSCSI makes sense [08:44] when the environment is large enough such setups make sense [08:44] Yup. Well, it is, here. We just can't use it. We just need to be able to migrate between hosts, at a minimum. And that seems too difficult with local storage. [08:45] at arp, there is a bit of common sense, simplicity, and economy in the mix, iscsi tends to take the simplicity and economy out of the equation IMHO [08:45] though I don't disagree with the awesomeness of your setup [08:46] I wish there was a free software iscsi target that did anything close to what you describe [08:46] I wish our product did everything it was supposed to do. :p [08:46] as it is the one free iscsi target I can run on OpenBSD (netbsd-iscsi-target ironically) can't even reload the targets config file w/out restarting, severing all iscsi connections in the process .. whee! [08:46] Damn. [08:47] Yeah, considering what it does, it's pretty solid. But sometimes it's really flakey, and it requires a clunky Java GUI to manage it. [08:47] Though now it's got some SSH console, but the CLI is undocumented. [08:47] are you able to divulge your 'product' ? ;-) I've got an equalogix array at a customers colo, seems like a very fancy iscsi target... [08:47] The clustering is awesome, and it supports LACP at the link layer automatically so the NICs are redundant. [08:47] HP/LeftHand SANs. [08:48] that sounds a lot like equalogix wannabe [08:48] Indeed. They were around for a while as LeftHand and then HP bought them. Apparently they've rose to huge success, at least that's their excuse for their shitty tech support. [08:48] The whole core was some guys PhD thesis or something. [08:49] ;-) [08:49] Wish it were open source, it would kick ass. [08:49] yeah [08:49] The real cool thing is remote replication -- we can replicate our five san cluster to our second datacenter all in a half hour over a dedicated backbone link. [08:49] thats what equalogix touts also [08:50] do you do more granularity than 15mb data chunks? [08:50] I believe so, though I've not tuned any of that. [08:50] it seems rather rediculous if one byte is modified every 15mb .. it transfers the entire 15mb chunk [08:51] Yeah, looks like LH is 256k. [08:51] much more efficient [08:52] I'm wondering if the new version of the software fixes some of thes issues we've seen with the version we're running, but I don't think I'm going to get the go-ahead to upgrade ... we've just had major headaches with upgrades in the past, and, if it ain't broke it, don't fix it. [08:52] But I know the second I log a support call, they're going to tell me to upgrade. [08:53] heh [09:00] Oh, of course listStoragePools() and listDefinedStoragePools() are mutually exclusive, why not! [09:15] *** LT has quit IRC (Quit: Leaving) [09:23] *** kitkatbar has joined #arpnetworks [09:29] mhoran: the config is not shared [09:30] *** heavysixer has quit IRC (Quit: BAMPF!) [09:32] up_the_irons: can you double check some small configs for me? [09:34] this is ipv6 part of /etc/network/interfaces -> http://pastebin.com/BKN6usGX [09:35] kitkatbar: shouldn't the netmask for link local be /48 [09:36] i'm not sure, i had hell of a time getting it to the point where it is now [09:36] :) [09:37] :) [09:37] kitkatbar: the mask should be /48 if you are routing a /48 block of ipv6 over link local [09:37] also, do you have packet fowarding enabled [09:37] yes [09:38] any crazy firewall rules [09:38] /etc/sysctl.conf i added net.ipv6.conf.all.forwarding = 1 [09:38] default firewall [09:39] ok [09:39] i even added that protocol 41 i think to iptables [09:39] kitkatbar: has he fowarded the block to you yet? [09:39] yes [09:39] i already have reverse delegation to my nameservers [09:39] can you print out "ifconfig" and "route" [09:39] sure one sec [09:39] and pastebin them [09:40] http://pastebin.com/gcFQAvXA [09:41] inet6 addr: fe80::2/64 Scope:Link is incorrect [09:41] should be fe80::2/48 [09:42] your routes look correct [09:42] bout to restart networking or might reboot [09:42] to see if the netmask 48 will change things [09:43] vcs: fe80::2/48 is incorrect. link local addresses are /64's [09:43] :X [09:43] kitkatbar: ^ [09:43] * vcs slaps himself [09:43] fe80::2/64 is correct [09:44] ::/0 2607:f2f8:34c0::1 UG 1 0 0 eth1 [09:44] it looks like you have an extra default route for ipv6 [09:45] that was probobly leftover from your /64 [09:45] err wait [09:45] im not used to non BSD route, lol [09:45] *** kitkatbar has quit IRC (Read error: Connection reset by peer) [09:47] 16 bytes from 2607:f2f8:34c0::3, icmp_seq=0 hlim=63 time=1.264 ms [09:47] that looks good :) [09:47] *** unknown_ has joined #arpnetworks [09:47] *** unknown_ is now known as kitkatbar [09:47] kitkatbar: you had an extra default ipv6 route [09:47] that was the problem [09:47] ;) [09:48] ::/0 2607:f2f8:34c0::1 UG 1 0 0 eth1 [09:48] was still loaded [09:48] from your /64 [09:48] so rebooting cleared it out, and now you are on ipv6 ;) [09:48] congrats man [09:48] sweet [09:49] hehe [09:49] can you check to see if you can reverse this ip 2607:f2f8:34c0::3 [09:49] maybe it just hasn't propagated yet, i sure to hell hope i got bind9 configured properly [09:50] Host 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.4.3.8.f.2.f.7.0.6.2.ip6.arpa not found: 2(SERVFAIL) [09:50] hmm [09:50] kitkatbar: are you running BIND? [09:51] yea [09:51] i get this from my server though [09:51] nslookup -type=AAAA six.nullbnc.com [09:51] six.nullbnc.com has AAAA address 2607:f2f8:34c0::3 [09:51] don't use nslookup for debugging or troubleshooting. use dig. [09:53] nslookup will make several assumptions about the information you are looking for, and will occasionally work even when things aren't configured properly. if you are troubleshooting, this is not a good thing. [09:54] thx :D i'm not a network guru yet [09:54] this one had me baffled [09:54] dig says no error when i dig that domain, so i guess it's a propagation issue [09:55] kitkatbar: I'm pretty decent with bind. let me scroll up a sec and read from the top. [09:55] i was having ipv6 issues with my interfaces config with the netmask [09:56] i think changing it and rebooting solved that problem [09:57] kitkatbar: it looks like ns1 and ns2.nullbnc.com are delegated the ip6.arpa for that address space. are those your NS's? [09:57] dig @your.dns.server.com 2607:f2f8:34c0::3 PTR [09:57] try that [09:57] yes [09:58] http://pastebin.com/ZmuJwBtM [09:58] kitkatbar: I'm getting a SERVFAIL from your NS for that record. can you paste your bind config and zone config? [09:58] yes, one sec [10:03] http://pastebin.com/VazMSimU [10:11] kitkatbar: I'm not seeing anything obviously wrong with the configs/zone. do you see any errors in bind when loading the configs? [10:12] no [10:12] i added that ipv6 address to ns1.nullbnc.com thinking it might help [10:13] not sure if thats correct, probally should work without it [10:13] ahh, your SOA, and origin don't match in the ip6.arpa zonefile [10:15] you have a zone definition of: 0.c.4.3.8.f.2.f.7.0.6.2.ip6.arpa, you have an SOA of: 0.c.4.3.8.f.2.f.7.0.6.2.ip6.arpa but you have an ORIGIN of: 0.0.0.0.0.c.4.3.8.f.2.f.7.0.6.2.ip6.arpa [10:16] ahhh [10:16] *** ziyourenxiang has quit IRC (Quit: ziyourenxiang) [10:17] so should which one should i change [10:17] lol [10:17] sorry [10:17] should i add 4 0's to the SOA or remove 4 0's from the origin? [10:18] must of been the ipv6 reverse dns zone builders fault, i should've known better than to use it haha [10:20] try removing the extra nibbles from the ORIGIN, and add them to the PTR record itself. [10:22] says status: noerror on dig now [10:22] instead of nxdomain [10:22] but still says answer: 0 [10:32] hmm i have no idea [10:32] i've tried every combination possible with the 0 thingy [10:51] *** Sabrii has joined #arpnetworks [10:52] keek-a-boo [11:00] *** schmir has quit IRC (Ping timeout: 265 seconds) [12:14] *** kitkatbar has quit IRC (Quit: leaving) [12:36] *** fink has joined #arpnetworks [12:44] anyone use gitosis with gitweb? [13:18] *** kitkarbar has joined #arpnetworks [13:18] i'm now getting a response with 'dig @ns1.nullbnc.com six.nullbnc.com AAAA' [13:19] but when i try 'host 2607:f2f8:34c0::3' it says servfail [13:33] *** schmir has joined #arpnetworks [13:59] *** islandfox has quit IRC (Read error: Connection reset by peer) [14:00] *** islandfox has joined #arpnetworks [14:01] *** Husky has quit IRC (Read error: Connection reset by peer) [14:01] *** mhoran has quit IRC (Read error: Connection reset by peer) [14:01] *** mhoran has joined #arpnetworks [14:01] *** ChanServ sets mode: +o mhoran [14:01] *** jazz57 has joined #arpnetworks [14:02] *** schmir has quit IRC (Remote host closed the connection) [14:02] *** heidar has quit IRC (Ping timeout: 245 seconds) [14:02] Anyone experiencing connectivity issues? [14:02] *** dxtr has quit IRC (Ping timeout: 264 seconds) [14:03] nope [14:03] not yet :X [14:03] I can't even ping arpnetworks.com [14:03] no pings [14:04] [sundial@puffy ~]$ ping6 arpnetworks.com [14:04] 16 bytes from 2607:f2f8:0:102::3, icmp_seq=0 hlim=63 time=1.054 ms [14:04] ipv6 is up [14:04] What about ipv4? [14:04] working for me [14:04] Some of us still use that, ya know. [14:04] :P [14:05] i have stuff hosted on ipv4 [14:05] and its all working ok [14:05] arp networks site is up for me [14:05] maybe its a routing problem [14:05] between you and them [14:05] 11 ae-1-69.edge1.SanJose1.Level3.net (4.68.18.14) 75.912 ms ae-3-89.edge1.SanJose1.Level3.net (4.68.18.142) 76.104 ms ae-4-99.edge1.SanJose1.Level3.net (4.68.18.206) 76.735 ms [14:05] 12 * * * [14:05] 13 * * * [14:05] dies at level3 [14:05] Yeah. [14:05] Having trouble here as well. [14:05] Just a few minutes ago. [14:05] *** Sheath has joined #arpnetworks [14:05] man I've got 2 vps boxes at softlayer [14:05] two times today [14:05] no response [14:05] argh [14:06] The level3 to MZIMA link may be down. [14:06] Yeah. [14:06] I can get in over v4 from my house, but not from work. [14:06] Home goes over Comcast to Mzima, work goes over L3. [14:06] My monitoring service is also complaining. [14:08] I'm on roadrunner and it dies at the Level3 MZIMA connection. [14:08] What does your route look like vcs? [14:09] *** dxtr has joined #arpnetworks [14:09] The link from Trit Networks may still be up. [14:10] vapor: Soflayer is going downhill? [14:10] They used to have a very good reputation. [14:10] alright, one sec [14:10] ill get you a traceroute [14:14] on http://pastebin.ca/1986763 [14:14] *** kitkarbar has quit IRC (Quit: Lost terminal) [14:14] my traffic is being routed over mzima [14:14] it appears [14:14] I love softlayer [14:14] just don't like random weird issues [14:14] I run a small datacenterand we never run into these kinds of problems [14:14] * vapor knocks on wood [14:14] :) [14:15] level3 routing issues...those happen a lot [14:15] level3 sucks [14:15] Thanks vcs. [14:15] mzima is good transit [14:15] considering they default to level3 mostly [14:15] im supprised i dont go through level3 [14:15] since im a few miles from them [14:15] lol [14:15] guess thats a good thing [14:15] level3 has awesome latency but they do run into routing issues frequently [14:15] their network is AGED like a fine wine [14:16] i have some servers collocated at their datacenter here [14:16] no ipv6 :X [14:16] guess thats aged equip for ya [14:16] vcs, yeah they still dont run v6 [14:16] you have to run tunnels [14:16] I remember when level3 was considered modern [14:17] *** nukefree has joined #arpnetworks [14:17] * RandalSchwartz waves from LA [14:17] jazz57: like 10 years ago? [14:18] it's so cool to have 1.1 ms ping times to my VPS from my desk :) [14:18] *** nuke| has joined #arpnetworks [14:19] *** nuke| is now known as nuke` [14:19] Here is my trace: http://pastebin.ca/1986770 [14:19] RandalSchwartz: I've got a couple of hundred [14:20] I usually get routing through Los Angeles. Now it's going up to SJC and getting lost. [14:21] vcs: That sounds about right. :-) [14:22] hurricane electric is cool :) [14:22] i like them :) [14:22] I remember someone recommending Level3 over ATT because the had a new network built from scratch. [14:22] a couple of hundred milliseconds? [14:23] I like hurricane too. ipv6 and they have a cool NTP servers too. [14:23] still seeing lvlt issues [14:23] it actually gets to mzima now [14:23] so if its bgp then should only take another 60 seconds [14:24] I'm still getting destination unreachable [14:26] *** kitkatbar has joined #arpnetworks [14:26] Ooh, my nagios just went nuts [14:26] did we have some downtime recently? [14:26] is anyone else experiencing network lag? [14:26] kitkatbar: I can't get connect at all. [14:26] me either [14:27] i've been working all day on my server [14:27] Me too. :-) [14:27] I just through. [14:27] I can't figure out why nagios can't even ping its own host [14:27] I've got "host down" on localhost. :( [14:27] And yes, something went down before, RandalSchwartz [14:28] randalschwartz: fd depletion or other dos? firewalling localhost? [14:28] no. nothing unusual. [14:28] maybe the whole VM was frozen [14:28] or at least the network stack outside my view [14:28] bad stuff from 1405 to 1426 across multiple VPS [14:28] nagios acts funny if resources take too long to allocate .. wheterh thats sockets or disk blocks etc [14:29] since it forks a process to run the check and considers things bad if it doesn't check in so to speak within a certain timeframe [14:29] well - that's pointing at VM issues, not guest OS issues [14:29] Looked like a network issue to me. [14:29] so it's Garrey's problem not mine [14:29] any of you guys can help me figure out why my rdns isn't working for my ipv6 [14:29] *** heidar has joined #arpnetworks [14:29] but it's his *because* I'm gonna get yelled at because of it [14:30] randalschwartz: think thundering herd of disk io .. slowing nagios process creation if the sectors happen to not be cached in memory .. [14:31] sure. Still sounds like a virtual-hardware fault though [14:31] I'd like those to go away [14:33] given my experience with nagaios, I'd expand the timeframe during which individual checks timeout and/or generate warnings by 20-40% ... just because nagios couldn't meet its own criteria of happy days doesn't mean external usage was effected as much as nagios might have you think .. *shrug* .. I've written a replacement to nagios and uninstalled it from my systems due to its inability to stop producing false positives on real hw, leta lone ... [14:33] ... virtual hw [14:34] Yes - I wait 10 checks before I send a hard notice [14:34] but I still shouldn't be getting soft notices like this [14:34] both mabel and red went nuts at the same time [14:34] so I'm gonna blame somethign higher [14:35] mind you, 99.96% availability isn't bad [14:35] but another 9 wouldn't hurt [14:35] especially if it's a fault that Garrey can fix [14:36] and it sounds like all of us experienced something odd during that time [14:36] that smells of VM [14:36] oops. It's Garry, and Dolley [14:36] I have a hard time remembering that. Blame jet lag. ) [14:38] Here is my trace now:http://pastebin.ca/1986789 [14:38] The route has changed back to Los Angeles. [14:40] So somehow a partial network outage causes weirdness with the VMs. [14:41] ok, so who here is setting their vm to go 'fritz' when upstream network outages occur? ;-) [14:41] anyone run debian & bind w/ ipv6? [14:41] maybe a bunch of console notifications (high uninterruptible priority) [14:41] kitkatbar, dig -x ip +trace is your friend [14:43] I did get some "runtime went backwards" notices the other day in my logs. [14:44] Interrupts may be getting dropped when activity is too high. [14:44] Someone suggested dropping kern.HZ to 10. [14:45] (assuming freeBSD) [14:46] I think it's that already [14:46] maybe it was the mysterious missle launch earlier off the coast of la the caused it [14:46] Oh. I have hz = 100 [14:53] did the missle launch affect the cruise ship that lost power? :) [14:54] maybe the missle took out our route :X [14:54] bastards! [14:55] that's what I get for putting that info record in! [14:56] $ host -t loc stonehenge.com [14:56] stonehenge.com location 34 2 53.000 N 118 15 21.000 W 50.00m 1m 10000m 10m [14:58] vcs, can you post your reverse zone for ipv6 please? [14:59] wait [14:59] kitkatbar: sure [15:00] i already have the link [15:00] i used same generator you did [15:00] but my reverses dont work :/ [15:00] http://pastebin.com/r5mb6mwn [15:00] did you use your own ip /48 range [15:00] and not mine [15:01] yes [15:02] perhaps your named.conf file is bad? [15:02] http://pastebin.com/J3VcyXaf [15:03] or you did not run rndc reload [15:03] yes i have [15:03] lol [15:03] ive tryed everything i know [15:03] 201011090 ; Serial number (YYYYMMdd) [15:03] errr [15:03] you have only changed to today? [15:03] i've been at this all day [15:03] every time you make a change [15:03] it requires an incriment [15:03] then rndc reload [15:03] Uh - that's not 00 [15:03] else it will not realod [15:04] 20101109xx [15:04] even for 'host ipv6:address' to work? [15:04] oh i see [15:04] to check to see if the config has changed [15:04] lemme test this [15:05] I'm old school... /etc/rc.d/named reload :) [15:06] well i have mostly been restarting it with /etc/init.d/bind9 restart [15:07] reload is enough [15:07] ah [15:07] well i still have a problem then :/ [15:07] and you should alwaysalwaysalways increment the serial [15:07] yes i just did and tested it [15:07] same result [15:08] but atleast i know in the future when i make a modification, to increment the serial [15:13] are there any error messages when bind is reloading? [15:13] what does your local soa report? [15:14] host -t soa $domain $localhost [15:15] you've checked your /var/log/* logfiles, right? [15:16] no errors when bind is reloading [15:17] host -t soa six.nullbnc.com nullbnc.com [15:17] Using domain server: [15:17] Name: nullbnc.com [15:17] Address: 174.136.101.162#53 [15:17] Aliases: [15:17] six.nullbnc.com has no SOA record [15:20] no no - the rdns [15:20] since that's what you're having trouble with [15:20] or am I mixing up conversations here [15:20] no [15:20] your bind should report an SOA with the same serial as what you defined [15:21] host -t soa 0.c.5.a.8.f.2.f.7.0.6.2.ip6.arpa. localhost [15:21] something like that [15:22] Wait a second [15:22] that SOA is wrong [15:22] @ IN SOA your.forward.host.name.here.com your.email.host.com. ( [15:22] that's what you want [15:22] not the reverse [15:23] you're defining the authoritative *master* host for *this* domain [15:23] for example, I have [15:23] @ IN SOA red.stonehenge.com. hostmaster.stonehenge.com. ( [15:23] * RandalSchwartz waits until kitkatbar catches up [15:24] so your saying '@ IN SOA 0.c.4.3.8.f.2.f.7.0.6.2.ip6.arpa. ns1.nullbnc.com. (' is wrong in my reverse-ip6.arpa file? [15:24] Yes. Very Wrong. [15:24] guess thats what i get for using damn generator for this reverse file [15:24] @ IN SOA master.host.com youremail.youremailhost.com [15:24] hahaha. wrong indeed. [15:24] no - you just put the wrong data in [15:24] it asked you things, you told it wrong :) [15:24] GIGO [15:24] ah [15:24] lol [15:24] lemme see if this will fix it [15:25] and what does your delegation in your master file look like? [15:25] in my nullbnc.com.db file it looks like [15:25] @ IN SOA ns1.nullbnc.com. ns2.nullbnc.com. [15:25] no... in your named.conf [15:26] ... zone "0.8.0.3.8.f.2.f.7.0.6.2.ip6.arpa" { [15:26] something like that? [15:26] yea [15:26] ok - so fix your soa, reload [15:26] and then you should be able to check your soa locally [15:26] once that's working, you can worry about the right upstream delegations [15:28] host -t soa -i six.nullbnc.com [15:28] six.nullbnc.com has no SOA record [15:28] wrong question [15:28] indeed [15:28] host -t soa -i nullbnc.com localhost [15:28]