-BEGIN PGP SIGNED MESSAGE-
Nico Schottelius [mailto:[EMAIL PROTECTED] wrote:
Hello!
I am more or less new to nanog (reading it about half a year),
so please correct me, if I do something wrong.
Jeroen Massar [Tue, Feb 10, 2004 at 02:07:27PM +0100]:
Jun-ichiro itojun Hagino
Jeroen Massar [EMAIL PROTECTED] wrote:
[...]
Not yet indeed, unfortunatly. The RIR prefixes under ip6.int, at least
for RIPE, seem to exist though if they don't take it up with them.
RIPE does require 2 mails to marvin, one for ip6.int and one for ip6.arpa.
Just to clarify, two domain objects
On Wed, Feb 11, 2004 at 00:36:19 +, Paul Vixie wrote:
or just put http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt into effect.
I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
rvdp
In article [EMAIL PROTECTED] you write:
On Wed, Feb 11, 2004 at 00:36:19 +, Paul Vixie wrote:
or just put http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt into effect.
I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
rvdp
RFC 3363 does NOT say that DNAME
On Wed, 11 Feb 2004, Mark Andrews wrote:
RFC 3363 does NOT say that DNAME is deprecated. All it says
is that since A6 was moving the exprimental using DNAME to
support renumbering is deprecated.
Which part of:
Therefore, in moving RFC 2874 to
Having been present at the meeting that gave rise to the document (at
the IETF meetings held in London, August 2001), I'd say that the
material quoted in the document is at fault. (There was quite a lot
of controversy at the meeting, perhaps my recollection isn't shared
with all others. But
or just put http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt into effect.
I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
A6 and bitstring labels are deprecated. DNAME remains in full force.
or just put http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt into effect.
I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
A6 and bitstring labels are deprecated. DNAME remains in full force.
last i heard from you, you said that DNAME would be evaluated by
... http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt ...
last i heard from you, you said that DNAME would be evaluated by recursive
resolver and will not be visible to end client... what changed?
according to this experiment:
+---
| ;; QUESTION SECTION:
|
[EMAIL PROTECTED] (Edward Lewis) writes:
...
DNAME was kind of the third record in. The change in it's status
pertained to the role it played in supporting bit sting labels -
which is why the reverse tree is mentioned in the deprecation.
Looking at the document now, the document ought to
Having been present at the meeting that gave rise to the document (at
the IETF meetings held in London, August 2001), I'd say that the
material quoted in the document is at fault. (There was quite a lot
of controversy at the meeting, perhaps my recollection isn't shared
with all
-BEGIN PGP SIGNED MESSAGE-
Paul Vixie wrote:
SNIP
the type is defined and at least one authority server
implementation will synthesize protocol-compliant CNAME RRs
in the presence of DNAMEs, and so
the approach documented at www.isc.org/pubs/tn/ will
universally work OK.
In that
... http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt ...
last i heard from you, you said that DNAME would be evaluated by recursive
resolver and will not be visible to end client... what changed?
according to this experiment:
+---
| ;; QUESTION SECTION:
|
[itojun]
i understand some implementation (BIND 9.3?) does this,
i think it's all bind9, but certainly all bind 9.2 and later.
but is the behavior documented somewhere in the set of RFCs?
yes. marka just quoted all of that.
for instance, does djbdns do it? does MS DNS server do it?
On Wed, 11 Feb 2004, Paul Vixie wrote:
: as a practical matter, it is impossible to ensure that all name servers
: and resolvers understand DNAME. but it is very possible to ensure that
: a given zone, such as 8.f.4.0.1.0.0.2.ip6.arpa in ISC's case, is only
: served by authority servers who
On Wed, 11 Feb 2004, Paul Vixie wrote:
: as a practical matter, it is impossible to ensure that all name servers
: and resolvers understand DNAME. but it is very possible to ensure that
: a given zone, such as 8.f.4.0.1.0.0.2.ip6.arpa in ISC's case, is only
: served by authority
-BEGIN PGP SIGNED MESSAGE-
Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame delegation
of blah.ip6.int. ip6.arpa. query returns instantly.
how
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame delegation
of blah.ip6.int. ip6.arpa. query returns instantly.
how could we fix it?
By fixing the software as ip6.int was deprecated 2
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame delegation
of blah.ip6.int. ip6.arpa. query returns instantly.
how could we fix it?
By fixing the software as ip6.int was deprecated 2 years+++
-BEGIN PGP SIGNED MESSAGE-
Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame
delegation
of blah.ip6.int. ip6.arpa. query returns
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame delegation
of blah.ip6.int. ip6.arpa. query returns instantly.
how could we fix it?
the ip6.int entry times out, no servers
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame delegation
of blah.ip6.int. ip6.arpa. query returns instantly.
how could we fix it?
By fixing the software as ip6.int was deprecated 2 years+++
ago as you
-BEGIN PGP SIGNED MESSAGE-
Randy Bush wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes
very long time. i guess i found the reason - (possible) lame delegation
of blah.ip6.int. ip6.arpa. query returns instantly.
how could we fix it?
By fixing the
-BEGIN PGP SIGNED MESSAGE-
Mark Andrews wrote:
The correct fix to this will be to just stop making IP6.INT
queries.
The best think that could be done is for the PTB to install
IP6.INT. DNAME IP6.ARPA. *now*. This will allow the legacy
resolvers to
In article [EMAIL PROTECTED] you write:
-BEGIN PGP SIGNED MESSAGE-
Mark Andrews wrote:
The correct fix to this will be to just stop making IP6.INT
queries.
The best think that could be done is for the PTB to install
IP6.INT. DNAME IP6.ARPA. *now*. This will
Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very
long time. i guess i found the reason - (possible) lame delegation of
blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
[EMAIL PROTECTED] (Jeroen Massar) writes:
Jun-ichiro itojun Hagino wrote:
if i try to log into my machines back in tokyo by IPv6 SSH, it takes very
long time. i guess i found the reason - (possible) lame delegation of
blah.ip6.int. ip6.arpa. query returns instantly. how could we fix it?
[EMAIL PROTECTED] (Jeroen Massar)
27 matches
Mail list logo
