Re: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use)

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 f

Re: [dns-operations] New OARC Chat Platform

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

Re: [dns-operations] any registries require DNSKEY not DS?

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.

Re: [dns-operations] Questions about my domain's DNS

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 ch

Re: [dns-operations] [Security] Glue or not glue?

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? > >

Re: [dns-operations] Stunning security discovery: AXFR may leak information

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

Re: [dns-operations] Sharing a DNSSEC key between zones

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 operati

Re: [dns-operations] DNSSEC on host listed in MNAME

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 no

Re: [dns-operations] latest bind, EDNS & TCP

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

Re: [dns-operations] latest bind, EDNS & TCP

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

Re: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

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' t

Re: [dns-operations] should recursors think there are only delegation data in tld name servers?

t looking for an existence proof. I'd not recommend to examine all this in a resolver on a routine base. > so it is clear for .de administrator to know the details. And said entity shares these details through whois -h whois.denic.de. " -C

Re: [dns-operations] should recursors think there are only delegation data in tld name servers?

t that's already a questionable deviation from protocol reality (Stephane's draft "draft-bortzmeyer-dns-qname-minimisation-01.txt" nonwithstanding). -Peter -- Peter Koch | | p...@denic.de DENIC eG|

Re: [dns-operations] Trustworthiness of PTR record targets

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 co

Re: [dns-operations] signing reverse zones

On Thu, Feb 13, 2014 at 08:48:02AM +1000, George Michaelson wrote: > Parent assertions can be useful. Signed parent assertions can be useful. > They can include information which materially says "for more information go > " so in principle, they can empower address holders, under a suitable > fram

Re: [dns-operations] signing reverse zones

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 d

Re: [dns-operations] BIND, Knot and NSD behaviour on zone expiry

On Mon, Feb 10, 2014 at 11:52:11PM +0100, Anand Buddhdev wrote: > The zone's operator had accidentally set its serial in the future, and > then set it back, not realising that they should have performed a serial > roll-over. this is the core of the problem. There might be more than one appropriat

Re: [dns-operations] Is it illegal to query the .berlin TLD servers?

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: > ? Ap

Re: [dns-operations] algorithm rollover strategies

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

Re: [dns-operations] algorithm rollover strategies

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 app

Re: [dns-operations] It's begun...

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 , therein draft "NewgTLD Agreement, page

Re: [dns-operations] It's begun...

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 https://lists.dns

Re: [dns-operations] It's begun...

On Thu, Oct 24, 2013 at 01:20:48PM +, Dan York wrote: [1] > >From a DNSSEC-advocacy point of view, this is a great step forward as all > new domains registered under these newgTLDs will at least have the > *option* of being secured by DNSSEC. [2] > Hmmm... interesting. Perhaps some work is s

Re: [dns-operations] It's begun...

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 +.

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

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

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

On Mon, Oct 14, 2013 at 09:08:33AM -0700, Paul Hoffman wrote: > Should that company run its own recursive resolver for its employees, or > should it continue to rely on its ISP? you could as well have asked for the IT staff's average shoe size. Are they running their own AD server? Mail server?

Re: [dns-operations] Problem with ns.uu.net

On Thu, Jun 27, 2013 at 01:34:59PM +0300, Jaana Järve wrote: > is there anybody here who can either confirm or deny that ns.uu.net is not > and has not been answering queries about .int or .ee? correlating your observation with

Re: [dns-operations] getting .CW recognised in the Google ccTLD tables/databases ...

On Mon, Jan 21, 2013 at 08:04:19AM +0530, Jothan Frakes wrote: > I strongly suggest you submit .cw to the public suffix list at mozilla. > > http://publicsuffix.org/submit/ just another sad example where misapplied pragmatism increases the problem instead of solving it. The underlying issue for

Re: [dns-operations] Question about L-Root IP address

Hi Orange, > I remember the official debut date of M-Root is Aug 22, 1997. > In the root hint file: > I'm not sure where the address 198.32.65.12 mentioned in that hints file ... -; temporarily housed at ISI (IANA

Re: [dns-operations] Question about L-Root IP address

Hi Orange, > I checked the past root hint file in Aug 22 1997, > > But its L-Root address is 198.32.64.12, I think it was used until 2007. L was introduced (together with M) with SOA# 1997031300 . 51840

Re: [dns-operations] Pinging the root name servers to check my connectivity?

On Mon, Sep 10, 2012 at 01:09:29PM -0400, Joe Abley wrote: > > RFC 6304 does not "mandate" that AS112 name servers respond to ICMP > > Echo requests. > > Sure. No RFC mandates that the root servers or Facebook respond to ping, > either. no idea about facebook but I'd say that AS112 is even more

Re: [dns-operations] Pinging the root name servers to check my connectivity?

On Mon, Sep 10, 2012 at 12:56:08PM -0400, Joe Abley wrote: > The AS112 servers don't have such good technical properties, but they have > the advantage that they are deployed with an expectation that junk will > arrive. Perhaps PRISONER.IANA.ORG is a reasonable thing to ping. RFC 6304 does not

Re: [dns-operations] "best practices" for restaring internal DNS servers

On Mon, Sep 10, 2012 at 07:38:20AM +1000, Mark Andrews wrote: > Running without a cache at all makes a difference but starting a > caching nameserver has no real impact on the root servers or tld > servers. I would suggest the original poster had taken a much broader view. There is of course an e

Re: [dns-operations] have the .DE and .KR operators read this paper about internet censorship by dns injection?

reproducing, and mitigating - where appropriate - the observations shared in this document. This _is_ work in progress, so i am not in a position to provide details, but we will inform the community once we have tangible results. -Peter -- Peter Koch | |

Re: [dns-operations] SUMMARY: Name server turning off RD bit in response - just curious

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

Re: [dns-operations] Name server turning off RD bit in response - just curious

On 07/08/2012 13:40, Faasen, Craig wrote: > > > Out of curiosity, any idea why a name server would want to change > > > the RD bit ? (except to break an unsuspecting script ;) both RA and RD are uni-directional (and over in the IETF we'll find someone who remembers why it was desigend this way in

Re: [dns-operations] thoughts on DNSSEC

On Wed, Jul 18, 2012 at 08:46:38PM +0200, Jan-Piet Mens wrote: > He or she may have the bright idea of checking at the TLD. A really > marvelous example is to be seen [1] at DENIC, responsible for .DE: > > Q: "How do I find a provider that supports DNSSEC?" > A: "Please contact your domain provid

Re: [dns-operations] Minimalistic DNS server for SOA and AXFR

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

Re: [dns-operations] How to transfer DS records to parent zone?

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 als

Re: [dns-operations] How to transfer DS records to parent zone?

On Mon, Jul 16, 2012 at 06:08:34AM +0200, Patrik Fältström wrote: > So, suggestion is to have a look at the registry/registrar/registrant > business and then write something new. Or, just skip the intention to try to > describe how that market is working and dive into the meat of the document >

Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?

{warning to self: sliding off topic} On Tue, Jun 12, 2012 at 02:46:12PM +, Vernon Schryver wrote: > Besides, local DNSSEC validating, regardless of ISP port 53 blocks, > is the fix for those concerns. not really. It helps "mitigate" lies, but does not reinstantiate access to helpfully suppr

[dns-operations] baby/bathwater [Re: Why would an MTA issue an ANY query instead of an MX query?]

On Tue, Jun 12, 2012 at 03:32:56AM +, Vernon Schryver wrote: > Joe and Joan should be using their ISP's validating, load balancing, > well (or at least somewhat) maintained DNS servers, just as they should > be using their ISP's SMTP systems. I'm sure my government loves you already. Why not

Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?

On Sun, Jun 10, 2012 at 04:24:51AM -0700, Kyle Creyts wrote: > So, list, I am young and foolish. Aside from being in the RFC, are there > legitimate reasons to continue supporting ANY queries? ANY queries are not bad per se, even though their use in production queries is ill advised. Big response

Re: [dns-operations] NS answer inconsistency between implementations for delegated zone

On Fri, Mar 16, 2012 at 04:47:08PM +, Tony Finch wrote: > The relevant text in RFC 2181 section 6.1 is: > > The NS records that indicate a zone cut are the >property of the child zone created, as are any other records for the >origin of that child zone, or any sub-do