Re: Is this correct behavior?

[Kare Presttun <Kare@Presttun.org>]

Thanks Kevin!

At 26.11.2002 17:17 -0500, Kevin Darcy wrote:
>
>Yes, this is correct behavior. RFC 2181 Section 5.5 requires that RRsets
>not be repeated in a response.

So this is what not.norid.no and njet.norid.no follows, but not
the rest of the .no ccTLD servers as we could see from the nac.no
responce (the others all the glue as well).
>
>This "squish" tool seems to be rather misguided. It seems to assume that
>referrals will *always* contain *all* glue records in the Additional

That was my suspicion. The response from Squish is actually:
"198.133.199.105 (NJET.NORID.NO) with failed to resolve SID.NIMROD.NO
 due to 198.133.199.105 - no answers". Well the answer was there but
without the aa bit.

>Section, but this is not guaranteed. Note that the RFC verbiage you quoted
>says that glue is "necessary when the name server's name is 'below' the
>cut"; since "sid.nimrod.no" is not below the "presttun.org" zone cut,
>there is no requirement for glue to be provided. To simplify matters, each

That is why I said that it looked correct.

>gTLD nameserver tends to have glue for all the gTLD domains, which
>explains why "THREE.PSEUDOSPACE.COM" glue is available on a .org
>nameserver; however, the same simplification doesn't hold true for
>ccTLD glue -- ns2.nextra.no and sid.nimrod.no -- and that's why no glue is
>provided for those names and they need to be looked up separately.

If you look up a zone like nextra.no or nimrod.no there is no problem,
you get the answer with all (.no) glue. It is only when I look up the
nameservers directly because I got them refered from .org (or
somewhere not .no) the problem arrises. Since these servers are registered
for .no domains all the .no servers know them. While nac.no did not
provide answer, only glue, not and njet.norid.no provided partly both:
answer without glue for the question, and glue without answer for the
other server(s).
>
>It's possible that the mail originators in this case are running BIND 4,
>BIND 8 or some other DNS package which lacks "query restart", and
>therefore may fail to perform all of these extra lookups automatically.
>This would cause the query to fail initially, and if the client resolver
>reached its retry threshold, to fail fatally.
>
BIND8 is widely used so this lack of backward compatibility cause
a big problem. This is not new or?? Is it the resolvers that has the
problem?


Med vennlig hilsen | Best regards,
Kåre Presttun
Tel.: +47 4100 4908
mailto:Kare@Presttun.org
http://www.presttun.org/kare/ 

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>