Re: [9fans] DNS

I had a similar problem with 'dnscache' from the TinyDNS suite of tools a couple years back. Certain DNS names hosted in AWS Route53 would exceed the max number of requests to be resolved at random, because Route53 randomized the NS records it gave for each subdomain, so every once in awhile

Re: [9fans] DNS

possibly. however it didn't take the plan9 community long to figure out what needed to be changed. Thus, by definition, it was not too obscure. -Steve > On 1 Apr 2017, at 10:46, Alexandru Gheorghe wrote: > > That's a weird name for CNAME traversing. Should've been

Re: [9fans] DNS

That's a weird name for CNAME traversing. Should've been (maybe more appropriately): "MaxCnameDepth". On 04/01/2017 04:40 AM, Skip Tavakkolian wrote: > Maxretries to > 5 -- ; Alexandru Gheorghe ; ;

Re: [9fans] DNS

Thanks! I should have checked the sources. On Fri, Mar 31, 2017 at 6:28 PM wrote: > yes. raising Maxretries to > 5 in dnresolve.c fixes it. this parameter > limits the chain of cname redirects. > > -- > cinap > >

Re: [9fans] DNS

yes. raising Maxretries to > 5 in dnresolve.c fixes it. this parameter limits the chain of cname redirects. -- cinap

Re: [9fans] DNS

Doesn’t work quite right for me. It resolves a few steps and gets to an IP address but it never prints out the “answer” between - lines. If I do it for www.google.com then it does. Also it prints some console messages - "no rr from dblookup; crapped out" Pete

[9fans] DNS

It seems Plan 9 dns can't resolve www.paypal.com correctly; I'm not sure why. Can anyone with a 9front installation try this to see if it resolves to the an IP address (i.e. see a final "answer" output)? ndb/dnsdebug www.paypal.com Thanks, -Skip

Re: [9fans] DNS

