classless in-addr.arpa delegation, and 3 other q's

[Ralf]

Hi, I will only answer your first question by the moment, see above.

John <Johnny at technik.sth.ac.at> wrote:

: hi,

: does anyone know about classless in-addr.arpa delegation?
: it seems to be a way, or a "workaround" to the fact that you used to be able to do reverse dns only if you had a whole C-class.

: our uplink, the university of vienna, uses this so we can do reverse dns ourselves, even though we have only a 64 ip-block assigned.
: however, on irc, some sites dont seem to recognize this and reverse map our addresses like a.b.c.d.in-addr.arpa. what kind of
: problem is this?

if you mean something like this:

nslookup  62.132.27.206

Name:    feurio.vescon.de
Address:  62.132.27.206
Aliases:  206.27.132.62.in-addr.arpa

then it is all ok. It looks a little bit strange, but it is a legal
way for classless in-addr.arpa delegation and no workaround.

Ralf

: ===

: another question I have is, I got to do the dns (and everything else) here after the other sysadmin left and it looks a bit messy. I
: updated the zone data files (bind 4) and the file for rev. dns of localhost.
: however, now, /var/log/messages gives me "named[pid]: accept: Connection reset by peer".
: what does that mean?
: that really bothers me because, a grep doesnt show this anywhere before I updated the zone files :/

: ===

: named[pid]: approved AXFR from [ip].4667 for "domain"
: named[pid]: zone transfer of "domain" to [ip].4667

: these should only occur for my secondary NS, right?

: ===

: and one last question, the primary NS is configured to forward querys to another NS (which isnt even the one authoritative for the
: zone above us)- does that make sense? it also has the line "slave" in named.boot, which, so it says, "leads to more complete
: forwarding and should be done."



: <hopes for an answer that will help him ;)>

: John