[9fans] dns vs. textrr

[erik quanstrom]

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?

- erik

----

dom=m1._domainkey.coraid.com txtrr="k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUlNZvtGDlIGDRtzyRQydM9yRInD5YMx86QpgZ3v7pT+Mx4tGbjUxY41TXbsp7UH9hTREaKKGQKNM/B3FzcFVv4zafZ09lUaXcbSdtD70iXyH0OXEGXLZI5gG0ZwjK5ptgQ18d+pUP9s8xMkJnZlubTk9MLvQnv3ZBzoL9FHFDQIDAQAB"

[Jeff Sickel]

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 simple and just have everything in /net
and learn to manage the bridging between networks.

-jas

Post by erik quanstrom
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?
- erik
----
dom=m1._domainkey.coraid.com txtrr="k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUlNZvtGDlIGDRtzyRQydM9yRInD5YMx86QpgZ3v7pT+Mx4tGbjUxY41TXbsp7UH9hTREaKKGQKNM/B3FzcFVv4zafZ09lUaXcbSdtD70iXyH0OXEGXLZI5gG0ZwjK5ptgQ18d+pUP9s8xMkJnZlubTk9MLvQnv3ZBzoL9FHFDQIDAQAB"

[erik quanstrom]

Post by Jeff Sickel
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 RD flag
on incoming queries.

the key to getting plan 9 resolution working right is
to have the proper ipnet configuration that has a
proper netmask s.t. ndb/ipquery $sys dns gives a
credible answer. e.g.

ladd; ndb/query ipnet athensnat
ipnet=athensnat ip=192.168.0.0 ipmask=/120 fs=aska.quanstro.net ipgw=192.168.0.4 gw=dexter-peak.quanstro.net dns=192.168.0.136 dnsdomain=quanstro.net authdom=plan9.quanstro.net auth=ladd cpu=ladd smtp=ladd
ladd; ndb/ipquery sys ladd dns
dns=192.168.0.136
ladd; ndb/query sys ladd
ip=192.168.0.136 sys=ladd ether=001d92350045 dom=ladd.quanstro.net proto=il

- erik

ps. the limit is 214 characters in that particular textrr. one
would expect 256, evidently the difference is the meaning
of life.

[erik quanstrom]

it turns out that the problem with ndb is actually a bio
problem Brdline() freaks out and returns nil if the line
in question is longer than b->bsize and doesn't increment
the file pointer, so you've got an infinite loop.

i had thought that this was clearly in violation of
what the man page says, but on second read, i'm not so
sure. i would think that Brdline() should return a
buffer if there are bytes available—otherwise it
could be confused with eof, but that's clearly not
what the code does.

it seems from the existing bio code the only reasonable way
eat lines that are too long is

/* get a line (ignoreing long ones) */
dump = 0;
for(;;){
if((line = Brdline(b, '\n')) == 0){
if(Blinelen(b)>0){
Bseek(b, Blinelen(b), 1);
dump = 1;
continue;
}
break;
}
if(dump){
dump = 0;
continue;
}
break;
}

that seems a bit ... goofy. it would seem better for
bio to do this internally? surely there isn't code that
relies on this behavior?

- erik

[Lyndon Nerenberg]

Post by erik quanstrom
that seems a bit ... goofy. it would seem better for
bio to do this internally? surely there isn't code that
relies on this behavior?

Or maybe realloc() a larger buffer and try to carry on? There's no guarantee of buffer pointer consistency across B* calls, is there? Default to 8K (or whatever), and place an adjustable cap of, say, 128K, on the dynamic bsize.

Given some XML stanzas I've seen lately, elastic buffers have a lot of appeal ...

[erik quanstrom]

Post by Lyndon Nerenberg

Post by erik quanstrom
that seems a bit ... goofy. it would seem better for
bio to do this internally? surely there isn't code that
relies on this behavior?

Or maybe realloc() a larger buffer and try to carry on? There's no guarantee of buffer pointer consistency across B* calls, is there? Default to 8K (or whatever), and place an adjustable cap of, say, 128K, on the dynamic bsize.

sizing the buffer has been considered (putting in a cap puts the
caller in the same position as before). it's probablly the best option,
if the goal is to rehabilitate Brdline(). i'm wondering if it shouldn't
just be considered depricated.

- erik

[erik quanstrom]

Post by erik quanstrom
it's probablly the best option,
if the goal is to rehabilitate Brdline(). i'm wondering if it shouldn't
just be considered depricated.

If you don't think of Brdline() as a 'C char *' construct, it's a useful vessel to escape from one of the most evil parts of parsing text. I won't begin to recount the pain I've endured dealing with text protocol parsers that didn't get the \r\n split across the buffer boundary right.
If you're claiming to read a line, just do it. I don't care if you have to buy dictionaries to hold the words, and front-end loaders from which to fill them!
Certainly some smarts can be added to deal with inflated buffers when they are no longer needed. But for now, dying from malloc(HUGE) isn't much worse than the current behaviour.

depricated, as in use Brdstr(2) instead which does its own dynamic allocation.

- erik

[Lyndon Nerenberg]

Post by erik quanstrom
depricated, as in use Brdstr(2) instead which does its own dynamic allocation.

This is where 'grep -r' is useful. How much pain might it be to nuke-and-replace the dead interface?

[Lyndon Nerenberg]

Post by erik quanstrom
it's probablly the best option,
if the goal is to rehabilitate Brdline(). i'm wondering if it shouldn't
just be considered depricated.

If you don't think of Brdline() as a 'C char *' construct, it's a useful vessel to escape from one of the most evil parts of parsing text. I won't begin to recount the pain I've endured dealing with text protocol parsers that didn't get the \r\n split across the buffer boundary right.

If you're claiming to read a line, just do it. I don't care if you have to buy dictionaries to hold the words, and front-end loaders from which to fill them!

Certainly some smarts can be added to deal with inflated buffers when they are no longer needed. But for now, dying from malloc(HUGE) isn't much worse than the current behaviour.

--lyndon

[Jeff Sickel]

Post by erik quanstrom

Post by Jeff Sickel
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 RD flag
on incoming queries.

not necessarily what I want, but I've tried that too.

Post by erik quanstrom
the key to getting plan 9 resolution working right is
to have the proper ipnet configuration that has a
proper netmask s.t. ndb/ipquery $sys dns gives a
credible answer. e.g.

yep, I get clean sys, ip, etc resolves for nodes in my
/lib/ndb/external file. It's the next hop out that just
doesn't happen. No pointer to the next dns server to
do a lookup, e.g. sources.cs.bell-labs.com.



Turns out Presotto posted a little comment in 9fans years back
about adding root entries into an ndb file would solve it. It
works, now I can replica/pull and 9fs sources til the cows come
home from a cpu server that spans multiple networks.

So as a reminder:

ndb/dns -sx /net.alt -f /lib/ndb/external

will require the external file to have the ROOT-SERVERS.NET ns
entries defined even if you have the following:

database=
file=/lib/ndb/external
file=/lib/ndb/common


^just copy the *ROOT-SERVERS.NET lines from /lib/ndb/common into
the external file. It may just be more practical to copy
local.complicated to external and edit from there. Researching
the lack of the database reference to /lib/ndb/common is left
to the reader.

-jas