hesiod and 9.3.0/8.2.3

Wed Oct 6 00:42:56 UTC 2004

At 04:23 AM 10/5/2004, Danny Braniss wrote:
> > At 05:53 AM 10/4/2004, Danny Braniss wrote:
> > >hi,
> > >         I'm about to upgrade our master dns server from 8.2.3 to 
> 9.3.0, in
> > >the process i'm discovering a 'little-problem' with class HS/hesiod:
> > >zone updates when the slave is 9.3.0 and the master is 8.2.2 fail.
> > >
> > >general: info: zone passwd.NS.CS.HUJI.AC.IL/HS/hesiod: refresh: failure
> > >trying
> > >master 132.65.16.8#53 (source 0.0.0.0#0): FORMERR
> > >
> > >if the slave is runing version 9.2.2 it works fine, also between 9.3.0 and
> > >9.2.2
> > >
> > >I could just upgrade our dns to 9.3.0 (and buy a one way ticket to 
> Rio) and
> > >hope for the best, but i'd like a less drastic path.
> >
> > Post the contents of the zone. However it is possible that 9.3.0 broke
> > something in the hesiod space. There aren't many servers out there
> > these days serving hesiod zones so it wouldn't have gotten the kind of
> > testing that internet zones get.
> >
>I don't think the contents of the zone are to blame. From looking at the
>ethereal trace, the server doesn't like the first request (with option EDNS0
>set) - so the client tries again without it, the servers says ok, but the
>client ignore it.

Probably not but it's always worth checking.

>could it be that the non-error response has the the Auth. RR clear? if so
>1- is it an old bug in 8.2.3? the server IS the master for NS.CS.HUJI.AC.IL.
>2- can 9.3.0 be made to accept data for class HS from the 'master' even if it
>forgot
>    to set the Auth. bit?

It cannot forget to set the Auth bit if it's authorative for the zone. That 
would
violate the protocols.

>[simplified ethereal trace]
>client server  Standard query SOA passwd.NS.CS.HUJI.AC.IL
>Domain Name System (query)
>     Transaction ID: 0xd0d0
>     Flags: 0x0000 (Standard query)
>         0... .... .... .... = Response: Message is a query
>         .000 0... .... .... = Opcode: Standard query (0)
>         .... ..0. .... .... = Truncated: Message is not truncated
>         .... ...0 .... .... = Recursion desired: Don't do query recursively
>         .... .... .0.. .... = Z: reserved (0)
>         .... .... ...0 .... = Non-authenticated data OK: Non-authenticated
>data is unacceptable
>     Questions: 1
>     Answer RRs: 0
>     Authority RRs: 0
>     Additional RRs: 1
>     Queries
>         passwd.NS.CS.HUJI.AC.IL: type SOA, class hesiod
>             Name: passwd.NS.CS.HUJI.AC.IL
>             Type: Start of zone of authority
>             Class: hesiod
>     Additional records
>         <Root>: type OPT, class unknown
>             Name: <Root>
>             Type: EDNS0 option
>             UDP payload size: 2048
>             Higher bits in extended RCODE: 0x0
>             EDNS0 version: 0
>             Z: 0x0
>             Data length: 0
>             Data
>
>the response is:
>
>server client Standard query response, Format error
>Domain Name System (response)
>     Transaction ID: 0xd0d0
>     Flags: 0x8081 (Standard query response, Format error)
>         1... .... .... .... = Response: Message is a response
>         .000 0... .... .... = Opcode: Standard query (0)
>         .... .0.. .... .... = Authoritative: Server is not an authority for
>domain
>         .... ..0. .... .... = Truncated: Message is not truncated
>         .... ...0 .... .... = Recursion desired: Don't do query recursively
>         .... .... 1... .... = Recursion available: Server can do recursive
>queries
>         .... .... .0.. .... = Z: reserved (0)
>         .... .... ..0. .... = Answer authenticated: Answer/authority portion
>was not authenticated by the server
>         .... .... .... 0001 = Reply code: Format error (1)
>     Questions: 0
>     Answer RRs: 0
>     Authority RRs: 0
>     Additional RRs: 0
>
>Which is probably to be expected from a vintage bind-8.2.3, then a
>'simplified' request is sent
>
>client server Standard query SOA passwd.NS.CS.HUJI.AC.IL
>Domain Name System (query)
>     Transaction ID: 0x6868
>     Flags: 0x0000 (Standard query)
>         0... .... .... .... = Response: Message is a query
>         .000 0... .... .... = Opcode: Standard query (0)
>         .... ..0. .... .... = Truncated: Message is not truncated
>         .... ...0 .... .... = Recursion desired: Don't do query recursively
>         .... .... .0.. .... = Z: reserved (0)
>         .... .... ...0 .... = Non-authenticated data OK: Non-authenticated
>data is unacceptable
>     Questions: 1
>     Answer RRs: 0
>     Authority RRs: 0
>     Additional RRs: 0
>     Queries
>         passwd.NS.CS.HUJI.AC.IL: type SOA, class hesiod
>             Name: passwd.NS.CS.HUJI.AC.IL
>             Type: Start of zone of authority
>             Class: hesiod
>
>which is answered, this time without error but is ignored by bind-9.3.0
>
>Domain Name System (response)
>     Transaction ID: 0x6868
>     Flags: 0x8480 (Standard query response, No error)
>         1... .... .... .... = Response: Message is a response
>         .000 0... .... .... = Opcode: Standard query (0)
>         .... .1.. .... .... = Authoritative: Server is an authority for 
> domain
>         .... ..0. .... .... = Truncated: Message is not truncated
>         .... ...0 .... .... = Recursion desired: Don't do query recursively
>         .... .... 1... .... = Recursion available: Server can do recursive
>queries
>         .... .... .0.. .... = Z: reserved (0)
>         .... .... ..0. .... = Answer authenticated: Answer/authority portion
>was not authenticated by the server
>         .... .... .... 0000 = Reply code: No error (0)
>     Questions: 1
>     Answer RRs: 1
>     Authority RRs: 2
>     Additional RRs: 4
>     Queries
>         passwd.NS.CS.HUJI.AC.IL: type SOA, class hesiod
>             Name: passwd.NS.CS.HUJI.AC.IL
>             Type: Start of zone of authority
>             Class: hesiod
>     Answers
>         passwd.NS.CS.HUJI.AC.IL: type SOA, class hesiod, mname
>shuldig.CS.HUJI.AC.IL

This just means that your BIND 8.2.3 box was not able to handle the EDNS0
query and the BIND 9.3.0 box resend the query without it. It probably was not
ignored. Was there any change to the zone? If the SOA serial number was
not changed then it won't need to transfer the zone if the serial number is
not larger at the BIND 8 end.

> > >so, is there any simple fix?
> >
>if there isn't, i think i can come up with a different upgrade approach.

So far I haven't seen an error.

> > You could try 9.2.4. Try running the slave version of the zone through
> > BIND 9.3.0 named-checkzone and see if it has any errors.
>
> >
> > The ticket to Rio may be a good idea
>you think i could find work there as a runaway dns manager? :-)
>
>         danny

dunno. It's also been quite I few years since I was a student in Givat Ram.
I can't get to ns. Is it inside a firewall?

Danny