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
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
Here is what I get:
stora:~ 7:55 8 0dig 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
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 txt
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
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 caused by
- Original Message -
From: Jim Reid j...@rfc1035.com
To: George Barwood george.barw...@blueyonder.co.uk
Cc: dnsop@ietf.org
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
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
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 or thereabouts wasn't
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
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
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
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
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::35 hostname.bind ch txt
- Forwarded message from Fred Baker f...@cisco.com -
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
15 matches
Mail list logo
