Additional information, about crash. Crash seems to happen only when asking for AAAA RR type.
it happens when constructing NXDOMAIN response for AAAA query,
so given name do not need to exist in in DNS.
I will use python shorthands to construct queries.
$ /etc/init.d/maradns restart
$ host -t AAAA `python -c 'print "w."*124 + "pl"'` # 250 characters
(including dots), 125 labels, 252 octets at wire level
w.w.w ... has no AAAA record
$ host -t AAAA `python -c 'print "w."*124 + "pl"'`
w.w.w ... has no AAAA record
# maradns still is alive here, and I can repedetly query it for above address,
but it already is in bad state
$ host -t AAAA ipv6.onet.pl # irrelevant query
;; connection timed out; no servers could be reached
$ # (maradns crashed)
Interesingly if I ask for example for host -t A wp.pl, it do not crashes
maradns.
$ /etc/init.d/maradns restart
$ host -t AAAA `python -c 'print "w."*123 + "o.pl"'` # 250 characters
(including dots), 125 labels, 252 octets at wire level
;; connection timed out; no servers could be reached
$
# 246 characters, 123 labels, 248 octets at wire level
$ /etc/init.d/maradns restart
$ host -v -t AAAA `python -c 'print "w."*121 + "o.pl"'`
$ host -v -t AAAA
w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.o.pl
All above queries make maradns crash or start behaving in unstable way
(it crashes after some other query).
This is also legal query (254 octets) , but makes maradns even strange thing:
$ /etc/init.d/maradns restart
$ host -v -t AAAA `python -c 'print "w."*125 + "pl"'`
;; Warning: Message parser reports malformed message packet.
;; Warning: Message parser reports malformed message packet.
Host
w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl
not found: 2(SERVFAIL)
$
This would be biggest possible query (255 octets)
$ /etc/init.d/maradns restart
$ host -t AAAA `python -c 'print "ww." + "w."*124 + "pl"'`
;; Warning: Message parser reports malformed message packet.
;; Warning: Message parser reports malformed message packet.
Host
ww.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.w.pl
not found: 2(SERVFAIL)
$
Maradns do not crash after both above queries, but memory coruption is
obviously presents.
This query would be too large, according to host utility
$ host -v -t AAAA `python -c 'print "w."*126 + "pl"'`
host: 'w.w.w.REMOVED.w.w.w.w.pl' is not a legal name (ran out of space)
Exit 1
$
According to RFC 1035, section 2.3.4 a size limit is:
labels 63 octets or less [ also know as
component here ]
names 255 octets or less
For messages a domain name is restricted in section 3.1
To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.
[ PS. This do not say if this is restriction before or after
compression/decompression.
But because compression can only be performed for suffixes seen
previously in
the packet, our query do not compress at all (see section 4.1.4).
But I will assume that becuase of "simplify implementation" it means
"after decompression".
Maybe some other rfc fixes this.
Similary one can construct 'more' not-compressible query, like:
"a.b.c.d.e......z.A.B....Z.0.1....9....pl"
but unfortunelty in this way only 62 components can be constructed.
]
So it looks that considering also section 4.1.2, host utility properly reports
when query is too large.
As each 'label length octets' eat 1 byte, I assume that
"w."*124 + "pl"
is 2*124 + 2 = 250 characters as dot notation, but
is actually
(1 length octet, 1 'w' characters)*124 + length octet + 2 characters for
'pl' + 1 length octet + 0 characters =
(1+1)*124 + 1 + 2 + 1 =
252 octets at wire level,
which looks ok.
Using ".w"*125, will give us 254 octets which still is OK.
I also tested different letters in domain name.
> A=map(chr, range(ord('a'), ord('z')+1) + range(ord('A'), ord('Z')+1) +
> range(ord('0'), ord('9')+1))
> print ".".join(A+A) + ".pl"
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V.W.X.Y.Z.0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V.W.X.Y.Z.0.1.2.3.4.5.6.7.8.9.pl
124 components + 1 last component (pl) + 1 empty component (root domain).
It is very strange. When quering this (call it L1), maradns do not crash and
returns NXDOMAIN (for AAAA).
If i change last 9, to "w" (call this L2), maradns also do not crash and
returns NXDOMIN (for AAAA).
But. If I query L1, and then L2, then maradns crashes. Also changing order
makes crash.
Probably some obscure memory coruption.
I do not yet tested if this bug also happen if given AAAA query would resolve
to existing AAAA RR.
(I assume I will need to install BIND and create fake nameserver to be sure).
I performed tests multiple times to make sure that other programs on the system
performing
resolving do not interfere.
PS. Previous timeout was indeed happening due to the subsequent MX query by
host utility.
It do not happen if specific RR type is asked using -t AAAA.
Regards,
--
Witold Baryluk
JID: witold.baryluk // jabster.pl
signature.asc
Description: Digital signature