trying again. On Mon, Mar 20, 2017 at 12:26 AM Skip Tavakkolian < skip.tavakkol...@gmail.com> wrote: > It seems Plan 9 dns can't resolve www.paypal.com correctly; I'm not sure > why. > > Can anyone with a 9front installation try this to see if it resolves to > the an IP address (i.e. see a

Re: [9fans] dns message

> ipnet=local ip=192.168.0.0 ipmask=255.255.255.0 > ipgw=192.168.0.1 > smtp=ar !> ntp=ntp.jst.mfeed.ad.jp ip > auth=hebe > fs=hebe > # the dns values are advertised by DHCP server > # we assume that dhcpd is running on the same ip. look /cfg/common/cpurc >

Re: [9fans] dns message

thank you erik. you are very careful! I didn’t aware that garbage. however removing “ip” does not fix my problem. looking source code I guess: names that are not followed by “=“ are just discarded. I want to know whether this is only to me. erik, thanks again! > 2015/09/27 0:28、erik quanstrom

Re: [9fans] dns message

On Sat Sep 26 15:52:28 PDT 2015, aris...@ar.aichi-u.ac.jp wrote: > thank you erik. > you are very careful! > I didn’t aware that garbage. > however removing “ip” does not fix my problem. > looking source code I guess: names that are not followed by “=“ are just > discarded. > I want to know

[9fans] dns message

Hello, running dns with -rs options I have a lot of messages in /sys/log/dns term% tail dns hebe Sep 26 07:17:20 rejecting my ip 192.168.0.6 as local dns server hebe Sep 26 07:19:34 rejecting my ip 192.168.0.6 as local dns server hebe Sep 26 07:19:37 rejecting my ip 192.168.0.6 as local dns

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

there you go: http://plan9front.googlecode.com/hg/sys/src/cmd/ip/hproxy.c http://plan9front.googlecode.com/hg/sys/src/cmd/ip/socksd.c -- cinap

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

http://plan9front.googlecode.com/hg/sys/src/cmd/ip/hproxy.c http://plan9front.googlecode.com/hg/sys/src/cmd/ip/socksd.c Thank you. Lucio. - This email has been scanned by the MxScan Email Security System.

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

The 9P implementation is based on puffs. Its docs/code may be of help. On Tuesday, October 14, 2014, lu...@proxima.alt.za wrote: i use a socks and http proxies running on the plan9 gateway machine to get windows internet connectivity. the plan9 machines just import the /net.alt ipstack

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

Not without substantial development work (I'd bet more than simply putting NAT on Plan 9). Once you get Plan 9's /net on the linux box, nothing's going to know what to do with it. The existing p9p code won't use it directly, nor will iptables know how to send packets there. If you want

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

doing plan9 gateway here. i use a socks and http proxies running on the plan9 gateway machine to get windows internet connectivity. the plan9 machines just import the /net.alt ipstack from it. the advantage is that i can run servers behind my gateway that listen on the public ip stack (thru

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

On 10/13/2014 at 9:25 PM, cinap_len...@felloff.net wrote: i use a socks and http proxies running on the plan9 gateway machine to get windows internet connectivity. the plan9 machines just import the /net.alt ipstack from it. Uau! So simple! I'm still thinking if will work for my machines... the

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

i use a socks and http proxies running on the plan9 gateway machine to get windows internet connectivity. the plan9 machines just import the /net.alt ipstack from it. I'm not aware that such tools are in the standard distribution (I have plans to install both 9atom and 9front, but not

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

On 10/10/2014 at 6:45 PM, Brian L. Stuart blstu...@bellsouth.net wrote: However, to my knowledge, there aren't any NAT implementations available on Plan 9. I know it's been worked on by several people at different times, but I don't think anyone has a currently packaged implementation. It might

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

On Oct 11, 2014, at 15:35 , brank...@hushmail.com wrote: It might be silly, but how about this: ISP router - Plan9 - Linux+P9P Mount the /net from Plan9 machine on the Linux machine, and add some iptables rules. Do you think it will work? Not without substantial development

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

if you really want to use plan9 as your internet gateway you could set up PPP between plan9 and Linux, though I have never tried this. On 11 Oct 2014, at 20:54, Anthony Sorace a...@9srv.net wrote: On Oct 11, 2014, at 15:35 , brank...@hushmail.com wrote: It might be silly, but how

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

On 10/11/2014 at 11:34 PM, Quintile st...@quintile.net wrote: if you really want to use plan9 as your internet gateway you could set up PPP between plan9 and Linux, though I have never tried this. I want a safe door to the outside world, and as plan9 is simpler ... But as I think about, I

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

On 10/10/2014 at 11:56 PM, Quintile st...@quintile.net wrote: sounds like an excellent idea, only one pain, the auth server uses the console for its config Then, I'll have to choose between a pi+keyboard+display, and a secondhand atom netbook (7-10). Btw, the usb keyboard and hdmi display are

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

One can still take a look to the simple stateless NAPT implementation I did few years ago. http://9legacy.org/9legacy/patch/nat.diff It works, but it's incomplete. However, I think it's simple enough to be used as an example to work on a more complete implementation. Another approach would be

[9fans] DNS/DHCP/AUTH with Raspberry Pi?

Hello, I'm new to Plan9, using acme/p9p for a couple of months, and I want to add plan9 machines to my network. I'm thinking that a DNS/DHCP/AUTH server will be an easy step. If this machine could have the role of an Internet firewall/nat-router it will be even better. Do you think

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

I'm new to Plan9, using acme/p9p for a couple of months, and I want to add plan9 machines to my network. I'm thinking that a DNS/DHCP/AUTH server will be an easy step. If this machine could have the role of an Internet firewall/nat-router it will be even better. Do you think plan9+raspi

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

I think the raspberry pi disk image that is available is 2GB, so it's probably easiest if you have at least that. On 10 October 2014 09:41, Brian L. Stuart blstu...@bellsouth.net wrote: I'm new to Plan9, using acme/p9p for a couple of months, and I want to add plan9 machines to my network.

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

sounds like an excellent idea, only one pain, the auth server uses the console for its config you could use erik's con Ethernet console driver so you can configure it from another plan system, or even dial into the pi and connect back in via con. this is not referred though, ideally you should

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

you could use erik's con Ethernet console driver so you can configure it from another plan system, or even dial into the pi and connect back in via con. cec(1), which is implemented in 9atom. - erik

Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?

cec(1) oops, yep, that's the one. On 10 Oct 2014, at 22:08, erik quanstrom quans...@quanstro.net wrote: you could use erik's con Ethernet console driver so you can configure it from another plan system, or even dial into the pi and connect back in via con. cec(1), which is

[9fans] DNS failures

I'm getting consistent failures from ndb/dns -rs that look like this: assert failed: rp-magic == RRmagic The corresponding stack dump is: ripple# acid 78867 /proc/78867/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid:

Re: [9fans] DNS failures

It is likely that I have a consistency error in the database: something along these lines, but not very clearly, was reported when I tried to do a zone transfer from Plan 9 to NetBSD; I have not been able to track the cause down. yes, there clearly is junk in the in-memory database. that

Re: [9fans] dns

I'm seeing dns panics about once a day. It was built from sources that were updated about a week ago from sources. it's a double free error. any ideas? cpue% acid 7196 /proc/7196/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: stk() abort()+0x0 /sys/src/libc/9sys/abort.c:6

Re: [9fans] dns

look at: free(v=0xa7200)+0x23 /sys/src/libc/port/malloc.c:250 notice the lsb is 00 exactly like in the case i solved here: http://9fans.net/archive/2012/08/249 i hate to repeat myself all the time. geoff needs to fix dial(). -- cinap

Re: [9fans] dns

look at this: free(v=0xa7200)+0x23 /sys/src/libc/port/malloc.c:250 thats exactly what happend here: http://9fans.net/archive/2012/08/249 its not a double free. dial() corrupts your stack. geoff needs to fix fial(). -- cinap

Re: [9fans] dns

I there a patch? it's not obvious from the archive posting what should be changed. -Skip On Sat, Sep 8, 2012 at 11:18 AM, cinap_len...@gmx.de wrote: look at this: free(v=0xa7200)+0x23 /sys/src/libc/port/malloc.c:250 thats exactly what happend here: http://9fans.net/archive/2012/08/249

Re: [9fans] dns

its pretty simple, just look where i made the --- arrow in my original post. a patch would might look like this: static int fillinds(DS *ds, Dest *dp) { Conn *conn; if (dp-winner 0) return -1; conn = dp-conn[dp-winner]; if (dp-cfdp)

Re: [9fans] dns

it makes perfect sense: if the length of the path is NETPATHLEN, length of a string usually referring to non-zero bytes, you need to allow for the terminating zero byte. unfortunately, as you describe, it's a bit pointless because the dnsresolve callers rely on the manual page (The path name is

Re: [9fans] dns

ah, so NETPATHLEN was introduced later and is really refering to the number of non null characters? and there was never an official named constant for the size of the netdir buffers for dial/annouce? thats indeed confusing. -- cinap

Re: [9fans] dns

No, I didn't explain it well. NETPATHLEN isn't named in the manual pages, so ndb/dns doesn't use it. On the other hand, dial does, but because it's ...LEN, it's an easy mistake to think of it as the length of a string, which wouldn't include the terminating zero byte, instead of the length of the

Re: [9fans] dns

On Sat Sep 8 23:02:25 EDT 2012, charles.fors...@gmail.com wrote: No, I didn't explain it well. NETPATHLEN isn't named in the manual pages, so ndb/dns doesn't use it. On the other hand, dial does, but because it's ...LEN, it's an easy mistake to think of it as the length of a string, which

Re: [9fans] dns

Thanks all. it's interesting that announce.c doesn't have the same problem: cpue% grep -n NETPATHLEN /sys/src/libc/*/*.[ch] /sys/src/libc/9sys/announce.c:73: strncpy(dir, buf, NETPATHLEN); /sys/src/libc/9sys/announce.c:74: dir[NETPATHLEN-1] = 0;

Re: [9fans] dns poisoning

you are right! baddelegation() is checking for that, but it was not effective because it bailed out before even entering that for loop because of: if(t == nil) t = lookupinfo(dom); if(t == nil) return 0; - delegation loop will not be checked

Re: [9fans] dns poisoning

Nice catch! 2012/8/29 cinap_len...@gmx.de: you are right! baddelegation() is checking for that, but it was not effective because it bailed out before even entering that for loop because of: if(t == nil) t = lookupinfo(dom); if(t == nil)

Re: [9fans] dns poisoning

dblookup.c:816,821 - /sys/src/cmd/ndb/dblookup.c:814,822 return 1; } + if(t == nil) + continue; + /* see if delegating to us what we don't own */ for(nt = t; nt != nil; nt = nt-entry)

[9fans] dns poisoning

aback.com has ns.buydomains.com as nameserver, which seem to announce itself to be responsible for the whole .com tld and answers positively to everything with bullshit spam ip addresses causing all further .com domain queries to get resolved by that spam ns.buydomains.com dns. :( is this allowed

Re: [9fans] dns poisoning

On Tue Aug 28 23:33:20 EDT 2012, cinap_len...@gmx.de wrote: aback.com has ns.buydomains.com as nameserver, which seem to announce itself to be responsible for the whole .com tld and answers positively to everything with bullshit spam ip addresses causing all further .com domain queries to get

Re: [9fans] dns

Hello, I got a broken dns snapshot. You can download from: http://plan9.aichi-u.ac.jp/dns.snap.gz Kenji Arisawa

Re: [9fans] dns

very good. thanks. one wired thing is that the string pointer (0xfb900) it tried to free (char *domain) points in the middle of the querylck array of a allocated DN. thats not a valid alloc block indeed. there migh'v been a block there, but it got accidently freed and then the space reused for

Re: [9fans] dns

if (ds-dir) { strncpy(ds-dir, conn-dir, NETPATHLEN); ds-dir[NETPATHLEN] = '\0'; i think this is okay, since the definition is chardir[NETPATHLEN+1]; - erik

Re: [9fans] dns

no. just look at all the call sites for announce() and dial(). ghost drivers! ghost drivers everywhere! -- cinap

Re: [9fans] dns

On Mon Aug 27 22:11:14 EDT 2012, cinap_len...@gmx.de wrote: no. just look at all the call sites for announce() and dial(). ah, you're right about dial. i misread that. i incorrectly considered the Conn and not the DS. both dial and announce could use a parameter declaring the size of the

Re: [9fans] dns

anyone look at rrcopy() in dn.c, it seems it assumes that structures like rr-soa, rr-cert, rr-key, rr-sig and rr-null where embedded into the RR struct but this is not true. (porting bug?) when you look at rralloc(), you can see that these sub structures are indeed malloced so rrcopy needs to

Re: [9fans] dns

It does. In fact, it's the Tsrv case that looks wrong (it leaks space already allocated by rralloc). nrp = rralloc(rp-type); ... case Tsoa: soa = nrp-soa;--- save space allocated by rralloc *nrp = *rp; --- destroy pointer by copying onto it nrp-soa = soa;

Re: [9fans] dns

9fans stoped sending me mail again, i read your response on the 9fans archive. you are indeed correct, i missed that it used rralloc() wich allocates all the structures. so false alarm from me again, but at least you spoted the memory leak. another thing, the DN* rr-sig-signer doesnt seem to get

Re: [9fans] dns

always make a process snapshot as the kernel might discard your broken process once it runs low on memory so you have time to debug: snap 41356 /tmp/dns.snap char *domain strings alloc header seems to have been corrupted (or just freed by accident?). the string just gets allocated and freed in

Re: [9fans] dns

Hello cinap, broken dns triggers Fauth problem, so I have rebooted. I will get snapshot at next crash. Kenji Arisawa On 2012/08/25, at 19:54, cinap_len...@gmx.de wrote: always make a process snapshot as the kernel might discard your broken process once it runs low on memory so you have

Re: [9fans] dns

did somebody notice that in dnresolve.c, netqueryns() frees the nsrp rr list? but in issuequery() it calls netqueryns() in a loop with the same nsrp pointer! -- cinap

Re: [9fans] dns

no, sorry. missed that nsrp = nil, carry on... -- cinap

Re: [9fans] dns

In my copy, which I'm sure I haven't changed, it gets a new nsrp from randomize(rrlookup... each time, or uses dbnsrp, which is randomize(dblookup..., so both are new and can be freed. On 25 August 2012 09:22, cinap_len...@gmx.de wrote: but in issuequery() it calls netqueryns() in a loop with

Re: [9fans] dns

yes, missed that. -- cinap

Re: [9fans] dns

looking for bugs, that mydnsquery() function uses netmkaddr(), which stores the resulting dialstring in a global static buffer. the tcplock in the query makes sure theres just one tcp dial going on *per query* but there could be multiple queries in parallel i think which might override that buffer

Re: [9fans] dns

Hello cinap, I got a one. I hope this a helpful. ar% cat broken/1345779846.41356 name=dns /proc/41356/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: abort()+0x0 /sys/src/libc/9sys/abort.c:6 ppanic(p=0x3975c,fmt=0x394ec)+0x146 /sys/src/libc/port/malloc.c:166

Re: [9fans] dns

wait, Maxdest is a count, see: dest = emalloc(Maxdest * sizeof *dest); /* dest can't be on stack */ code like: Dest*curdest; /* pointer to next to fill */ p = dp-dest; ... if (qp-ndest qp-curdest - p) { and for(p = qp-dest; p qp-curdest; p++) indicates that dp-curdest is an end

Re: [9fans] dns

Hello, On 2012/08/22, at 19:32, cinap_len...@gmx.de wrote: the result check of that serveraddr() call should really be: if (j 0 || j Maxdest) { dnslog(serveraddrs() result %d out of range, j); abort(); }

Re: [9fans] dns

look closely at: qp-curdest = qp-dest[j]; this just takes the address, it doesnt actually dereference anything. you could write this as qp-curdest = qp-dest + j. that destck(qp-curdest); call and the j = Maxdest check after the serveraddrs() call seem like a confused debug

Re: [9fans] dns

On Wed Aug 22 08:38:51 EDT 2012, cinap_len...@gmx.de wrote: look closely at: qp-curdest = qp-dest[j]; this just takes the address, it doesnt actually dereference anything. you could write this as qp-curdest = qp-dest + j. that destck(qp-curdest); call and the j = Maxdest

Re: [9fans] dns

and further, after failing to get an answer from 24 different servers, it's unlikely that the 25th will trying 24 different servers for the same address is already i think it should be smaller. but that's just me. :-). good grief. what that was supposed to say was the 25th is unlikely to

Re: [9fans] dns

for(n = 0; n Maxdest; n++, qp-curdest++) if (setdestoutns(qp-curdest, n) 0) On 22 August 2012 09:05, erik quanstrom quans...@quanstro.net wrote: since qb-curdest is indirected, for example by setdestoutns, this must be a valid pointer to remain safe. only when the pointer is valid. I

Re: [9fans] dns

or is here any reason why serveraddrs() should *not* fill the whole array up to the last element and stop at Maxdest-2? I'm just guessing here, but Kenji pointed to the need to add a server address in the case of a straddling server. Would that perhaps be a factor here? ++L

Re: [9fans] dns

that's why cinap removed that line in his diff. On 22 August 2012 09:18, erik quanstrom quans...@quanstro.net wrote: you can argue that this is a mistake, but i'm sure there are others.

Re: [9fans] dns

i just said it like 2 times already that i think this destck() and the result serveraddrs() check is bogus and is the source of all this confustion. the curdest is handled as an end pointer in the rest of the code. its where you start adding stuff, and after writing it, you increment it to the

Re: [9fans] dns

On Wed Aug 22 09:34:24 EDT 2012, cinap_len...@gmx.de wrote: i just said it like 2 times already that i think this destck() and the result serveraddrs() check is bogus and is the source of all this confustion. the curdest is handled as an end pointer in the rest of the code. doesn't this code

Re: [9fans] dns

No, see the call to procansw On 22 August 2012 10:22, erik quanstrom quans...@quanstro.net wrote: since, if qp-curdest is an end pointer, then p!=qp-curdest ≡ 1.

Re: [9fans] dns

this is interesting. the p != qp-curdest check would just support my point because it effectively checks if p is valid. if p would be at qp-curdest, it would be past the last valid entry and hence invalid so its not written. but theres another thing, look in queryns() how p comes to be:

Re: [9fans] dns

On Wed Aug 22 10:51:02 EDT 2012, cinap_len...@gmx.de wrote: this is interesting. the p != qp-curdest check would just support my point because it effectively checks if p is valid. if p would be at qp-curdest, it would be past the last valid entry and hence invalid so its not written. if

Re: [9fans] dns

here's my copy. it probablly won't work if *ncpu1 on the standard system because vmap's no up to the task. i didn't re-verify that all the vmap() wiggles are necessary with nix; they are with the pae kernel. - erik#includeu.h #include../port/lib.h #includemem.h #include

Re: [9fans] dns

On Wed Aug 22 11:34:39 EDT 2012, quans...@quanstro.net wrote: here's my copy. it probablly won't work if *ncpu1 on the standard system because vmap's no up to the task. i didn't re-verify that all the vmap() wiggles are necessary with nix; they are with the pae kernel. - erik sorry,

Re: [9fans] dns

I sent this to cinap earlier, who concurred. On 22 August 2012 11:12, Charles Forsyth charles.fors...@gmail.com wrote: Given the comment /* remove all addrs of responding server from list */ for(np = qp-dest; np qp-curdest; np++) if(np-s == p-s) p-nx = Maxtrans; I wonder whether np-nx

Re: [9fans] dns

Hello, I suspect the problem is in: --rwxrwxr-x M 21231 glenda sys 311768 Jul 14 11:46 dns I don't have 2012/0501 version. I am lazy sorry. My current dns is --rwxrwxr-x M 131526 sys sys 310819 Apr 13 12:46 /386/bin/ndb/dns That works 12 days since last boot without any troubles. ar% ps

Re: [9fans] dns

nothing wrong with diffing the changes and see if theres a clue, but to solve this one really needs to find the underlying cause no matter what. changes can just hide bugs or make them more or less likely to appear. can anyone provide at least a stacktrace or process snapshot of the crashed dns

Re: [9fans] dns

can anyone provide at least a stacktrace or process snapshot of the crashed dns processes? I've had double-free errors from dns on my server, but the same machine suffers from fossil/venti errors, so I can't use it as diagnostics. I do think that Plan 9 dns is a bit fragile, though not in the

Re: [9fans] dns

Hello, Files in /sys/src/cmd/ndb are not be changed since this Mar 31. However dns in /n/sources/plan9/386/bin/ndb have changed two or three times since that day. Probably the difference comes from others (library?). hera% pwd /sys/src/cmd/ndb hera% ls -lt --rw-rw-r-- M 21422 sys sys 34365 Mar

Re: [9fans] dns

On Tue Aug 21 07:31:55 EDT 2012, cinap_len...@gmx.de wrote: nothing wrong with diffing the changes and see if theres a clue, but to solve this one really needs to find the underlying cause no matter what. changes can just hide bugs or make them more or less likely to appear. can anyone provide

Re: [9fans] dns

Doh! I can't tell you how often I've looked at that very line of code, but evidently my eyes are shallow. On 21 August 2012 14:32, erik quanstrom quans...@quanstro.net wrote: all of the crashes were due to an off-by-one in dnresolv:/^serveraddrs the final loop in the function should be limited

Re: [9fans] dns

On Tue Aug 21 16:06:56 EDT 2012, charles.fors...@gmail.com wrote: Doh! I can't tell you how often I've looked at that very line of code, but evidently my eyes are shallow. i missed it last time, too. - erik

Re: [9fans] dns

excellent! :) -- cinap

[9fans] dns

Has anyone else been seeing their Plan 9 dns servers work for a little while and then stop responding? I've seen this happen after delegation loops show up in the logs: Aug 20 00:24:10 delegation loop 68.23.115.in-addr.arpa ns rev1.kornet.net - ns H.ROOT-SERVERS.NET from 211.216.50.180

Re: [9fans] dns

i'm using a modified version of dns. i found that aktomi redirections too unreliable. even so, i still get crashes, which have become more frequent in recent weeks. i've attached a copy of restartdns which is ment to be called from cron on short intervals. contrib quanstro/ndb has the whole

Re: [9fans] dns

Hello Recent version of dns crashes. Old version (for example, Apr this year) is OK. It seems crashed dns make other side effect: Many processes stop with Fauth status. # I don't know the reason. Kenji Arisawa On 2012/08/21, at 10:51, Jeff Sickel wrote: Has anyone else been seeing their Plan

Re: [9fans] dns

As in using: Apr 12 22:46:05 CDT 2012 /n/sourcesdump/2012/0501/plan9/386/bin/ndb/dns 310819 [jmk] Oct 14 13:32:38 CDT 2011 /n/sourcesdump/2012/0412/plan9/386/bin/ndb/dns 310519 [sys] There are a few differences if you compare with sourcesdump. Knowing one that works should help narrow down the

Re: [9fans] dns

Has anyone else been seeing their Plan 9 dns servers work for a little while and then stop responding? I had that, and other problems with it left and right. I probably had to restart DNS a few times per week. I was able to get it to support a local Windows Active Directory domain though,

Re: [9fans] dns problem with plan9.iso downloaded on Tue07Feb2012_2219

Thank you. Managed to ping 8.8.8.8 and had to recompile ping after modifying nrand.c as per my earlier bug find on Mar 9 2009, 9:38 am [

[9fans] dns problem with plan9.iso downloaded on Tue07Feb2012_2219

Hello Using this new version and creating a new Plan9 install with the following: md5sum /home/plan9/plan9.Tue07Feb2012_2219.iso a62dba17efa51e3c5dbd1b12e8586492 /home/plan9/ plan9.Tue07Feb2012_2219.iso I see the following: term% ip/ipconfig term% ndb/dns -r term% ip/ping www.google.com

Re: [9fans] dns problem with plan9.iso downloaded on Tue07Feb2012_2219

is ndb/cs running ? stat /srv/cs 2012/2/13 ROuNIN rounin.urash...@googlemail.com Hello Using this new version and creating a new Plan9 install with the following: md5sum /home/plan9/plan9.Tue07Feb2012_2219.iso a62dba17efa51e3c5dbd1b12e8586492 /home/plan9/ plan9.Tue07Feb2012_2219.iso I

Re: [9fans] dns problem with plan9.iso downloaded on Tue07Feb2012_2219

term% ip/ping -fr 192.168.0.12 192.168.0.12 is not a routable address, so one onders if you can actually route out of your local segment. try 8.8.8.8. It used to work before - what happened? Have I missed something? ROuNIN dns failure usually means that a dns message came back in response

[9fans] dns vs. textrr

a long text record seems to be causing lookup failures for other records. with the record below in /lib/ndb/external, lookups for mx.coraid.com fail. with just that line deleted, lookups work again. older versions of dns don't seem to have that problem. i was wondering if anyone had seen this?

Re: [9fans] dns vs. textrr

Haven't seen it. But it does seem that a lot of us are having fun with dns this week (and every week). Mine's more the problem of ndb/dns -sx /net.alt -f /lib/ndb/external configuration and properly getting it a resolver from a subsequent dns= tuple. One day I'll remember to keep it

Re: [9fans] dns vs. textrr

On Thu Jan 19 12:08:37 EST 2012, j...@corpus-callosum.com wrote: Haven't seen it. But it does seem that a lot of us are having fun with dns this week (and every week). Mine's more the problem of ndb/dns -sx /net.alt -f /lib/ndb/external you probablly want -R too, so you ignore the

  1   2   >