[EMAIL PROTECTED] writes:
[ about RFC 1034's database-consistency requirement ]
> The only way to meet this all the times and at all levels
> of the DNS is to have the all the zones administered on a
> single machine *and* to have a multizone transfer protocol.
False; and, more importantly, irre
> Andrews admits that his configuration violates RFC 1034 section 4.2.2.
It's a necessary and unavoidable reality to temporarily
violate it.
The only way to meet this all the times and at all levels
of the DNS is to have the all the zones administered on a
Andrews admits that his configuration violates RFC 1034 section 4.2.2.
He also agrees that DNS servers are allowed to discard the inconsistent
parts of his configuration. (BIND 9 doesn't; djbdns does; BIND 8 does to
some extent.)
However, because the _title_ of section 4.2.2 is ``Administrative
co
> Here's a chart summarizing the situation:
>
>Timing of |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns
>data change |practice |compliant|support|support|support
>--+-+-+---+---+---
>Synchronized |Yes |Yes |No
Here's a chart summarizing the situation:
Timing of |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns
data change |practice |compliant|support|support|support
--+-+-+---+---+---
Synchronized |Yes |Yes |No |No |
> [EMAIL PROTECTED] writes:
> > Semi-synchronized changes have always been part of the DNS.
>
> If there's an honest proposal to modify the DNS specifications to allow
> semi-synchronized changes (once again: parent zone being changed after
> all the child servers have changed), perhaps the discu
[EMAIL PROTECTED] writes:
> Semi-synchronized changes have always been part of the DNS.
If there's an honest proposal to modify the DNS specifications to allow
semi-synchronized changes (once again: parent zone being changed after
all the child servers have changed), perhaps the discussion will re
> Robert Elz writes:
> > If you have a proposal for some method to actually cause the parent/child
> > delegation to *always* be compatible (glue in parent matches records in
> > child, always), then please don't keep it a secret
>
> Read about timestamps in http://cr.yp.to/djbdns/tinydns-data.ht
Robert Elz writes:
> If you have a proposal for some method to actually cause the parent/child
> delegation to *always* be compatible (glue in parent matches records in
> child, always), then please don't keep it a secret
Read about timestamps in http://cr.yp.to/djbdns/tinydns-data.html. It's
not
On 19 Feb 2003, D. J. Bernstein wrote:
> If the BIND company wants the RFC 1034 rule changed, they can propose
> that, and we'll discuss the costs and benefits. Instead they're trying
> to slip the change past us as a ``clarification.'' You know they're
> lying; why are you condoning dishonest be
Date:19 Feb 2003 05:44:54 -
From:"D. J. Bernstein" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| In the situation under discussion, one server has both zones, so that
| server _can_ guarantee RFC 1034 consistency---and my server _does_.
| (BIND 8 also
[EMAIL PROTECTED] writes:
> ; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2
[ claims that ns2.child.example.net doesn't exist, as compared to: ]
> ; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.2
> ns2.child.example.net.10 IN A 10.53.0.2
Once ag
Kevin Darcy writes:
> RFC 1034 requires matching NS record sets in the parent
> and the child, but this cannot be *guaranteed*
In the situation under discussion, one server has both zones, so that
server _can_ guarantee RFC 1034 consistency---and my server _does_.
(BIND 8 also does, to some exten
13 matches
Mail list logo
