Re: [dns-operations] Offline DNSSEC Validation
On Mon, Apr 1, 2024 at 10:37 AM Rithvik Vibhu wrote: > Hi, > > I'm looking for a good way to validate DNSSEC for a chain of records, > offline. I mean: given a list of records including all RRSIGs, NSECs, > etc.), verify that all the signatures match and the whole trust chain leads > to a trust anchor. > > I've seen a few libraries, but at least in golang, most packages either > don't validate DNSSEC on their own (ex: stub resolvers) or the DNSSEC > validation is tightly integrated with the recursor code that handles > querying for any required records. > > Does anyone know of an existing library that only does DNSSEC validation > without resolution? Preferably in go, but any other language will do at > least as reference. > I'm not aware of anything in Go, but getdns (in C) has the function getdns_validate_dnssec() which can do this: https://getdnsapi.net/documentation/spec/#7-more-helper-functions (Code in https://github.com/getdnsapi/getdns/blob/develop/src/dnssec.c ) Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region
On Wed, Jul 19, 2023 at 3:28 AM Shane Kerr wrote: > Shumon and all, > > On 18/07/2023 21.41, Shumon Huque wrote: > > On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni > <mailto:ietf-d...@dukhovni.org>> wrote: > > > > Yes, I agree. A resolver can't really tell that a response with an > > expired signature wasn't an attacker trying to replay old data. For > > robustness against attacks, it must re-query other available other > > servers if they exist. > > I kind of think that a resolver using UDP should just drop a response on > the floor if it has an expired signature. Otherwise an attacker can > induce behavior change by spoofing replies, which is itself a security > problem (in this case, blocking with a response that would arrive later > and work, effectively removing a name server from the set of name > servers queried for a given lookup). > The problem is that in the general case the resolver can't really tell if this was an attack or a misconfiguration. So, it's best to build in robust behavior to deal with the case more generally. Which in my opinion is "drop the response on the floor, maybe blacklist the server for a while, and retry the next server". If a later valid response does come, then be prepared to accept it (if you've still held on to the query). This idea mostly applies to UDP without DNS cookies since it is the only > transport easily vulnerable to spoofing. With other transports you are > much more sure that the answer actually came from the server you are > querying, and so you can be confident that the server is giving out > bogus answers. (TCP is vulnerable to BGP hijacking and the like, but in > that case you would still expect to get bogus answers for subsequent > queries to the same server.) > Well, there are inline attackers as well and DNSSEC is designed to protect against those too. If this only applied to UDP, then other protocols that use connection oriented transport or session oriented frameworks on top of UDP would not bother with cryptographic authentication either. And yet, they all do. Unfortunately I don't think any resolvers hold onto a UDP query until > after the DNSSEC validation. So there is not really much option other > than to try again. 邏 > Yeah, but I don't really see that as a problem. I see concerns have been raised in this thread about the NXNAME attack and such dissuading resolver implementers from more retries, but in my view the only thing that taught us is that resolver implementers need to go back to first principles and sensibly bound the amount of work they are willing to do, not eliminate retries. To quote RFC 1034 (published in 1987): "The recommended priorities for the resolver designer are: 1. Bound the amount of work (packets sent, parallel processes started) so that a request can't get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA." Note: the capitalized phrase for emphasis. (My addendum: they should also bound the time spent.) Transient configuration problems are _pervasive_ in deployed DNS infrastructure. If BIND for example did not have the robust retry behavior that Mark Andrews documented upthread, we could never have used them in our infrastructure. In my experience Unbound also had the same robustness, but I'm now a little concerned by the description of the Unbound failures reported by Gavin M during this Verisign incident. Maybe they have limited retries too aggressively? It would be good to get some NLnetLabs colleagues to chime in with a description of their behavior. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region
On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni wrote: > On Tue, Jul 18, 2023 at 08:54:04PM +0200, Ondřej Surý wrote: > > > With my implementor’s hat on, I think this is wrong approach. It > > (again) adds a complexity to the resolvers and yet again based > > (mostly) on isolated incident. I really don’t want yet another > > “serve-stale” in the resolvers. I have to yet see an evidence that > > serve-stale has helped anything since the original incident, but now > > every resolver has to have it because people want it. > > How is this akin to "serve stale"? We're talking about retrying > response that fail to validate, just one might/would retry a response > that is "REFUSED", "SERVFAIL", has TC=1 over UDP, contains garbage, ... > > The "serve stale" situation is quite different, here substantial new > logic is required, whereas with invalid responses, it is just a matter > of trying the next server up to some reasonable work limit. > > Retries to reach a better authoritative server are core element of DNS > resilience in the face if inevitable partial degradation of service. > Yes, I agree. A resolver can't really tell that a response with an expired signature wasn't an attacker trying to replay old data. For robustness against attacks, it must re-query other available other servers if they exist. Also, I was under the impression that most resolvers already had this robust behavior. Since Unbound was mentioned, I just tested an unbound resolver against a test DNS record that I have provisioned with an intentionally expired DNSSEC signature - it sent queries to all 4 servers for the zone before giving up and returning SERVFAIL. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare TYPE65283
On Tue, Mar 28, 2023 at 6:19 AM Viktor Dukhovni wrote: > > A possibly inconvenient question, just to make sure we're not ignoring > the obvious sceptical position: > > * How compelling are compact lies? > > The reason to ask is that both the original and now modified protocols > involve non-trivial complexity, and would have resolvers responding > differently to queries with the DO bit set (tell them the truth) vs. > queries that don't request validated answers (unmask the lie). > > The savings vs. actual by-the-book NSEC responses appear to be a 2x > reduction in the number of signatures to compute (the SOA RRSIG is > presumably easily cached) and a 1.5x reduction in the number of > signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC). > > Do the CPU and packet size reductions justify the additional protocol > complexity? > That's a reasonable question, and perhaps best directed to the originators of the scheme at Cloudflare. I don't know if there have been any measurement studies or analyses of the cost benefits vs by-the-book DNSSEC. There are currently 3 large commercial DNS providers that have had it deployed for a while now, so I suspect that it is here to stay. Note that one other provider (UltraDNS) does support traditional NSEC White "Lies" that give by-the-book DNSSEC proofs for NXDOMAIN, so apparently they are bearing the additional costs just fine. One other point -- without the additional rcode substitution schemes under discussion, Compact Answers can cause additional work for authority servers, since NODATA responses may lead to follow-on queries by DNS client applications (e.g. the common followed by A pattern). So, the per-response crypt & size reductions need to also be weighed against the cost of these additional queries. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare TYPE65283
On Tue, Mar 28, 2023 at 12:16 AM Viktor Dukhovni wrote: > On Mon, Mar 27, 2023 at 04:28:30PM +0200, Emmanuel Fusté wrote: > > > > definitely does not exist. The issue I take it that the > > > sentinel-free: > > > > > > nxdomain.example. IN NSEC \0.nxdomain.example. RRSIG NSEC > > > > > > which is an ENT per: > > > > > > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01#section-3.2 > > > > > > may for some time be ambiguous while still used for NXDOMAIN by earlier > > > implementations. For that, sure, we should encourage those > > > implementations to adopt whatever becomes the published protocol at > > > their earliest convenience (realistically a year or two based on prior > > > experience nagging operators to resolve compliance issues). > > > > Thank you Viktor. > > That confirm my understanding and my analysis in my answers to Petr. > > Do you have a list of operators that currently return just "RRSIG NSEC" > for ENTs? Do you what software they are running? > > On the fly signing with compact denial of existence is a bleeding-edge > behaviour, and one might expect that the software in question is not > ossified and operators might be proactive. So with a bit of luck any > ambiguity might be resolved before long. > > The only other option is to introduce yet another sentinel that signals > that the node in question is an ENT, so that the bare "RRSIG NSEC" > combination is ultimately never used. > > And, FWIW, the sentinel value will surely need to change (once a better > codepoint is assigned). The current 0xff03 is in the private-use range. > I've spoken to both NS1 and Route53, and both are amenable to adjusting their implementations to support the changes specified in draft-huque-dnsop-compact-lies. So, we hope that the end result will be that all known implementations of compact lies will support this common mechanism to distinguish NXDOMAIN vs ENT vs (other) NODATA. If there are any other implementations of Compact Lies that folks are aware of, we should make them aware of this and bring them into the fold. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Looking for zones using white lies (RFC 4470)
On Fri, Jan 27, 2023 at 11:16 AM Paul Ebersman < list-dns-operati...@dragon.net> wrote: > shuque> UltraDNS (Neustar Security Services) is known to use NSEC White > shuque> Lies. I have a test zone there, > > shuque> which you can examine: "[[ultratest.huque.com]]". > > My recollection is that the NSS implementation is really grey lies, > i.e. not quite RFC white lies but not fully black like cloudflare. > Paul - what's the definition of "grey lies"? The UltraDNS implementation doesn't use the more precise white lies epsilon function defined in the spec, but it is probably good enough for all practical purposes. And it's much closer to white lies than "black" lies, because it preserves the correct semantics of NXDOMAIN. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Looking for zones using white lies (RFC 4470)
On Fri, Jan 27, 2023 at 3:39 AM Stephane Bortzmeyer
wrote:
> On Fri, Jan 27, 2023 at 12:19:18AM -0500,
> Viktor Dukhovni wrote
> a message of 30 lines which said:
>
> > Three sample zones:
>
> They all seem to use black lies, not white lies.
>
I took a quick look:
* herokudns.com is definitely "black" ("minimal"?) lies, hosted on NS1,
which uses that method.
* cfcualerts.com appears to use normal pre-computed NSEC3.
* technohazard.io - no idea; my attempts at eliciting negative responses
result in SERVFAIL.
UltraDNS (Neustar Security Services) is known to use NSEC White Lies. I
have a test zone there,
which you can examine: "ultratest.huque.com".
$ dig +dnssec foobar.nxd.ultratest.huque.com. A +noall +authority
!~.nxd.ultratest.huque.com. 1792 IN RRSIG NSEC 13 5 1800
20230722123724 20230123123724 39543 ultratest.huque.com.
q+TWfjkPmlWs/xVBsZu3kiWyhUqcZJWjq2U28BVoLcT8kCacqjRF1NKM
qEss4HsL9VxpAlq7AfRarczZwNtBaA==
!~.nxd.ultratest.huque.com. 1792 IN NSEC-.nxd.ultratest.huque.com.
RRSIG NSEC
foobaq~.nxd.ultratest.huque.com. 1792 IN RRSIG NSEC 13 5 1800
20230722123724 20230123123724 39543 ultratest.huque.com.
UM1w+ZxUTUXCZ/T8xD5cOHOgrJaBHJM7UPFTOs4UlMjkbRcK3L7eEn8M
/36nCgTfQNk+cllamUqr5CJ+FuUDFw==
foobaq~.nxd.ultratest.huque.com. 1792 IN NSEC foobar!.
nxd.ultratest.huque.com. RRSIG NSEC
ultratest.huque.com.1792IN SOA dns01.salesforce.com.
hostmaster.salesforce.com. 2019101692 1800 900 2592000 1800
ultratest.huque.com.1792IN RRSIG SOA 13 3 1800
20230722123724 20230123123724 39543 ultratest.huque.com.
6nhsLNAUv0TYiA6Gp0evnicallUmMEsr0T9qK3GvmkxVy+8FC9v2DsUR
rp+o7/QMjKl+dvYncQcIspRZmUlgZw==
Shumon.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
On Mon, Jan 17, 2022 at 9:04 AM Ulrich Wisser via dns-operations < dns-operati...@dns-oarc.net> wrote: > > -- Forwarded message -- > From: Ulrich Wisser > To: Mark Andrews > Cc: Shreyas Zare , Greg Choules via > dns-operations > Bcc: > Date: Mon, 17 Jan 2022 15:01:36 +0100 > Subject: Re: [dns-operations] DNSSec validation issue for .se (missing > denial of existence for *.se) > This is of course very interesting for us (at .se). > I tried this with all our dns servers and all give the same answer. > But I tend to agree that a proof for the non existence of the wildcard > should be there. > > I am thinking of a domain setup as: > > *.example.com. TXT “wildcard” > 0.example.com. TXT “zero” > test.a.example.com. TXT “test.a” > > What answer should “dig +dnssec a.example.com txt” give? > > I would say “wildcard”. And if that is the case, shouldn’t it then send an > extra sec in case there is no wildcard record? > Actually, no Ulrich, a query for "a.example.com" in your example will not match the wildcard, since the node "a.example.com" positively exists (as an empty non-terminal with a descendant node, test.a.example.com, that has data). The DNS name matching algorithm is label by label inspection from the top down (see RFC 1034, Section 4.3.2). c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a the "*" label exists. (At this stage in your example, a match is found) Hence, no wildcard non-existence proof is needed. Those are needed only for NXDOMAIN responses, where we you have to additionally prove that although the name did not explicitly exist, a response for it could not have been synthesized by a wildcard. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSSec validation issue for .se (missing denial of existence for *.se)
Hannes, This is a NODATA response for an empty non-terminal, so no wildcard non-existence proof is needed. The following NSEC record demonstrates that "a.se" is an empty non-terminal: _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC Shumon. On Tue, Jan 11, 2022 at 10:58 AM Hannes Mehnert wrote: > Hi DNS operators, > > since this is my first mail here, I first would like to thank you all > for the constructive discussions and technical expertise. I'm developing > a DNS suite in OCaml, a statically typed functional programming language > [see https://github.com/mirage/ocaml-dns // https://mirageos.org if > interested], and have learned a lot from lurking on this list. My > current work item is a recursive resolver. > > When I just implemented the denial of existence for DNSSec (with NSEC), > I stumbled upon the TLD .se that uses NSEC. I mailed earlier to > registry-default at nic dot se (the hostmaster in the SOA of .se), but > didn't get a reply. > > Of course, I may be wrong with my analysis, if this is the case please > help me to understand how this should work. > > I'm wondering how other validators (public resolvers) deal with the > following issue, which is a missing denial of existence for *.se: So, a > request for resource record type A, domain name a.se results in the > following: > > $ dig +dnssec a.se > > se. 5363IN SOA catcher-in-the-rye.nic.se. > registry-default.nic.se. 2022010921 1800 1800 864000 7200 > se. 5363IN RRSIG SOA 8 1 172800 > 20220122054639 20220109191050 30015 se. [...] > _nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC > _nicname._tcp.se. 6694IN RRSIG NSEC 8 3 7200 > 20220121191006 20220108001053 30015 se. [...] > > Which provides a non-existence proof for everything between > _nicname._tcp.se and acem.a.se, but nothing for *.se (which according to > the order of canonical domain names, is before _nicname._tcp.se -- even > before 0.se that seems to be the first registered domain name). > > The NSEC record missing from the reply above is the following NSEC and > RRSIG ($ dig +dnssec ns \!.se). > > se. 4353IN NSEC0.se. NS SOA TXT RRSIG > NSEC DNSKEY > se. 4353IN RRSIG NSEC 8 1 7200 > 20220121132017 20220108061050 30015 se. > jzWI5l5Sxyb2sOLzCWNX06nwmCtZuFdS3PvmivnyOPVZ3cw+blBXNYwN > cFCYFdMC7R31W0ABBuT587mAm7Ae5NJX2GnXGcNgaVcD9VhKWAjJHpqf > +NJcLOF9771m/BKPC7dKTwt/zVdKJSwFjaYTr0streS9OMCnJXbiWaQc > CMDmzko2WiWdBNDAbZ8H/OfKymYjgJz1hZynMdl5LyWcGgxlOksuLKSv > 4xg4Ey07r4ZCy5XTQwfHG74qWa+61BVjfP3KEEEB42B0rZX8lT15B9MS > Cg9RmBObNC5FYjXGkbeik6iXrdOGzUUURHay+th9SJ4BGIFIV8fyyDTd oxOc5w== > > > Thank you for reading, > > Hannes Mehnert > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)
On Tue, Jan 19, 2021 at 8:44 AM Viktor Dukhovni wrote: > > Sorry for leaving this vague. Changing the salt requires rebuilding the > entire NSEC3 chain, and so is difficult to combine with incremental zone > signing (such as BIND's "auto-dnssec maintain"). If you're doing > periodic whole zone signing, which reconstructs the entire chain, you > can change the salt at will each time the zone is signed from scratch. > > If, on the other hand, the zone is signed incrementally as individual > records are modified, then there is not an opportunity to change the > salt, which needs to be consistent across the entire chain. > It should work with incremental signing too. I haven't actually tried it with BIND's 'auto-dnssec maintain' - perhaps ISC folks can confirm. The way it should work is that you tell the BIND signing server that you're updating the NSEC3 parameters (by dynamic update or issuing an 'rndc' control command). It will then in the background rebuild a second complete NSEC3 chain. While doing this, it will temporarily house the NSEC3PARAM data in a private record (so that the auth servers don't instantly start using that chain to construct negative responses), and will only make that visible in the apex NSEC3PARAM record once the chain has been fully built. You can then delete the old NSEC3PARAM. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] is anybody awake at 5.0.1.0.0.2.ip6.arpa? (comcast and/or arin)
On Mon, Oct 5, 2020 at 11:22 PM Mark Andrews wrote: > > On 6 Oct 2020, at 13:18, Paul Vixie wrote: > > > > ssh gets hinky when i connect from a server whose PTR is "servfail" > (dnssec "bogus") > > > > • 5.0.1.0.0.2.ip6.arpa to 9.5.5.0.1.0.0.2.ip6.arpa: No valid > RRSIGs made by a key corresponding to a DS RR were found covering the > DNSKEY RRset, resulting in no secure entry point (SEP) into the zone. > (68.87.68.244, 68.87.72.244, 68.87.76.228, 68.87.85.132, 69.252.250.103, > 2001:558:1004:7:68:87:85:132, 2001:558:100a:5:68:87:68:244, > 2001:558:100e:5:68:87:72:244, 2001:558:1014:c:68:87:76:228, > 2001:558:fe23:8:69:252:250:103, UDP_-_EDNS0_4096_D_K) > > I have no idea why DNSVIZ is reporting this NSEC record (?) given there is > a DS RRset. The covering NSEC record for 9.5.5.0.1.0.0.2.ip6.arpa that > would prove the non existence of the DS RRset if it didn’t exist is > 9.5.5.0.1.0.0.2.ip6.arpa. I suspect a DNSVIZ bug here. > Sorry Mark - where do you see dnsviz complaining about an NSEC record? This error message says that no "valid" DNSKEY RRSIGs made by a key matching the DS RRset were found -- which is a correct diagnosis. No NSEC records are involved in that determination. As you've already pointed out, DNSKEY with keytag 47242 has an expired signature on the DNSKEY RRset. Key 30705 has a valid unexpired signature but that does not match the DS set (it also doesn't have the advisory SEP flag, so was likely not intended to be used as a secure entry point). Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare (and perhaps also Google) public DNS sometimes forwards incomplete subset of NSEC RRs
On Tue, Sep 1, 2020 at 4:24 AM Viktor Dukhovni wrote: > On Tue, Sep 01, 2020 at 01:48:17AM -0400, Viktor Dukhovni wrote: > > > > @ 1.1.1.1 _25._tcp.mx.runbox.com. IN TLSA ? ; +cd +dnssec > [...] > > So I'm at a loss to explain what's happening... Haven't seen any > anomalous replies yet from either VRSN or Quad9. > It looks to me like a bug in Cloudflare and Google, and we probably need to await their response to figure out what's going on. Cloudflare omits the wildcard NODATA NSEC, and Google omits the no closer match NSEC. Both are required. Interestingly, they both set AD=1, so perhaps internally they authenticated the full NSEC set. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Test Zone Metalist
On Thu, Jun 4, 2020 at 10:05 AM Matthew Pounsett wrote: > On the suggestion of some community members, I’m considering setting up a > list of known DNS test zones to be posted on OARC’s web site. The list > will include zones designed to provide data to use as input to DNS software. > > Off the top of my head, and with five minutes of googling, I know of only > two: > > test.dnssec-tools.org <https://dnssec-tools.org/testzone/> > workbench.sidnlabs.nl <https://workbench.sidnlabs.nl/> > > This seems to be one of those subjects that is hard to search; I’m mostly > getting test *software* in my search results. > > What other zones should be on such a list? Hi Matt, These don't appear to be listed on the rootcanary project's website ( rootcanary.org), but Willem Toorop recently made me aware that they have a set of DNSSEC test zones of the form "dNaNnN.rootcanary.net", where: dN: DS digest algorithm number aN: algorithm number nN: NSEC version (1 or 3) So, the zone "d2a15n3.rootcanary.net" has a DS record with hash algorithm 2 (SHA256), is signed with algorithm 15 (EdDSA25519), and uses NSEC3, etc. -- Shumon Huque ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Anyone from Google here?
On Mon, May 11, 2020 at 1:48 PM Robert Evans via dns-operations < dns-operati...@dns-oarc.net> wrote: > From: Robert Evans > On Fri, Apr 17, 2020 at 1:23 PM Robert Evans wrote: > >> [...] >> >> Not sure the motivation for why the server does that, but I agree it >> should be NOERROR or NXDOMAIN for all RTYPEs that don't exist including >> unknown ones. We're looking into this and will get back to you. >> > > Following up here: I've confirmed this behavior is an oversight and will > be corrected in an upcoming server release. > Hi Bob, I just want to elaborate on one important point from Mark's earlier response. For the query in question (google.com, type 1001), the response should be NOERROR, and not NXDOMAIN (the name google.com exists, so the response cannot be NXDOMAIN, regardless of what query type was issued). Specifically, it should be a "NODATA" response (response code: NOERROR, an empty answer section, and a SOA record in the Authority section). More generally, if the domain name exists (either because it has other RR types associated with it, or if it has none but has descendent nodes that do have RRsets), then the response must be NODATA. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSSEC Signatures failed in Top-Level Domain fr.
On Mon, May 4, 2020 at 3:41 PM Martin Wismer wrote: > Hello, Bonjour, > > I noticed, that the DNSSEC signed Domains under top-Level Domain fr. > failed since about 4 hours. > > Example Domains: > m6replay.fr. > climato-realistes.fr. > langue-au-chat.fr > sully-group.fr > > Could anybody please fix this? > Does anybody else also noticed this? > Thanks or merci beaucoup. Greetings > Martin.Wismer. > Yes, I notice the same. The signature on the DS RRset for these zones (in the .fr parent) has expired (May 4 15:19:46 2020 UTC for the first). Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail
On Thu, Apr 23, 2020 at 2:25 AM Viktor Dukhovni wrote: > On Mon, Apr 20, 2020 at 11:55:38AM +0100, Christian Elmerot wrote: > > > On 2020-04-19 07:55, Viktor Dukhovni wrote: > > > The CloudFlare auth servers return ServFail for the TLSA lookup of: > > > > > > https://dnsviz.net/d/_25._tcp.mx01.mx-hosting.ch/XpvvXg/dnssec/ > > > https://dnsviz.net/d/_25._tcp.mail.markleenen.eu/Xpvvcg/dnssec/ > > > https://dnsviz.net/d/_25._tcp.box.nobodyghost.net/Xpvvow/dnssec/ > > > > Those ServFails are being looked into as that is something different and > > a bug I believe. I'll get back with more information when the issue's > > been identified in our pipeline. > > Great, thanks. Not yet resolved FWIW: > > http://dnssec-stats.ant.isi.edu/~viktor/dnsviz/cloudflare.com.html I didn't see the reason for the SERVFAIL in the dnsviz output. So I ran my own debugging tool on these domains. All the CF servers for the zone are unresponsive to DNS queries for the TLSA record at those names. I assume that's why we get SERVFAIL. They respond to other queries fine such as apex SOA, A, etc): Abbreviated transcript from the first: [...] # QUERY: _25._tcp.mail.markleenen.eu. TLSA IN at zone eu. address 194.146.106.90 #[SECURE Referral to zone: markleenen.eu. in 0.080 s] ZONE: markleenen.eu. NS: darl.ns.cloudflare.com. 173.245.59.98 2606:4700:58::adf5:3b62 NS: tegan.ns.cloudflare.com. 173.245.58.226 2606:4700:50::adf5:3ae2 DS: 2371 13 2 23de654eeaae6a7acf8192d2604cdaad5b0ae6abc4dc6456e89559fb5d7a19f0 DNSKEY: markleenen.eu. 257 2371 ECDSA-P256 (13) 512-bits DNSKEY: markleenen.eu. 256 34505 ECDSA-P256 (13) 512-bits # QUERY: _25._tcp.mail.markleenen.eu. TLSA IN at zone markleenen.eu. address 173.245.59.98 WARN: UDP query timeout for 173.245.59.98 WARN: UDP query timeout for 173.245.59.98 # QUERY: _25._tcp.mail.markleenen.eu. TLSA IN at zone markleenen.eu. address 2606:4700:58::adf5:3b62 WARN: UDP query timeout for 2606:4700:58::adf5:3b62 WARN: UDP query timeout for 2606:4700:58::adf5:3b62 # QUERY: _25._tcp.mail.markleenen.eu. TLSA IN at zone markleenen.eu. address 173.245.58.226 WARN: UDP query timeout for 173.245.58.226 WARN: UDP query timeout for 173.245.58.226 # QUERY: _25._tcp.mail.markleenen.eu. TLSA IN at zone markleenen.eu. address 2606:4700:50::adf5:3ae2 WARN: UDP query timeout for 2606:4700:50::adf5:3ae2 WARN: UDP query timeout for 2606:4700:50::adf5:3ae2 Queries to all servers for zone markleenen.eu. failed. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Validation anomalies under gpo.gov
On Fri, Apr 3, 2020 at 4:54 PM Viktor Dukhovni wrote: > > The AD=1 replies from Google and Verisign are not "wrong". They just > reflect the fact that any ancestor zone is in principle free to bypass > delegation and return "unexpected" signed answers for a child domain, > legitimately or otherwise. In this case, I think the explanation might be a bit simpler. The parent zone isn't really bypassing anything. The behavior is likely a result of the fact that both the parent (gpo.gov) and child (access.gpo.gov) are served by the same set of nameservers. An incoming query containing the full qname (as opposed to qname minimization), will cause most authoritative servers to find the closest enclosing zone for the query (i.e. the child zone) and answer directly from that. And since the signer for permanent.access.gpo.gov is claimed to be gpo.gov, it validates, and the broken delegation isn't even being seen. Cloudflare I believe does qname minimization, so is likely reacting to discovery of the broken delegation. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] OpenDNS, Google, Nominet - New delegation update failure mode
On Fri, Apr 3, 2020 at 1:55 PM Puneet Sood wrote: > On Fri, Apr 3, 2020 at 1:53 PM Paul Hoffman > wrote: > > > > Shouldn't this part of the thread (proposed changes base on an Internet > Draft) be in the DNSOP WG in the IETF? Said another way, if you don't move > it there soon, when the topic appears there, you'll have to repeat > yourselves. > > +1. From Google Public DNS perspective, I also have thoughts on this > topic. Would prefer to discuss on the dnsop WG list. > Yes, sure. I was actually planning to post it there in the run up to IETF107, but then the pandemic derailed everything, and I forgot about it, until the topic showed up here, so .. Rather than posting it now just before the weekend, I'll wait til Monday - more likely that people will read and pay attention. Thanks for the nudge Paul! Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
On Fri, Apr 3, 2020 at 11:59 AM Ralf Weber wrote: > Well it was you think and others (including me) disagree for valid reasons. > There is absolutely no reason to issue queries for some validation, when > you already got good results. > > I see this is a workaround for people to lazy to update the delegations, > and put more complexity and work on resolvers. > Dear Ralf, It is possible that there exist some people who want this because they are "too lazy" to update delegations. But I strongly suspect there are other reasons. Let me explain why I am personally interested in having this behavior implemented widely. We can take care to make sure the contents of parent/child NS sets are always in sync (and we do). What we cannot control is the TTL value of the NS RRset in the parent. Many TLDs are quite inflexible in this regard and only support long (~2 day) TTLs. (I know some people will immediately say let's fix this. But we have to live in the real world of TLDs. Folks have been asking for this forever, and there has been no movement. And if there is movement, that will happen on the timescale of many years or longer). Normally, this is not an issue for us, as we prefer long TTLs on zone infrastructure records for stability and performance reasons. The issue arises when we are making changes to the infrastructure, such as migrating to another DNS provider, or deploying DNSSEC etc. We want to make sure we can very quickly backout changes if we encounter unanticipated problems, by temporarily deploying a short TTL. To give you a real case, some time last year, we signed and migrated some of our important zones to a set of new providers, after extensive testing (verifying the zones were correctly deployed and signed, detailed pre-delegation testing, distributed monitoring of the provider footprints etc). A couple of days after pulling the trigger, we discovered breakage in a particular region of the world where one of the provider's servers were misconfigured. We weren't able to catch this pre-deployment, since our distributed monitoring did not include nodes in the anycast catchment area(s) of these broken servers. So, we had to backout the change, and then deal with the lingering up-to-2-day effect of the parent NS TTL (for parent centric resolvers). To fend off these kinds of issues, there are some well known infrastructure operators that configure their resolvers to enforce a maximum cache TTL of only 60 seconds. Should we be advocating things like that? :) (There is a larger philosophical question that I will avoid for now, about why resolvers should prefer non-authoritative glue, which cannot be signed, over signed authoritative data, and whether or not we should redesign the DNS delegation mechanism to fix that. The security of DNSSEC does not currently rely on signed nameserver records, but why not try to catch spoofed delegation data as early as possible, at its source?). Shumon Huque ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records
On Fri, Apr 3, 2020 at 8:20 AM Stephane Bortzmeyer wrote: > On Fri, Apr 03, 2020 at 07:48:16AM -0400, > Shumon Huque wrote > a message of 98 lines which said: > > > The second one, doesnotexist.monitor.itconsult.net., does not appear > to be > > delegated from its parent. > > This is not what I see. Both are delegated from itconsult.net > (source: their SOA). > Ah, yes. The subtlety here (which I didn't notice at first) is that monitor.itconsult.net is served by the same name servers as its parent. Since most authority servers answer from their closest enclosing zone, most iterative debugging tools like dig+trace etc won't see the delegation. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
On Thu, Apr 2, 2020 at 5:10 PM Brian Somers wrote: > FWIW, OpenDNS/Umbrella/Cisco will use the glue to look things > up and won’t explicitly ask the authority for its own NS record. > > However, if we’re asked for an NS record by a client, we’ll lookup > & return the authoritative answer and that answer will trump the glue. > We’ll never serve glue to a client. > > One of the problems with caching NS records is that you’ve got to be > careful that you don’t let them keep re-asserting their own presence > in the cache (by repeating their RRset in the AUTH section every time > you talk to them). We do *force* their eventual TTL decay, but > for frequently queried domains, the original glue TTL is *not* honoured > due to the authoritative RRset trumping it! > Folks may be interested in this proposal, Paul Vixie, Ralph Dolmans, and I have been working on, to cause resolvers to deterministically prefer the child NS set, while avoiding the problem you mention in the last paragraph: https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 I realize some implementers (Petr Spacek?) do not agree, but on balance we think this is what resolvers should do. Shumon Huque. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records
On Fri, Apr 3, 2020 at 7:35 AM Matthew Richardson wrote: > I am observing responses from particular authoratitive servers for > non-existant domains, which is puzzling me. I thought I understood this > topic, but am now having doubts... > > Consider two (real) non-existant records (which are not empty non-terminals > - there is nothing below them):- > > doesnotexist.mtgmon.itconsult.net > doesnotexist.monitor.itconsult.net > > where mtgmon.itconsult.net & monitor.itconsult.net are delegated to > different authoratitives. > > Querying each against the authoratitives returns NOERROR with "ANSWER: 0" > for the first one and NXDOMAIN for the second, behaviour which is > consistent across all the authoratitives:- > The second one, doesnotexist.monitor.itconsult.net., does not appear to be delegated from its parent. That's why you're getting NXDOMAIN - that response is coming from the parent zone: itconsult.net. >> Query: doesnotexist.monitor.itconsult.net. A IN at zone itconsult.net. >> Send to zone itconsult.net. at address 193.201.42.1 ERROR: NXDOMAIN: doesnotexist.monitor.itconsult.net. not found Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Extended Submissions Deadline: 33rd DNS-OARC Workshop, Paris, France, May 09 - 10th 2020
On Mon, Mar 9, 2020 at 2:41 PM Paul Vixie wrote: > On Monday, 9 March 2020 14:44:09 UTC Shumon Huque wrote: > > ** We have extended the submissions deadline for the 33rd DNS-OARC > > ** workshop to March 19th 2020 (midnight CEST). > > > > The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche > > Hotel & Conference Center in Paris, France on May 9th and 10th 2020. It > > is co-located with and will take place right after the ICANN GDD (May > > 3rd to 6th), Registrations Operations Workshop (May 6th) and ICANN DNS > > Symposium (May 7th and 8th). > > > > ... > > Early May is going to be a very bad time: > > https://threadreaderapp.com/thread/1236095180459003909.html > > i suggest ICANN and DNSOARC be ready to convert to virtual for this. > Yeah, I'm aware that contingencies are being actively discussed. But I'll defer to OARC and ICANN staff to officially comment. Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Extended Submissions Deadline: 33rd DNS-OARC Workshop, Paris, France, May 09 - 10th 2020
** We have extended the submissions deadline for the 33rd DNS-OARC ** workshop to March 19th 2020 (midnight CEST). The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche Hotel & Conference Center in Paris, France on May 9th and 10th 2020. It is co-located with and will take place right after the ICANN GDD (May 3rd to 6th), Registrations Operations Workshop (May 6th) and ICANN DNS Symposium (May 7th and 8th). The Workshop's Program Committee is requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. Poster submissions are also welcome. There will be an OARC Business session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 10 Jan 2020 - Submissions open via Indico 19 Mar 2020 - Extended Deadline for submission (midnight CEST) 20 Mar 2020 - Initial Contribution list published 02 Apr 2020 - Full agenda published 02 May 2020 - Deadline for slideset submission 09 May 2020 - Workshop begins Details for presentation submission are published here: <https://indico.dns-oarc.net/event/34/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Shumon Huque, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. OARC is aware of concerns around the ongoing novel Coronavirus outbreak and how that may potentially affect travel. More details are available at: https://indico.dns-oarc.net/event/34/page/93-covid-19-situation (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] c.root-servers.net over IPv6
Didn't we discuss this recently? I assume this is the Cogent<->Hurricane Electric IPv6 peering issue. See the long thread that starts here (short summary: dnsviz is singly homed to HE so can't reach Cogent IPv6 servers): https://lists.dns-oarc.net/pipermail/dns-operations/2019-October/019276.html Shumon. On Mon, Feb 3, 2020 at 3:14 PM SM wrote: > Hello, > > c.root-servers.net (2001:500:2::c) is not responding to queries over IPv6 > [1]. > > Regards, > -sm > > 1. The error from DNSViz is "arpa zone: The server(s) were not > responsive to queries over UDP. (2001:500:2::c)" > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Extended Submission Deadline for 32nd DNS-OARC Workshop
Hi folks, In order to help us construct the best program we can for OARC32, we are still soliciting a few more submissions, and have extended the submission deadline by one week, to December 16th (midnight PST): The 32nd DNS-OARC Workshop will take place at the Hyatt Regency San Francisco in San Francisco, California, USA on February 8th 2020. It is co-located with and will take place right before NANOG 78 (Feb 10th to Feb 12th 2020). The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. Workshop Milestones: 28 Sep 2019 - Submissions open via Indico 16 Dec 2019 - Extended deadline for submission (23:59 PT) 20 Dec 2019 - Initial Contribution list published 03 Jan 2020 - Full agenda published 24 Jan 2020 - Deadline for slideset submission 08 Feb 2020 - Workshop Details for presentation submission are published here: <https://indico.dns-oarc.net/event/33/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee via submissi...@dns-oarc.net Shumon Huque, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Call for Presentations: 32nd DNS-OARC Workshop, San Francisco, CA, Feb 08 2020
Hi folks, The 32nd DNS-OARC Workshop will take place at the Hyatt Regency San Francisco in San Francisco, California, USA on February 8th 2020. It is co-located with and will take place right before NANOG 78 (Feb 10th to Feb 12th 2020). The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. Workshop Milestones: 28 Sep 2019 - Submissions open via Indico 07 Dec 2019 - Deadline for submission (23:59 PT) 20 Dec 2019 - Initial Contribution list published 03 Jan 2020 - Full agenda published 24 Jan 2020 - Deadline for slideset submission 08 Feb 2020 - Workshop Details for presentation submission are published here: <https://indico.dns-oarc.net/event/33/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee via submissi...@dns-oarc.net Shumon Huque, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] glitch on [ip6|in-addr].arpa?
On Fri, Oct 11, 2019 at 4:12 PM Warren Kumari wrote: > On Fri, Oct 11, 2019 at 9:00 PM Joe Abley wrote: > >> >> What some people are seeing in this thread as a problem is actually a >> nice demonstration that the system as a whole is immune to damage due to >> partial-table peering disagreements. > > > Indeed. > W > I certainly agree that the Cogent-HE IPv6 peering dispute poses no reliability or availability problems for the DNS root service. But what impact might it have on individual services, organizations, and other smaller entities? Since the Internet is still IPv4 omni-present, and only partially IPv6, it probably doesn't matter at all to most. It might be much more important for diagnostic and measurement services like DNSviz though. At the moment, if you run IPv6 DNS servers on networks that are singly connected to Cogent, it will probably incorrectly flag those servers as unavailable. For such services, perhaps it would be better if they were not single-homed to either Cogent or HE. (To be clear, I'm happy that DNSviz is housed at OARC. So, I guess I might be suggesting that the community might consider how to fund a second ISP connection for OARC). -- Shumon Huque ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Lack of tlsa support
: Wed May 27 15:50:57 EDT 2015 ;; MSG SIZE rcvd: 108 ns5.dns.nic.accountant. 156.154.157.195 ; DiG 9.10.1 @156.154.157.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns5.dns.nic.accountant. 2610:a1:1075::c3 ; DiG 9.10.1 @2610:a1:1075::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 56808 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 13 msec ;; SERVER: 2610:a1:1075::c3#53(2610:a1:1075::c3) ;; WHEN: Wed May 27 15:51:12 EDT 2015 ;; MSG SIZE rcvd: 108 ns6.dns.nic.accountant. 156.154.158.195 ; DiG 9.10.1 @156.154.158.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns6.dns.nic.accountant. 2610:a1:1076::c3 ; DiG 9.10.1 @2610:a1:1076::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 40030 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 1 msec ;; SERVER: 2610:a1:1076::c3#53(2610:a1:1076::c3) ;; WHEN: Wed May 27 15:51:27 EDT 2015 ;; MSG SIZE rcvd: 108 -- Shumon Huque ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Lack of tlsa support
On Wed, May 27, 2015 at 3:59 PM, Shumon Huque shu...@gmail.com wrote: Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): Actually, I was wondering why those answers are NODATA rather than NXDOMAIN since presumably there aren't other record types at the name I queried. It looks like this is because this zone is in the controlled interruption mode (it has a wildcard at the apex for A, MX, etc). Shumon Huque. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] An simple observation
On Wed, Sep 24, 2014 at 9:27 PM, Davey Song songlinj...@gmail.com wrote: Hi everyone, I‘m recently doing a little survey on the penetration of IPv6 in DNS system and it's latent problems. I find that top websites like Google, Wikipedia,Yahoo already support IPv6 access, but its name servers are still IPv4-only. I'm wondering why? is there any operation consideration or risk in their IPv6 deployment? I've done brief surveys of a small group of well known tech companies (and a few other groups) and a little over half of those have at least one IPv6 reachable authoritative nameserver (28 of 52 or ~ 54%): http://www.huque.com/app/dnsstat/category/techcom/ Yes, the new gTLDs do require IPv6, and my survey of that group seems to confirm that this is the case in practice: http://www.huque.com/app/dnsstat/category/new_gtld/ You might be interested in NIST's larger measurement of over 2000 US companies also. They show 77 of 2150 IPv6 reachable DNS domains (only 3.6%). http://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com --Shumon ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] An simple observation
On Mon, Sep 29, 2014 at 3:15 PM, Shumon Huque shu...@gmail.com wrote: You might be interested in NIST's larger measurement of over 2000 US companies also. They show 77 of 2150 IPv6 reachable DNS domains (only 3.6%). http://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com A quick correction on the NIST measurement. For IPv6/DNS it's actually 398 out of 2150 or 18.5% --Shumon. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First new gTLD using ICANN's Name Collision Occurrence Management Framework
A related observation: according the ICANN webinar on this topic from a couple of weeks ago, all new gTLDs delegated on or after August 18th were supposed to deploy these kinds of controlled interruption wildcard records. The slides are here: https://www.icann.org/en/system/files/files/name-collision-framework-slides-12aug14-en.pdf It looks like the following new gTLDs were delegated on/after that date. But only .otsuka has the records: business gbiz gmail immo network otsuka pizza xn--vhquv --Shumon. On Thu, Aug 28, 2014 at 8:38 AM, Chris Thompson c...@cam.ac.uk wrote: The gTLD otsuka, created sometime in the last 24 hours, appears to be the first to use the wildcards described at https://www.icann.org/news/announcement-2-2014-08-01-en https://www.icann.org/en/system/files/files/name- collision-framework-30jul14-en.pdf That is, it contains *.otsuka. 3600 IN A127.0.53.53 *.otsuka. 3600 IN TXT Your DNS configuration needs immediate attention see https://icann.org/namecollision; *.otsuka. 3600 IN SRV 10 10 0 your-dns-needs-immediate- attention.otsuka. *.otsuka. 3600 IN MX 10 your-dns-needs-immediate-attention.otsuka. and the corresponding RRSIGs. What do people think about this business? Is anyone taking specific precautions to detect attempts to connect to 127.0.53.53? -- Chris Thompson University of Cambridge Information Services, Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
