Hi,
On Tue, Apr 13, 2021 at 07:33:53PM -0400, Andrew Sullivan wrote:
> TLD, which seemed like a pretty bad barrier. Then (a) certain large
> delegation-centric zone operator(s) from Europe (it's now kind of
> ironic which the leader was) got a legal opinion that the GDPR would
> raise problems
Doug,
On Tue, Aug 25, 2020 at 07:17:22PM -0700, Doug Barton wrote:
> I'm particularly interested in what elements are available for the new
> platform that were not available for jabber.
how many OARC jabber conversations have you observed or engaged in over
the course of the last year?
-Peter
On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.
this is correct.
On Mon, Nov 25, 2019 at 10:20:17PM +0800, Wesley Peng wrote:
> When I changed name servers in registrar, won’t they be registered into DE’s
> servers automatically? Thank you.
without knowing details about the registrar/reseller chain that you might be
using, informing the registrar of such a
On Mon, May 04, 2015 at 09:11:28AM +0200, Stephane Bortzmeyer wrote:
agency) recommends to prefer delegations with glue because glueless
delegations may carry additional risks since they create a
dependency. Is there any other best practices text which makes such
a recommendation?
On Tue, Apr 14, 2015 at 10:23:26AM +0200, Stephane Bortzmeyer wrote:
https://www.us-cert.gov/ncas/alerts/TA15-103A
http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/
this latest wave started on golem.de
On Fri, Jan 09, 2015 at 07:10:28PM +, Tony Finch wrote:
There is a paragraph about this at
http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#same-key-for-multiple-zones
the argument regarding the extent of a compromise only holds if
you think of cryptanalitic rather than
Hi Alex,
i've been trying to find guidance whether or not the host listed in the MNAME
field of the SOA record is required to have the respective zone signed (when
it is signed on the authoritative servers, and a secure delegation exists at
the parent)? I understand the MNAME host is not
On Sat, Oct 11, 2014 at 10:21:22AM +0100, Simon Munton wrote:
And its been a very sudden change (we can identify the day it started
happening) - which suggests code change, as opposed to a config change
(i.e. it happened in a number of places at about the same time).
no, it may suggest a
On Fri, Oct 10, 2014 at 02:53:38PM +0100, Simon Munton wrote:
I seem to remember someone saying that the latest version of bind starts
with bufsize=512, but presumably it will learn a larger bufsize
capability, if declared by the responding server?
the decreased buffer size is in response
On Fri, Apr 04, 2014 at 09:12:52AM -0700, Edward Lewis wrote:
This all smells like something that the IETF is suited to help with. I mean,
operators, multiple implementations, desires for interoperability...
it appears to me as one of these 'in the privacy of your own
bed^Wimplementation'
-minimisation-01.txt nonwithstanding).
-Peter
--
Peter Koch | | p...@denic.de
DENIC eG| | +49 69 27235-0
Kaiserstraße 75-77 | |
60329 Frankfurt am Main
On Mon, Mar 03, 2014 at 05:26:54PM +, Stephen Malone wrote:
1. In general, can I trust PTR records? Is ownership of the target
domain validated at setup time by ISPs, and if yes, how is this done?
the presence and content of a PTR RR is solely controlled by who ever
controls the
On Mon, Feb 10, 2014 at 03:47:57PM -0800, Mark Boolootian wrote:
I'm interested in knowing if it is standard practice amongst folks to
sign .arpa zones.
probably no more or less than for the forward tree. I find ~ 2000 IN-ADDR.ARPA
and IP6.ARPA zones with key material registered in the RIPE
On Sat, Jan 11, 2014 at 08:49:15AM -0800, Paul Hoffman wrote:
From an operations point of view, this TXT is problematic in that it shows
that the zone operator is willing to break its agreement with ICANN without
notice. They agreed to only put the following in the TLD zone:
? Apex SOA
On Thu, Nov 28, 2013 at 10:16:33AM +0100, Matthijs Mekking wrote:
http://tools.ietf.org/html/rfc6840#section-5.11
I will consult the Updated by clause in the RFC index.
I will consult the Updated by clause in the RFC index.
I will consult ...
to make sure that your zone does not go
On Wed, Nov 27, 2013 at 08:48:05AM -0500, Edward Lewis wrote:
It should be:
There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset that is also in the DS RRset.
The apex DNSKEY RRset
itself MUST be signed by each algorithm
On Thu, Nov 14, 2013 at 03:35:24PM +, Dan York wrote:
I wonder how much they will be able to sell is.sexy for?
last time I looked, Iceland still existed.
-Peter
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
On Thu, Nov 14, 2013 at 06:51:02PM +0200, Daniel Kalchev wrote:
Was it not proven there is no problem... /s
surely not proven, decided maybe. RFC 1535 remains a nice read.
As is
http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf,
therein draft NewgTLD Agreement, page 46
On Wed, Oct 23, 2013 at 04:01:09PM -0400, Edward Lewis wrote:
My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added
between 1800 and 1900 UTC.
-. 86400 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2013102300 1800 900 604800 86400
+.
On Mon, Oct 14, 2013 at 01:24:27PM -0700, Paul Hoffman wrote:
It didn't. That's a useful data point for people creating other protocols who
have to listen to commenters who say where resolvers need to be.
sure. Yet another instance of the DNS people have said Come on.
-Peter
On Fri, Aug 17, 2012 at 01:11:09PM +0200, Faasen, Craig wrote:
Thanks to everyone who responded to the question: any idea why a name server
would want to change the RD bit ?
Consensus is that there is no particular reason and that clients should not
care about the RD bit in responses.
the
On Mon, Jul 16, 2012 at 10:12:28AM +0200, Patrik Fältström wrote:
Done!
thanks.
PS Thanks for the reminder. There are so many /DNS.*op.*/ mailing lists...
yes, and they live in co-existence while serving their respective communities.
The thoughts and input generated here is very helpful also
On Mon, Jul 16, 2012 at 04:49:08PM +0200, Anand Buddhdev wrote:
1a. return REFUSED responses for any zones I haven't loaded;
I'd make a difference between zones supposed to be loaded but not
available (SERVFAIL) vs zones intentionally absent (REFUSED).
1c. return a NOERROR response for zones
24 matches
Mail list logo
