Re: Extra records in zone transfers

[Masataka Ohta <[e-mail]>]

Dan;

> Masataka Ohta writes:
> > same name server may have different A records zone by zone.
> 
> That's the BIND 9 model, but it is _not_ consistent with RFC 1034.
> Here's what the DNS specifications actually say:
> 
>    * DNS is divided into zones. Names are partitioned among zones. Each
>      zone is authoritative for all records under its names. See RFC
>      1034, section 4.1.
> 
>    * Zones may---and sometimes must---contain records for which they
>      aren't authoritative, i.e., records from other zones. These records
>      are supposed to be EXACT COPIES of the authoritative records. See
>      RFC 1034, section 4.2.1, last paragraph on page 20.

Glue records are provided by (sometimes malicious) human intervention.

"supposed to be" is not a protocol standard but a best current practice.

Protocols must assume they are supposed to be but may not be the exact
copies.

> Clients can and do assume the accuracy of any record set received from
> any server authorized to provide that set.

It's OK as long as the clients can reach the desired data.

> > > My servers use a redesigned unified configuration-file format,
> > Your server is wrongly implemented, then.
> 
> Don't be ridiculous. I'm not going to force my users to deal with that
> horrendous format. If they want painful configuration, they can use the
> BIND master-file format.

So, your server works just fine with the real world BIND master-file
content.

What is the problem, then?

> That format is, by the way, neither stable nor
> identical to the standard RFC 1034 master-file format, so you can't
> justify it on interoperability grounds.

I know. Several years ago, I found a bug on escape characters.

But, a problem here is that binary zone transfer format is not good
enough to distinguish glues of each referral.

						Masataka Ohta


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.