- Forwarded message from Fred Baker -
This is a structured question for the community.
Jari Arkko tells us that he is getting requests from various sources to take
RFC 5006 to Proposed Standard. It is now experimental.
http://www.ietf.org/rfc/rfc5006.txt
5006 IPv6 Router Advertisement
In message <4ba0ee53.20...@restena.lu>, Gilles Massen writes:
>
> Chris Thompson wrote:
> > On Mar 17 2010, sth...@nethelp.no wrote:
> >
> >> Should of course have checked hostname.bind, which reveals:
> >>
> >> % dig @202.12.27.33 hostname.bind ch txt +short
> >> "M-CDG-3"
> >> % dig @2001:dc3:
At 15:51 -0400 3/17/10, Paul Wouters wrote:
I think currently, a wrong DS trumps an updated DLV, but I have not
tested this recently on either bind or unbound. Is it specified anywhere
else what the expected behaviour is?
Local policy trumps all.
For instance in RFC 4035:
#4.9.3. Handling o
On Wed, Mar 17, 2010 at 03:51:42PM -0400, Paul Wouters wrote:
> I think currently, a wrong DS trumps an updated DLV, but I have not
> tested this recently on either bind or unbound. Is it specified anywhere
> else what the expected behaviour is?
Good point. No, I have no idea.
A
--
Andrew Sull
On Wed, 17 Mar 2010, Andrew Sullivan wrote:
I think this should be changed to
The same operational concerns apply to the rollover of KSKs that
are used as trust-anchors. But remember: if a trust anchor
replacement is done incorrectly, and there is no other trust path
to the zone or val
Dear colleagues,
I have reviewed draft-ietf-dnsop-rfc4641bis-02. These are my
comments.
First, I think the draft is largely in good shape, but there remain
some substantive issues in it that I think require work. I do not
think there is enough "current practice" on the Internet to target BCP
st
Chris Thompson wrote:
> On Mar 17 2010, sth...@nethelp.no wrote:
>
>> Should of course have checked hostname.bind, which reveals:
>>
>> % dig @202.12.27.33 hostname.bind ch txt +short
>> "M-CDG-3"
>> % dig @2001:dc3::35 hostname.bind ch txt +short
>> "M-CDG-4"
>>
>> So it seems my guess of Paris
On Mar 17 2010, sth...@nethelp.no wrote:
A small followup:
So it looks like the IPv4 instance refuses TCP, while the IPv6 instance
handles it okay. No filters in the way at my end. The m.root-servers.net
instance looks like it is in Paris or thereabouts - but there is quite
a bit of difference
Dear Dnsop,
Since there has been some discussions around the applicability of
NETCONF (and YANG) on the mailing list and in the form of a (now
expired) draft I though that this could be of interest to the DNSOP
audience.
This is an open invitation for sharing and discussing implementation
an
On Wed, 17 Mar 2010, George Barwood wrote:
>
> I reproduced the problem at 3 different sites, all within the UK.
Works for me from cam.ac.uk. I'm hitting the M instance in Tokyo (!) over
IPv4 and in Paris over IPv6.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5
A small followup:
> So it looks like the IPv4 instance refuses TCP, while the IPv6 instance
> handles it okay. No filters in the way at my end. The m.root-servers.net
> instance looks like it is in Paris or thereabouts - but there is quite
> a bit of difference between the instances: IPv4 (highly
> >> It seems that m.root-servers.net is now serving DNSSEC, but does not have
> >> TCP, so the following queries all fail
> >
> > Well these queries work just fine for me. Perhaps your problems are caused
> > by local misconfiguration such as a broken CPE/middleware box or DNS proxy?
>
> I th
- Original Message -
From: "Jim Reid"
To: "George Barwood"
Cc:
Sent: Wednesday, March 17, 2010 12:23 PM
Subject: Re: [DNSOP] m.root-servers.net DNSSEC TCP failures
> On 17 Mar 2010, at 11:28, George Barwood wrote:
>
>> It seems that m.root-servers.net is now serving DNSSEC, but doe
On Mar 17, 2010, at 5:23 AM, Jim Reid wrote:
> On 17 Mar 2010, at 11:28, George Barwood wrote:
>
>> It seems that m.root-servers.net is now serving DNSSEC, but does not have
>> TCP, so the following queries all fail
>
> Well these queries work just fine for me. Perhaps your problems are cause
On 17 Mar 2010, at 11:28, George Barwood wrote:
It seems that m.root-servers.net is now serving DNSSEC, but does
not have TCP, so the following queries all fail
Well these queries work just fine for me. Perhaps your problems are
caused by local misconfiguration such as a broken CPE/middlew
A little more, from Comcast SF bay area:
Its responding to large EDNS MTUs just fine for me:
dig +dnssec any . @m.root-servers.net
works (4096B MTU)
but with a 512B MTU (no EDNS) it doesn't because there is no working TCP:
dig any . @m.root-servers.net
;; Truncated, retrying in TCP mode.
;; Co
It's a bit weird from here:
TCP queries to m's IPv4 adress are working fine:
dns-test:~ # dig @202.12.27.33 . any
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.7.0-P1 <<>> @202.12.27.33 . any
; (1 server found)
;; global options: +cmd
;; Got answer:
And:
dig @202.12.27.33 hostname.bind ch t
Here is what I get:
dig any . @m.root-servers.net.
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.6.1-P1 <<>> any . @m.root-servers.net.
Thus I think the any-cast instance you are using is the broken one,
I'm talking to the one on the west coast of the US. (SFO ?).
traceroute to m.root-server
m.root-servers.net
is now serving DNSSEC, but does not have TCP, so the following
queries all fail
They works for me but not behind the linksys router of the meeting I'm
currently in.
jaap
___
DNSOP mailing list
DNSOP@ietf.org
It seems that
m.root-servers.net
is now serving DNSSEC, but does not have TCP, so the following queries all fail
dig any . @m.root-servers.net
dig rrsig . @m.root-serves.net
dig any . @m.root-servers.net +dnssec +bufsize=1400
None of these are normal queries, but seems a bit doubtful even so.
20 matches
Mail list logo
