Re: [DNSOP] draft-jabley-dnsop-missing-mname-00

2008-11-23 Thread Joe Abley


On 19 Nov 2008, at 14:28, Antoin Verschuren wrote:


Just a small nit I happened to notice in this draft.
In section 3, there's an example SOA record where the dot representing
the MNAME is printed behind the RNAME.
Shouldn't the MNAME be before the RNAME ?

So:

@   1800IN  SOA jabley.automagic.org. . (

Should be:

@   1800IN  SOA . jabley.automagic.org. (

?


Yes, you're right.

I'd undertake to fix that and roll a -01, but last I heard (in Dublin)  
there was no consensus that the idea had legs, so I have dropped it.



Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] draft-jabley-dnsop-missing-mname-00

2008-11-19 Thread Antoin Verschuren
Just a small nit I happened to notice in this draft.
In section 3, there's an example SOA record where the dot representing
the MNAME is printed behind the RNAME.
Shouldn't the MNAME be before the RNAME ?

So:

@   1800IN  SOA jabley.automagic.org. . (

Should be:

@   1800IN  SOA . jabley.automagic.org. (

?

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [EMAIL PROTECTED]
W http://www.sidn.nl/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-jabley-dnsop-missing-mname-00

2008-06-28 Thread Paul Vixie
> Is it then out of spec if we're working with a hidden/unreachable master
> server, and even though it is disclosed in SOA.MNAME, it is not listed in
> NS.NSDNAME ?  What should one put in the SOA.MNAME in that case ?  Any one
> of the slaves ?

Since an RFC 2136 initiator is only supposed to send updates to an NS.NSDNAME,
and since the only spec'd use for SOA.MNAME is to select an NS.NSDNAME, any
change we want existing clients to make, we'd make with changes in NS.NSDNAME,
which would also affect normal operations (since these are used for delegation)
which isn't desireable.

I don't know a way to get out-of-spec clients to stop sending unwanted updates
other than to point SOA.MNAME at a meaningless value like LOCALHOST in one's
own local domain, and have that resolve to 127.0.0.1.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-jabley-dnsop-missing-mname-00

2008-06-28 Thread Phil Regnauld
(updated subject to reflect draft being discussed)

Paul Vixie (vixie) writes:
> i think that if LOCALHOST. could be made to return A 127.0.0.1 and  ::1
> then we could use LOCALHOST. as a meaningless value for SOA.MNAME,

I actually considered that option for a moment.

> but that
> would just be there to handle the case where RFC 2136 initiators were talking
> to an SOA.MNAME that did not match any NS.NSDNAME, in which case they are
> already out of spec and it's difficult to say how much effort should be spent
> changing the spec further.

Is it then out of spec if we're working with a hidden/unreachable master
server, and even though it is disclosed in SOA.MNAME, it is not listed
in NS.NSDNAME ?  What should one put in the SOA.MNAME in that case ?
Any one of the slaves ?

Phil
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop