Re: [dns-operations] DNS benchmark platform @ OARC

[Matthew Pounsett]

On 2012/04/13, at 09:13, Ondřej Surý wrote:

> So we were thinking that DNS-OARC would be ideal platform to prepare
> methodology for measuring DNS servers performace and it could also do
> the tests as an "independent" laboratory.

We've discussed something like this within the board a few times, but have 
never had the resources to proceed with it.  If the resources are there I'll 
happily support this, and I suspect others will as well.



___
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] gtld servers in oz

[Matthew Pounsett]

On 2012/04/27, at 13:31, Randy Bush wrote:

> are there servers for com, net, org, ... in australia?

The nearest org servers to Australia would be in Hong Kong.



___
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] gtld servers in oz

[Matthew Pounsett]

On 2012/04/27, at 14:20, Matthew Pounsett wrote:

> 
> On 2012/04/27, at 13:31, Randy Bush wrote:
> 
>> are there servers for com, net, org, ... in australia?
> 
> The nearest org servers to Australia would be in Hong Kong.

I should clarify that.. the nearest Afilias-operated org servers are in Hong 
Kong.  PCH operates part of the infrastructure and they definitely have servers 
inside Australia.



___
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] The (very) uneven distribution of DNS root servers on the Internet

[Matthew Pounsett]

On 2012/05/16, at 03:53, Mark Andrews wrote:

> 
> The only problem with this is ICANN wanting to make the DNS a flat
> namespace by adding lots of vanity TLDs.   As these grow the space
> required to serve "." increases and it will only be possible to do
> this with large servers.

What's your definition of a "large server"?  I'm serving a few tens of 
thousands of records off of an ATOM machine designed to be a settop box.  Or 
are you suggesting that the new TLDs will expand beyond tens of thousands of 
zones?



___
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] Restrict ANY query to TCP ? Re: Why would an MTA issue an ANY query instead of an MX query?

[Matthew Pounsett]

On 2012/06/11, at 13:57, Thomas Dupas wrote:

> Well, partly from what I see.
> Posts from yesterday already mentioned that many sources are not spoofed for 
> the actual query the nameserver sees.
> If I look at our logs I see that most of the any queries come from 
> north-america, not china. They use spoofed source ip's to reach the cpe, but 
> the cpe queries towards the nameserver aren't spoofed.
> Forcing any queries to tcp won't change that.


The vast majority of DoS-scale ANY queries we (Afilias) see are spoofed, 
generating attacks against a third party.


On 2012/06/11, at 13:46, Olafur Gudmundsson wrote:

> how about much simpler configuration option to force all
> any queries to be reissued over TCP,
>   restrict-any-udp  "yes/no";



Because that only solves the problem of ANY queries.  If they were forced over 
TCP, then the next easiest attack vector is spoofed DNSKEY queries.   
(source,query,answer) tuple rate limiting handles the entire attack method, not 
just a single qtype.




___
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] Rogers contact?

[Matthew Pounsett]

Does anyone have a DNS contact at Rogers?  I think I've found a v6 connectivity 
(or communications) problem between the recursive servers for the 3G and 
probably also residential cable networks and my name servers at least.. 
probably others... but it's hard to tell from my vantage point.  I'm hoping I 
can find someone on the inside to help figure out if that's right, and diagnose 
the problem.


___
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] DNS ANY record queries - Reflection Attacks

[Matthew Pounsett]

On 2012/09/12, at 09:06, paul vixie wrote:

> On 9/12/2012 10:57 AM, Phil Regnauld wrote:
>> I do wish we had similar knobs in NSD (I thought version 3 was going
>> to offer that) -
>> http://www.nlnetlabs.nl/downloads/NSD_DenicTechnical.pdf, but that's
>> from 2009.
> 
> i will pay my own air fare and hotel costs to spend a week with the NSD
> folks if they want to implement DNS RRL and they think that having me in
> the office to yell at will improve their chances.
> 
> or they can find me during RIPE 65 and i'll tell them what little i
> know, PLUS i will buy them beer.

I would be most happy if something like this happened.  Once we're done labbing 
BIND's RRL implementation and go to put it in production, it would be great if 
we could update our NSD instances as well.  Rate limiting from some instances 
is better than none, but if we could do it the same way from all of them it 
would be great.




___
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] DNS ANY record queries - Reflection Attacks

[Matthew Pounsett]

On 2012/09/12, at 15:44, Eric Osterweil wrote:

> 
> OK, this is beginning to become clearer... But I have to admit, this still 
> seems worrisome to me.  If you drop 50% of legit traffic (a generous 
> assumption as it assumes a uniform distribution, which is not established by 
> any of the analysis I have seen), and the other 50% (that you service as 
> TC-bit mini-responses) comes back to you as TCP.  Thus, you have taken your 
> own processing requirements way up (as your clients will now all hit you over 
> TCP instead of UDP).

Are you perhaps thinking that when rate limiting gets applied, it is applied 
uniformly to all queries from a particular source address?  It isn't, as I 
understand it.  Rate limiting is applied by response .. a well behaved client 
isn't going to be sending hundreds of queries for the same information, let 
alone thousands.  If the one query every TTL that it sends is truncated, it 
will resend via TCP, and that will be okay.

when a real client is sending periodic legitimate queries, while a spoofed 
source is sending thousands of queries per second for 
whatever query they happen to be using as an attack, the real client will only 
be rate limited if it happens to query for the same data that the attacker is 
querying for, and a single TCP query is all it will take to get around the rate 
limiting.

I'm unable to see where the potential is for high (or even measurable) false 
positive rates.


___
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] Fingerprinting stub resolvers

[Matthew Pounsett]

A friend of mine at an ISP asked me recently whether I had any suggestions for 
fingerprinting stub resolvers.  They've got pcaps from the downstream side of 
their caching servers and are looking at trying to pull more interesting 
statistics than query counts out of them.  I didn't have any good suggestions, 
but it seems like an interesting question to ask of one's name server.   Has 
anyone else tackled this before?  Do tools exist?


___
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] Fingerprinting stub resolvers

[Matthew Pounsett]

On 2013/01/04, at 11:48, Rubens Kuhl wrote:

> 
> Em 04/01/2013, às 14:05:000, Matthew Pounsett escreveu:
> 
>> 
>> A friend of mine at an ISP asked me recently whether I had any suggestions 
>> for fingerprinting stub resolvers.  They've got pcaps from the downstream 
>> side of their caching servers and are looking at trying to pull more 
>> interesting statistics than query counts out of them.  I didn't have any 
>> good suggestions, but it seems like an interesting question to ask of one's 
>> name server.   Has anyone else tackled this before?  Do tools exist?
> 
> 
> One could try looking for queries similar to the ones fpdns does:
> https://github.com/kirei/fpdns
> 
> fpdns uses very unusual, borderline queries, to try to identify the servers, 
> so it might not find much samples in the usual traffic. 

fpdns is designed for authoritative servers.  I gather people have had some 
success running it against caching servers, but neither of those apply here.  
One can't assume that the stub resolver is even reachable to bounce queries off 
of it.. any stub resolver fingerprinting is going to have to be passive.



___
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] Fingerprinting stub resolvers

[Matthew Pounsett]

On 2013/01/04, at 12:05, John Kristoff wrote:

> On Fri, 4 Jan 2013 11:05:47 -0500
> Matthew Pounsett  wrote:
> 
>> A friend of mine at an ISP asked me recently whether I had any
>> suggestions for fingerprinting stub resolvers.  They've got pcaps
>> from the downstream side of their caching servers and are looking at
>> trying to pull more interesting statistics than query counts out of
>> them.  I didn't have any good suggestions, but it seems like an
>> interesting question to ask of one's name server.   Has anyone else
>> tackled this before?  Do tools exist?
> 
> I've not tried it in an automated way, but if you have pcaps of stub
> resolvers, that ought to tell you a good deal. 

Yeah.  I imagine he's got a fair bit of data there that could be sifted through 
given the time.  But, I think that coming up with reasonable fingerprints would 
require a lot of testing where the tester controls both sides of the 
connection.  It's one thing to try to categorize stubs from just their 
activity, but name them you'd have to know for certain what's on the other end. 

My impression is that he's hoping someone else has done this before and that 
there's a wheel out there already invented.  It sounds like that probably 
hasn't happened, though.


___
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] Fingerprinting stub resolvers

[Matthew Pounsett]

On 2013/01/07, at 06:32, gra...@graemef.net wrote:

> On 04.01.2013 16:05, Matthew Pounsett wrote:
>> A friend of mine at an ISP asked me recently whether I had any
>> suggestions for fingerprinting stub resolvers.  They've got pcaps from
>> the downstream side of their caching servers and are looking at trying
>> to pull more interesting statistics than query counts out of them.  I
>> didn't have any good suggestions, but it seems like an interesting
>> question to ask of one's name server.   Has anyone else tackled this
>> before?  Do tools exist?
> 
> p0f would be a good one to start with.
> 
> Although it might not be 100% accurate, running those pcaps through p0f would 
> give a starting point as it already has some of the techniques included that 
> were mentione din other responses to your question.

That looks like a fantastic starting point.  Thanks, Graeme... I'll pass that 
on.



___
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] RRL exposed: resolver issues with AAAA-only NS?

[Matthew Pounsett]

On 2013/01/10, at 16:53, Phil Pennock wrote:

> Anyone know of any resolvers that suffer horribly and die when presented
> with an NS host which is -only?

>From the perspective of a v4-only resolver, that would look like a lame 
>delegation.  Is the whole NS set v6-only, or just the one name server?  If 
>it's the whole NS set it wouldn't surprise me to find a few implementations 
>that become a bit pathological about trying to get the address records.  I'd 
>expect those implementations to try resolving the whole NS set though, and 
>give up once they found a v4 address for any of them.




___
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] DNS continuity during registrar transfers (was Re: Enom's name server broken?)

[Matthew Pounsett]

On 2013/01/15, at 09:41, Mark Jeftovic wrote:

> 
> 
> On 13-01-15 8:46 AM, Mark Andrews wrote:
>> 
>> For clean transfers of zones from one provider to the next the
>> losing provide should slave the zones from the new provider.  This
>> ensures that caches only see current content regardless of whether
>> they are talking to the new or old servers.
>> 
> 
> I think this almost never happens in the real world when domains move
> from one set of auth nameservers to another. What the losing servers can
> do is continue to serve the data they have, especially in the case of a
> registrar transfer because in a lot of cases the zone data will be the
> same for an overlapping period of time.

This almost never happens because cooperation between the two service providers 
is difficult to obtain.  Speaking as a service provider, I've managed to get 
inter-operator zone transfers happening post-transfer on a small number of 
occasions (from both sides of the transfer), but only because the customer was 
large enough to demand it of the other operator when we suggested it.  With 
smaller customers, and here speaking also as a customer on a few occasions, 
it's impossible to get both operators to care enough to do the extra work to 
open up zone transfers between the two organizations.  

So I think you're right.  In most cases, the only option for the losing 
operator is just to serve what they've got until the TTLs run out.


___
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] DNS Issue

[Matthew Pounsett]

On 2013/04/24, at 09:06, Samir Abidali wrote:

> I wonder if someone can guide me in the direction for troubleshooting my DNS 
> issues.
> I work in the regional ISP, we have to DNS servers where it works fine for 
> most of the Domain names but it cannot resolve some others, like dyn.com.

I wasn't able to reproduce this myself.. it all looks good from here.

> dig: couldn't get address for 'ns1.p01.dynect.net': failure

What happens if you run a 'dig +trace ns1.p01.dynect.net'?  Since that name 
server name isn't a subdomain of dyn.com I think dig is (correctly) ignoring 
the additional section in the response from h.gtld-servers.net, and has gone to 
your stub resolver to get the address for ns1.p01.dynect.net.  If that is 
failing for some reason it would explain the error you're seeing.


___
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] Resolvers choosing low latency nameservers

[Matthew Pounsett]

On 2013/06/21, at 09:27, Matthäus Wander wrote:

> Hi,
> 
> are there any studies or anecdotal evidence about how recursive
> resolvers select a query destination from a set of authoritative servers
> with known RTTs, and how often they re-probe the slower ones?
> 
> Specifically, how many queries in what period of time would it take
> until a BIND or Unbound has re-probed all auth ns of e.g. com?

This may not answer your second question, but at the DNS-OARC meeting in London 
last spring there was a presentation covering your first.





___
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] .ORG website experiences intermittent DNS failure

[Matthew Pounsett]

On 2013-09-30, at 15:25 , "Catherine Burdon"  wrote:

> Website www.newmarketstageco.org experiencing DNS failure intermittently.  I 
> have verified the DNS zone settings for the domain and all are correct.  From 
> time to time the website will not be found, then shortly thereafter will 
> appear again.

At the moment, the "two" name servers for newmarketstageco.org are unreachable. 
 I'm quoting the word two because the registration has ns1.myviabank.com and 
ns2.myviabank.com, but according to the glue in the .com zone both name servers 
have the same IP address.

Since that IP address isn't reachable, newmarketstageco.org is unresolvable.



; <<>> DiG 9.8.5-P1 <<>> +norec IN A ns1.myviabank.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53754
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ns1.myviabank.com. IN  A

;; AUTHORITY SECTION:
myviabank.com.  172800  IN  NS  ns1.myviabank.com.
myviabank.com.  172800  IN  NS  ns2.myviabank.com.

;; ADDITIONAL SECTION:
ns1.myviabank.com.  172800  IN  A   208.73.211.69
ns2.myviabank.com.  172800  IN  A   208.73.211.69

;; Query time: 19 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Tue Oct 01 12:12:25 EDT 2013
;; MSG SIZE  rcvd: 99


___
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] DNSSEC at ICANN: still no check?

[Matthew Pounsett]

On Jan 20, 2014, at 11:37 , 🔒 Roy Arends  wrote:

> The problem is indeed the absence of type NS in the type bit maps, as you 
> (and Peter van
> Dijk) showed in your previous mail.

It’s hard to see from outside since its all the same NS set, but I suspect red. 
and nic.red. are separate zones, but that there is no delegation from red. to 
nic.red.  I’ve seen that mistake before.  With the same NS set it wouldn’t 
appear as a problem prior to signing.


___
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] DNSSEC at ICANN: still no check?

[Matthew Pounsett]

On Jan 21, 2014, at 06:13 , Chris Thompson  wrote:

> On Jan 20 2014, Matthew Pounsett wrote:
> 
>> It’s hard to see from outside since its all the same NS set, but I suspect
>> red. and nic.red. are separate zones, but that there is no delegation from
>> red. to nic.red.  I’ve seen that mistake before.  With the same NS set it
>> wouldn’t appear as a problem prior to signing.
> 
> But there shouldn't have been a "prior to signing" state for "red", should
> there? "In the absence of validation" might be an explanation, though.

No, there wouldn’t be a prior to signing state for “red”, but there would be a 
prior to signing state for the operators.  
___
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] DNSSEC at ICANN: still no check?

[Matthew Pounsett]

On Jan 21, 2014, at 09:34 , Casey Deccio  wrote:

> That could be the case (the issue appears to be fixed now).  In the past when 
> I've seen this the authoritative server returns NXDOMAIN status, rather than 
> NOERROR, as the name (according the delegating parent zone, which answers for 
> DS) does not exist.  In this case, the name does appear to exist, but with no 
> record types.  I'm guessing that is because there is some "sibling glue" in 
> the "red" zone for another delegation, which NS records include server names 
> in "nic.red".  Interesting find - I hadn't seen this scenario before.

If the same server is authoritative for both zones you’ll still get an answer 
for your request (for nic.red), so no NXDOMAIN, but the cryptographic chain 
will be missing since the NSEC records in red indicate that nic.red doesn’t 
exist.


___
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] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

[Matthew Pounsett]

On Apr 4, 2014, at 23:26 , Mark Andrews  wrote:

> FreeBSD is using _http._tcp today for some of their services.

Do you know for which ones?

; <<>> DiG 9.8.3-P1 <<>> IN SRV _http._tcp.freebsd.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20566
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0



___
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] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

[Matthew Pounsett]

On Apr 5, 2014, at 17:10 , Doug Barton  wrote:

> On 04/05/2014 01:51 PM, Matthew Pounsett wrote:
>> 
>> On Apr 4, 2014, at 23:26 , Mark Andrews  wrote:
>> 
>>> FreeBSD is using _http._tcp today for some of their services.
>> 
>> Do you know for which ones?
> 
> portaudit for one.

; <<>> DiG 9.8.3-P1 <<>> IN SRV _http._tcp.portaudit.freebsd.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4991
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


___
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] NSCD for Linux/UNIX stub resolver failover?

[Matthew Pounsett]

On Apr 23, 2014, at 12:10 , Chuck Anderson  wrote:

> On Tue, Apr 22, 2014 at 11:27:02PM -0400, Robert Edmonds wrote:
>> Chuck Anderson wrote:
>>> 2. Use a local DNS daemon on every server with forwarders configured
>>>   to the network's nameservers, and fix resolv.conf to 127.0.0.1.
>> 
>> I'll shamelessly admit that I do this on all my Debian systems, where
>> "apt-get install unbound resolvconf" results in exactly that
>> configuration.
> 
> Has anyone had good experiences with using NSCD to solve the DNS
> failover problem?

The last time I used solaris for anything it was running nscd by default.  I 
had mixed experiences with it.  It solved the resolver failover problem fairly 
well, but brought other issues along with it.  I found it tended to cache 
things longer than it was supposed to, crashed fairly frequently (reintroducing 
a cousin of the lookup failure problem that it was solving) and made cache 
clearing for “emergency” DNS changes more problematic by decentralizing the 
cache.  

Granted this was a long time ago (over ten years) so the stability and TTL 
respect problems may have been solved; and that last issue isn’t so much of an 
issue if we’re talking about home nets instead of larger installations.



___
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] DDNS updates for 2.0.0.2.ip6.arpa to ns3.apnic.net

[Matthew Pounsett]

On Apr 24, 2014, at 10:28 , Chuck Anderson  wrote:

> Has anyone seen bunches of machines on their network attempting to do
> DDNS updates to ns3.apnic.net for addresses in the 6to4 2002::/16
> block 2.0.0.2.ip6.arpa zone?  Should I be concerned?

ns3.apnic.net is the reverse DNS PTR for the actual MNAME of the 
2.0.0.2.ip6.arpa zone.

% dig +short IN SOA 2.0.0.2.ip6.arpa.
ns-apnic.6to4.nro.net. dns-admin.apnic.net. 2004083706 7200 1800 604800 172800
% dig +short IN A ns-apnic.6to4.nro.net.
202.12.28.131
% dig +short IN PTR 131.28.12.202.in-addr.arpa.
ns3.apnic.net.

Do you have a 6to4 gateway in operation?   If there are misconfigured dhcp 
clients in your network, and you’re using addresses somewhere in 2002::/16 then 
it’s reasonable that you’d be seeing that traffic.  


___
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] about the underline in hostname

[Matthew Pounsett]

On May 29, 2014, at 04:24 , hua peng  wrote:

> I found this is a valid RR:
> 
> _spf.yandex.ru. 2768IN  TXT "v=spf1
> include:_spf-ipv4.yandex.ru include:_spf-ipv6.yandex.ru ~all"
> 
> 
> But for A, CNAME,  etc, the underline in hostname is invalid.
> Does this make a confusion?

There is a distinction between domain names and host names.  Host names are a 
subset of domain names; a host name is any domain name that points to an actual 
host (i.e. has an address record).  The rules for the characters in domain 
names and host names are slightly different.

Host names are only allowed the characters [a-z] (case insensitive), [0-9], and 
[-].  See RFCs 952 and 1123.

Domain names may use any string as a label, so for example the underscore is 
perfectly legal.  See RFC 2181.


___
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] name.com admins?

[Matthew Pounsett]

Is there anyone on-list from name.com that can look into some strange behaviour 
from the name.com servers?  



___
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] name.com admins?

[Matthew Pounsett]

On Jul 2, 2014, at 21:08 , hua peng  wrote:

> 
>> Is there anyone on-list from name.com that can look into some strange 
>> behaviour from the name.com servers?
> 
> You may describe what's the problem firstly.

It was something specific to name.com, and not something I would expect anyone 
other than a name.com admin to have any insight into.  I was merely looking for 
a contact point, which I found.




___
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] Zone with expired signatures?

[Matthew Pounsett]

On Jul 30, 2014, at 00:53 , Doug Barton  wrote:

> I could have sworn that I remembered someone setting up zones with both 
> expired and valid signatures so that people could test against them. But I 
> cannot find any references. I can set that up myself of course, but I don't 
> want to spend the effort if someone else has already invented that particular 
> wheel.

There’s one in the test.dnssec-tools.org zone[1], and another at SIDN[2].  I 
seem to recall one at NLnet Labs, but can’t find any reference to it currently. 
 

[1] 
[2] 



___
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

[Matthew Pounsett]

On Sep 24, 2014, at 21:27 , Davey Song  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?

There is additional operational complexity in running a dual-stack network, 
which implies some risk, but in my opinion it’s not serious enough to be a real 
blocker for most networks.  Some companies may have legacy assumptions in their 
application that makes adding IPv6 difficult in some way, but from the outside 
it’s impossible to identify who those networks might be.

Some large companies simply have their own inertia to overcome.  It can take a 
while to get large re-engineering projects moving in larger companies, and they 
may need/want to wait until the infrastructure is in place everywhere before 
turning it on anywhere. 

It’s a little weird to me that google’s authoritative DNS servers are not 
addressable over v6.  Their Google Public DNS service does operate over v6, so 
clearly they have the infrastructure in place.  I’m speculating, but perhaps 
there are bits of their internal CDN-like behaviour that still need to be 
modified.

In short, no there are no generally applicable technical reasons not to be 
running v6 on your DNS servers.
___
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] 2014 Fall DNS-OARC Workshop PGP Keysigning

[Matthew Pounsett]

I've heard a couple reports that attendees at the meeting this weekend did not 
receive an email I sent through Indico about the PGP keysigning at the meeting. 
 Apologies for that.. I'm using this email to dns-operations to compensate.

The keysigning party will be during the second half of lunch on Sunday.   If 
you wish to participate, please email your key(s) to 
matt.pounsett+keypa...@rightside.co and I'll compile a keyring.  

Please bring a trusted source to read your fingerprint from (such as your PGP 
keyring on your laptop) and ID suitable for identifying yourself to people from 
other countries.

Thanks all.  Apologies for the noise to those of you not attending.
- Matt



___
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] resolvers considered harmful

[Matthew Pounsett]

On Oct 22, 2014, at 13:16 , Andrew Sullivan  wrote:

> On Wed, Oct 22, 2014 at 12:47:39PM -0400, Mark Allman wrote:
> 
>>  leaving recursive resolution to the clients.  We show that the two
>>  primary costs of this approach---loss of performance and an increase
>>  in system load---are modest and therefore conclude that this approach
>>  is beneficial for strengthening the DNS by reducing the attack
>>  surface.
> 
> As long as you only count costs _to you_, externalizing costs is often
> a good idea.
> 
> There's a third cost here, and that is a large increase in costs to
> authoritative server operators.  
> 
> That might be worth trading off, but it won't do to pretend that isn't
> a cost that's incurred.

The paper also appears to make the assumption that eliminating existing 
resolvers is a thing we can do.  Open recursive resolvers won’t go away simply 
because we, as an industry, decide to stop setting up new ones.  There’s no way 
to prevent them from sending queries (or to selectively block them), and they 
are almost by definition unmanaged, so we cannot expect they will be taken 
offline by their respective administrators.

___
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] resolvers considered harmful

[Matthew Pounsett]

On Oct 22, 2014, at 23:03 , Mark Allman  wrote:

> 
> 
> The paper quantifies this cost for .com.  We find that something like 1%
> of the records change each week.  So, while increasing the TTL from the
> current two days to one week certainly sacrifices some possible
> flexibility, in practical terms the flexibility isn't being used.

I think your definition of “used” is flawed.  1% of the records in .com is 
actually over a million delegations.  That seems like quite a lot of use, to 
me.  

But, let’s consider the actual effects of changing TTLs in a delegation-centric 
zone.

Today, the TTL of NS records at the parent are, by and large, ignored by 
resolvers.  As non-authoritative data, it’s my understanding that, in most 
resolvers, the TTL of the parent NS set is overwritten by the TTL of the 
authoritative NS records in the child zone.  Under current normal operation, 
changing the TTL in the TLD would have little or no effect on the frequency of 
queries to the TLD.

If resolvers were to begin paying more attention to the parent TTL, then 
raising the TTL in the TLD zone would cause that 1% of customers (over a 
million a week) to have to wait a week every time they update their NS set for 
the old records to expire.  That’s a significant operational change for zone 
operators.  

It’s even worse for DNSSEC, where the DS record in the parent zone is actually 
authoritative data.  Forcing people to take a minimum of a week to do a 
security roll isn’t going to go over well.  Even the standard one or two days 
that most TLDs use today is too long for some people in this case.

> 
>  - As noted in the paper 93% of the zones see no increase in our
>trace-driven simulations.  That is, they are accessed by at most one
>end host per TTL and therefore see no benefit from the shared cache
>and hence will see the same load regardless of whether it is an end
>host or a shared resolver asking the questions.

How does this compare to resolvers with one or two (or four) orders of 
magnitude more clients behind them?  You were watching a network with roughly 
clients 100 behind a revolver; this doesn’t seem to be representative of the 
Internet at large, where a very large number of the clients are served by a 
very small number of recursive servers.  Have a look at recent work from Geoff 
Huston.. While I can’t put my hands on the reference at the moment, I seem to 
recall him having data that suggests ~25% of the clients sit behind ~1% of the 
resolvers (I can find the reference[1] that puts 16% of the Internet behind 
Google alone).  That’s a very different world from the one extrapolated from 
100 users behind each resolver.

> 
>  - Or, put differently ... We are not pretending that there is no
>additional cost at some auth servers.  But, this additional cost
>does buy us things.  So, it is simply a different tradeoff than we
>are making now.

It’s externalizing costs, not a trade-off.  One entity is not making a change 
and then gaining some things and losing others.  One entity is making a change 
(e.g. an ISP shutting down its resolver) and gaining a reduction in expenses.  
Meanwhile other entities (e.g. their end users) lose some processor cycles to 
their new private resolvers, and some time to increased RTT due to cache misses 
(see above why I don’t accept that this is not a problem).  A third set of 
entities (authoritative operators) lose quite a lot to a significant increase 
in operational costs.  

> - There is also a philosophical-yet-practical argument here.  That is,
>if I want to bypass all the shared resolver junk between my laptop
>and the auth servers I can do that now.  And, it seems to me that
>even given all the arguments against bypassing a shared resolver
>that should be viewed as at least a rational choice.  So, in this
>case the auth zones just have to cope with what shows up.  So, do we
>believe that it is incumbent upon (say) AT&T to provide shared
>resolvers to shield (say) Google from a portion of the DNS load?
>Or, put differently, the results in the paper suggest that there
>really isn't much for AT&T to gain from providing those resolvers,
>so why should it?  One argument here could be that AT&T is trying to
>provide its customers better performance.  But, the paper shows this
>is really not happening (which is largely a function of pervasive
>DNS prefetching).  So, if I am AT&T I'd be thinking "hey, what am I
>or my customers actually gaining from this complexity I have in my
>network?!".  And, if the answer is little-to-nothing then it seems
>rational to not provide this service.  Or, so it seems to me.

It doesn’t look to me like your paper has done anything to capture what it 
looks like behind AT&T’s resolvers, so I’m not sure how you can come to that 
sort of conclusion.  In 2012, AT&T had around 107 million mobile users alone (I 
found that number[2] more easily than their ho

Re: [dns-operations] resolvers considered harmful

[Matthew Pounsett]

On Oct 23, 2014, at 11:59 , Andrew Sullivan  wrote:

> Also, as I already noted, modelling this in a delegation-centric zone
> uses the wrong model.  Moreover, the data sets are from a notably tiny
> shared-iterative-resolver community.  It seems to me that
> understanding the endpoint:iterative ratios in (for instance)
> Comcast's, Time-Warner's, AT&T's, Verizon's, and T-Mobile's networks
> (even just in the US) would go a long way to indicating whether the
> inferences about load in this paper are realistic.

Agreed.  Most people are behind caches with at least an order of magnitude more 
users whether they’re at home or at work.  Lots of people are behind caches 
with two or three orders of magnitude more users.  The behaviour of those 
caching recursive servers would be very different from this study.



___
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] resolvers considered harmful

[Matthew Pounsett]

On Oct 23, 2014, at 12:28 , Stephane Bortzmeyer  wrote:

> On Wed, Oct 22, 2014 at 12:47:39PM -0400,
> Mark Allman  wrote 
> a message of 64 lines which said:
> 
>> Short paper / crazy idea for your amusement ...
> 
> The biggest problem I have with this paper is of terminology. I
> thought at the beginning that the idea was to get rid of resolvers,
> then it appeared you want a resolver, but on the end host, and the,
> during the discussion here (your answer to David Conrad), it seems you
> want to move the resolver to every application?

Reading between the lines, I think the intent was “shared resolver”, or “shared 
caching resolver”, or possibly just “shared cache.”   Whichever way, it seems 
to be the “shared” part that the paper argues against.




___
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] resolvers considered harmful

[Matthew Pounsett]

On Oct 23, 2014, at 15:18 , Mark Allman  wrote:

>> How does this compare to resolvers with one or two (or four) orders of
>> magnitude more clients behind them?  
> 
> Presumably pretty well.  I only know of old results here, but Jung's
> IMW 2001 paper suggests that the cache hit rate levels off after 10-20
> users.  I have in mind that there is a more recent (but not last year)
> validation of this, but I don't have a reference at my finger tips.

The cache hit rate may level off, but the query rate to the caching recursive 
doesn’t.  The key variable is at what point (how many users) cache misses start 
to occur every $TTL seconds.It’s at that point that a shared caching server 
becomes critical.  

Say for example that occurs at 1,000 users.  In that case, at >1000 users there 
is a linear relationship between queries sent by clients and queries blocked 
from hitting the authoritative servers.  If that’s the number, then in an 
infrastructure with a million users that caching server is saving the 
authoritative servers from orders of magnitude increase in queries for a 
particular name, not 2x or 3x as you claim.

I don’t see where you’ve done the work that allows you to extrapolate your 
numbers to the Internet at large.  Your tiny sample just isn’t representative 
of the caching recursive servers that handle the majority of the Internet’s 
queries.

As a TLD operator, and the operator of some very busy second level 
authoritative servers, I don’t care about the offices or neighbourhoods of 100 
people behind a single caching resolver suddenly deciding they should all run 
their own resolvers, and bypass the local cache.  That’s a tiny drop in the 
bucket compared to the hundreds of millions of users behind a small handful –– 
low tens of thousands –– of caching resolvers.   If we have that situation you 
can expect your $15/yr domain registration to be more like $50 or $60, and your 
$15/mo hosting plan that comes with DNS services to start charging you 
similarly 

>>> - There is also a philosophical-yet-practical argument here.  That is,
>>>   if I want to bypass all the shared resolver junk between my
>>>   laptop and the auth servers I can do that now.  And, it seems to
>>>   me that even given all the arguments against bypassing a shared
>>>   resolver that should be viewed as at least a rational choice.
>>>   So, in this case the auth zones just have to cope with what shows
>>>   up.  So, do we believe that it is incumbent upon (say) AT&T to
>>>   provide shared resolvers to shield (say) Google from a portion of
>>>   the DNS load?
>> 
>> It doesn’t look to me like your paper has done anything to capture
>> what it looks like behind AT&T’s resolvers, so I’m not sure how you
>> can come to that sort of conclusion.
> 
> Correct.  This is a thought experiment with exemplars that I gave names
> to. 

Your exemplars don’t match your experiment.  You appear to be trying to make an 
economic argument for a major change to the infrastructure based on an 
unrepresentative sample.

You ignored my comments on how TTLs in delegation-centric zones like TLDs 
actually work.. it seems to me there are some bad assumptions about the 
behaviour of the DNS underlying this work that make it hard to use it to 
suggest any sort of change to current operations.


___
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] resolvers considered harmful

[Matthew Pounsett]

> On Oct 23, 2014, at 18:23, Matthew Pounsett  wrote:
> 
> The cache hit rate may level off, but the query rate to the caching recursive 
> doesn’t.  

Sorry, that should have said the cache *miss* rate. It's an asymptote maxing 
out at the TTL, dependent on the population behind the cache. 

> The key variable is at what point (how many users) cache misses start to 
> occur every $TTL seconds.It’s at that point that a shared caching server 
> becomes critical.  
> 
> Say for example that occurs at 1,000 users.  In that case, at >1000 users 
> there is a linear relationship between queries sent by clients and queries 
> blocked from hitting the authoritative servers.  If that’s the number, then 
> in an infrastructure with a million users that caching server is saving the 
> authoritative servers from orders of magnitude increase in queries for a 
> particular name, not 2x or 3x as you claim.
> 
> I don’t see where you’ve done the work that allows you to extrapolate your 
> numbers to the Internet at large.  Your tiny sample just isn’t representative 
> of the caching recursive servers that handle the majority of the Internet’s 
> queries.
> 
> As a TLD operator, and the operator of some very busy second level 
> authoritative servers, I don’t care about the offices or neighbourhoods of 
> 100 people behind a single caching resolver suddenly deciding they should all 
> run their own resolvers, and bypass the local cache.  That’s a tiny drop in 
> the bucket compared to the hundreds of millions of users behind a small 
> handful –– low tens of thousands –– of caching resolvers.   If we have that 
> situation you can expect your $15/yr domain registration to be more like $50 
> or $60, and your $15/mo hosting plan that comes with DNS services to start 
> charging you similarly 
> 
>>>> - There is also a philosophical-yet-practical argument here.  That is,
>>>>  if I want to bypass all the shared resolver junk between my
>>>>  laptop and the auth servers I can do that now.  And, it seems to
>>>>  me that even given all the arguments against bypassing a shared
>>>>  resolver that should be viewed as at least a rational choice.
>>>>  So, in this case the auth zones just have to cope with what shows
>>>>  up.  So, do we believe that it is incumbent upon (say) AT&T to
>>>>  provide shared resolvers to shield (say) Google from a portion of
>>>>  the DNS load?
>>> 
>>> It doesn’t look to me like your paper has done anything to capture
>>> what it looks like behind AT&T’s resolvers, so I’m not sure how you
>>> can come to that sort of conclusion.
>> 
>> Correct.  This is a thought experiment with exemplars that I gave names
>> to.
> 
> Your exemplars don’t match your experiment.  You appear to be trying to make 
> an economic argument for a major change to the infrastructure based on an 
> unrepresentative sample.
> 
> You ignored my comments on how TTLs in delegation-centric zones like TLDs 
> actually work.. it seems to me there are some bad assumptions about the 
> behaviour of the DNS underlying this work that make it hard to use it to 
> suggest any sort of change to current operations.
> 
> 
> ___
> 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

Re: [dns-operations] Workshop on DNS Future Root Service Architecture (2014 WDFRSA), Hong Kong, December 8-9, 2014

[Matthew Pounsett]

On Nov 14, 2014, at 04:14 , Paul Vixie  wrote:

> Registration is now open for the 2014 Workshop on DNS Future Root Service 
> Architecture (2014 WDFRSA)
> 
> > Location: Hong Kong, HK
> > Venue: The Mira Hotel (Kowloon district)
> > Date: December 8-9, 2014
> > Hosted by: ISOC-HK
> > Sponsors: ZDNS/BII and CNNIC
> > Co-chairs: Warren Kumari and Paul Vixie

Paul, 

Will there be any sort of remote participation for this workshop?



___
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] cool idea regarding root zone inviolability

[Matthew Pounsett]

On Nov 28, 2014, at 02:07 , Paul Vixie  wrote:

> 
> is there some reason why an updated sig(0) is not a solution to this? 

People move zone data around using mechanisms other than *XFR (scp, database 
replication, etc.).  A signature on the complete zone, as part of the zone, 
also covers those mechanisms.


___
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] cool idea regarding root zone inviolability

[Matthew Pounsett]

On Nov 29, 2014, at 17:57 , Paul Vixie  wrote:

> here, i'm specifically thinking of zones so large that touching every byte of 
> their content is a multiple-minutes cost.

Those zones are relatively rare though, and reading a randomly-written mmaped 
file isn’t a common name server implementation.  That seems to me to be 
optimizing for an edge case at the expense of the common case.  Zones which 
fall into that rather narrow edge case can simply not use this proposed 
signature.




___
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] Root-servers returning TC=1 after 5 NXDOMAINS

[Matthew Pounsett]

On Feb 10, 2015, at 09:06 , Emil Natan  wrote:

> If this is an issue with the F-root only it would be easier to use hints file 
> with the F excluded instead of managing local root zone and keeping it up to 
> date.

This is Response Rate Limiting in action… they’re not explicitly limiting 
NXDOMAIN responses; they’re limiting identical responses.  If Bert’s server was 
asking for the same A record over and over that would get truncated and forced 
over to TCP as well.   It’s probably not only F, although I don’t think I’ve 
seen a comprehensive list of which root instances are running RRL.  



___
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] Saga of HBONow DNSSEC Failure

[Matthew Pounsett]

On Mar 9, 2015, at 23:50 , Livingood, Jason  
wrote:

> So earlier today HBO announced a new HBONow streaming service (at an Apple 
> event). The FQDN to order, which should have been DNSSEC-enabled, was 
> order.hbonow.com. This unfortunately suffered from a rather inconveniently 
> timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). 
> :-( Of course, these being hot Net Neutrality days in the U.S., we at Comcast 
> were quickly blamed for blocking access to ordering this new service (despite 
> failures at Google and other validators). 

I’d just like to comment how pleased I am that Comcast continues to push DNSSEC 
validation, despite taking regular hits from end users.  I keep hoping others 
will follow suit.. the more large validator operators that enable it, the fewer 
hits anyone will take for doing so.




___
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] Fwd: Re: [Security] Glue or not glue?

[Matthew Pounsett]

> On Jun 9, 2015, at 23:35 , Dave Warren  wrote:
> To me, the main problem isn't verifying the nameservers before delegation, 
> but rather, the fact that an authoritative server cannot reliably get 
> themselves removed once delegation is established. At most, an authoritative 
> server operator can return bad data to attempt to disrupt the zone owner's 
> rightful use, but in the case of a high traffic DNSBL which has been 
> abandoned, there's little an authoritative server operator can do about the 
> flood of traffic.

In the (very rare) case of my name servers receiving unwanted traffic in this 
way, I’ve treated it as an abuse issue.  Report to abuse@ the organization 
that’s doing the delegation that they’re generating undated traffic.  So far 
that’s worked, but I haven’t yet had to email a gTLD registry.  
___
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] [Security] Glue or not glue?

[Matthew Pounsett]

> On Jun 10, 2015, at 16:02 , Mark E. Jeftovic  wrote:
> 
>> In the (very rare) case of my name servers receiving unwanted traffic in 
>> this way, I’ve treated it as an abuse issue.  Report to abuse@ the 
>> organization that’s doing the delegation that they’re generating undated 
>> traffic.  So far that’s worked, but I haven’t yet had to email a gTLD 
>> registry.  
>> ___
> 
> It's not that rare.

Didn’t say it was.. just that it hasn’t happened on my name servers much.

> It's happened to us (more than once) and it happened
> to DNSimple not too long ago. In those cases we've had problems getting
> the registrar to yank the delegation. In cases like that the registry
> often won't even talk to us.
> 
> It should be a no brainer to have a registrar or registry do this, but
> it isn’t.

Indeed.  Have you tried the abuse approach at the registry when the registrar 
won’t deal with you?  What sort of response did you get (if any at all)?  I’m 
curious what registries’ abuse departments would say about that when, 
technically, they’re contractually bound to publish whatever a registrar gives 
them.


___
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] DNSViz Update: Final Stretch (we hope!)

[Matthew Pounsett]

Hi everyone.  It’s been several weeks since my last update on the current 
status of the DNSViz historical data, and at least a couple of weeks since I 
last estimated we’d be up and running.  Here’s a quick summary of what’s been 
happening, including some of the history for those who have missed it, or have 
just forgotten since this has been going on so long.

During the transitional period, while we were trying to get the newly delivered 
database server installed and running, we began  temporarily running the DNSViz 
database from one of our file servers.  We initially noticed some odd behaviour 
that was tracked down to a library inconsistency between the two systems, which 
resulted in some string indexes being treated as corrupt on the second system.  
We fixed one broken index, but there were others that we did not spot at the 
time.  Without the proper constraints in place, some bad data (in the form of 
duplicate entries for primary key columns) were inserted into the database.

Fast forward to re-importing the database on the old system after it was 
cleaned up, and several index creation statements and foreign key constraint 
statements were skipped due to the duplicate records in the database.  This is 
about where we were the last time I sent an update.

To make matters worse, some of these indexes rely on the existence of other 
indexes and constraints, which meant that while we were trying to clean things 
up, our queries resulted in sequential scans of extremely large tables, which 
took a really long time.  We had to systematically fix all the data, so that 
the constraints could be properly added, then reinitiate the import of the 
affected tables (with the fixed data) so that the indexes could then be created.

We believe we’re in the home stretch as we wait for the final import to 
complete.  However, Casey and I are both, for obvious reasons, very reluctant 
to try to estimate the time remaining on that process.

I think it’s important to recognize Casey for all the work he’s been putting 
into helping get this going again.  Since the initial reimport completed and we 
began cleanup work, as the person who knows the database schema best, Casey has 
been responsible for virtually all of the forward progress.  While I’ve helped 
here and there attempting to optimise queries that needed to be run, Casey has 
been the one doing the actual cleanup work.  I’d very much like to thank him 
for that.

The signs are good that we should have this back to full functionality soon.  
Thanks again to everyone for your patience.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
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?

[Matthew Pounsett]

On Wed, 9 Oct 2019 at 22:57, Viktor Dukhovni  wrote:

> On Wed, Oct 09, 2019 at 05:41:43PM -0400, Viktor Dukhovni wrote:
>
> > No, even small responses receive no answers from the IPv6 addresses
> > of the C and F roots.  Both of the below time out even though I'm
> > not setting the "DO" bit:
> >
> > $ dig -6 +norecur -t soa arpa. @2001:500:2f::f
> > $ dig -6 +norecur -t soa arpa. @2001:500:2::c
> >
> > Looks like an outage from my vantage point.
>

I can't speak to the reachability of F from that vantage point, but Cogent
has famously refused to peer over v6 with HE, which is why they're
unreachable from OARC (and therefore DNSViz) and lots of other places on
the Internet.
___
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?

[Matthew Pounsett]

On Thu, 10 Oct 2019 at 17:26, Jared Mauch  wrote:

> On Thu, Oct 10, 2019 at 01:56:11PM -0700, Randy Bush wrote:
> > >> Neither Cogent or HE buy transit from anybody else
> >
> > i believe this statement to be false
>
> i know of at least 2 transit providers..
>

Both providing v4 transit, not v6, yes?

The speculation I've seen is that Cogent refuses to treat HE as a Tier1
network in v6 because they don't try to also be one in v4, but that they
should because HE's v6 network is much wider reaching and much longer
established than Cogent's.  In any case, Cogent's refusal to peer with HE
over v6 has been very public and well documented.  It makes Cogent
unreachable from a significant portion of the v6 network.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Matthew Pounsett]

On Wed, 11 Dec 2019 at 08:24, Jim Reid  wrote:

>
> In principle, they could all change at once, In reality, they don’t.
> 
>

This absolutely does happen.  I've been at the helm of several operator
changes on TLDs that saw all the NS records and glue change in the same
update.   I've seen several others change the same way.  I have yet to
witness anyone splitting the NS change up into multiple IANA requests.
With enough prep and testing it's fairly low risk to do all at once.

But, even if they were split up, the change would still happen on the order
of a few days, maybe two weeks tops if the operators are being extremely
careful and IANA is unusually busy/slow.  That's far too fast a change for
most resolvers to keep their root zone up to date by any current non-XFR
means.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: help with a resolution

[Matthew Pounsett]

On Thu, 9 Jan 2020 at 20:47, Tony Finch  wrote:

> I saw the Eurocrypt SHA-1 chosen-prefix attack last year but I didn't
> think about the consequences. As soon as I saw the SHAmbles announcement I
> realised what it actually meant and that DNSSEC was in serious trouble.
>
>
What are the implications for NSEC3, given that both (current) algorithm
numbers rely on SHA-1?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: help with a resolution

[Matthew Pounsett]

On Fri, 10 Jan 2020 at 08:08, Matthew Pounsett  wrote:

>
>
> On Thu, 9 Jan 2020 at 20:47, Tony Finch  wrote:
>
>> I saw the Eurocrypt SHA-1 chosen-prefix attack last year but I didn't
>> think about the consequences. As soon as I saw the SHAmbles announcement I
>> realised what it actually meant and that DNSSEC was in serious trouble.
>>
>>
> What are the implications for NSEC3, given that both (current) algorithm
> numbers rely on SHA-1?
>

Nevermind.. a split thread meant the answer to my question was further down
in my inbox.

So an attack against a TLD using NSEC3 is logistically difficult, but it's
not impossible.. so I guess we'd better get on with standardizing
RSASHA256-NSEC3-SHA256.
There are a LOT of TLDs—particularly CC's—using algo 7.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

[Matthew Pounsett]

On Wed, 19 Feb 2020 at 11:43, Pirawat WATANAPONGSE  wrote:

> Well, let’s look at the real netblock, shall we? (‘cause I have nothing to
> hide)
> You can see for yourself at
> https://dnsviz.net/d/108.158.in-addr.arpa/dnssec/
>
>
I don't really see any of these things as flag-day level problems.  The
(so-called) DNS Flag Days are about fixing long standing
interoperability issues that increase complexity of DNS server code, as it
needs to work around those problems.  None of the issues below are
interoperability issues, and none of them are long-standing issues either.


> 1. There are old DS keys from .arpa to in-addr.arpa still dangling around.
>

Why do you say there are old DS records (not keys) hanging around?  It
looks to me like the DS records for key IDs 53696 and 63982 are likely to
be pre-published for a key roll.  Although without very long term
history of the zone contents it's hard to tell.  Perhaps one of them is
outgoing and the other is incoming?  Either way, this is not a _problem_
for the zone or the DNS.


> 2. 158.in-addr.arpa is still using ‘Algorithm 5’
>

That could be improved, but again I don't see this as a flag-day level
issue.  Algo 5 has only recently fallen out of favour, and we haven't even
got around to deprecating it yet.  Presumably ARIN will get around to doing
an algorithm roll in the coming months.  You might ask on arin-discuss[1]
whether there are currently any plans, and what the schedule is.  It's
entirely possible they've already published such a schedule... their
operations team is usually pretty on top of things.

The remainder of these are not DNS problems at all, they're registry
operations and RIR policy issues.  For those I suggest you email the
registration support contacts at RIPE and ARIN, and if that doesn't solve
your issue, then I'd take it to their respective policy mailing lists.


> 3. Even though my 158.108.0.0/16 netblock was ROAed, APNIC did not link
> me to the ‘reverse’ DNSsec chain:
> 3.1. Why? Because it’s a ‘Historical’ netblock, transferred from ARIN to
> APNIC epochs ago. So, my ‘domain’ is with NIR (thank god), my ‘netblock’
> Whois is now with APNIC, but my ‘reverse’ is still with ARIN.
> 3.2. If I want to hook into the ‘reverse’ DNSsec chain, who do I send my
> DS key to? APNIC? ARIN?
> 3.2.1. APNIC is not the SOA of 158.in-addr.arpa.
> 3.2.2. I am no longer a ‘client’ of ARIN, the SOA of 158.in-addr.arpa.
>

 [1]: 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNSViz Service Restoration

[Matthew Pounsett]

Hi all!

OARC is happy… no, ecstatic… to announce that the DNSViz historical functions 
have been restored!  Users will now be seeing full functionality from the site 
at .

A few weeks ago we made the decision to temporarily put aside the attempt to 
completely restore the old historical data and instead stand up a new, empty 
database so that we could get the full featureset online.  So, for now there is 
no access to old tests run prior to the service’s move to OARC, however new 
tests will be available for review.

We’re continuing to work to restore the full historical database; we hope that 
with the pressure off, and the temptation to cut corners in order to speed up 
the process removed, we can restart the import from scratch with a slower—but 
more reliable—approach to recovering those data.

I’d like to thank everyone again for your patience with this whole saga.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSViz Service Restoration

[Matthew Pounsett]

> On Mar 12, 2020, at 07:04, Jim Popovitch via dns-operations 
>  wrote:
> 
> 
> From: Jim Popovitch 
> Subject: Re: [dns-operations] DNSViz Service Restoration
> Date: March 12, 2020 at 07:04:23 EDT
> To: dns-operations@lists.dns-oarc.net
> 
> 
> On March 12, 2020 5:04:23 AM UTC, Casey Deccio  wrote:
>> 
>> Thanks for the perspective.  I believe there is value in being able to 
>> answer the question: "what did foo.example.net look like at time X?"
> 
> Sounds great.  I think the most important feature of dnsvis was the ability 
> to link to a report to show a recent problem to others.  People haven't had 
> that capability, in over a year, because someone else saw greater value in 
> being able to show very very very old data.

While the snark may have sounded witty in your head, the decision-making was a 
actually a lot less obvious than that.

Had we known it was going to be a year of hacking at a broken database, of 
course we’d have taken this route in the first place.  But, when we first found 
that some corruption had been introduced it wasn’t obvious that would take very 
long to fix.  At all decision points along the way, it appeared as if we were 
no more than a month from having a functioning historical database.

At the OARC workshop in October, we thought we were hours away from announcing 
that it was back up and running with all of its historical data, but the import 
script running at that time was interrupted by the DB running up against its 
transaction limit, and we had to start a vacuum of the db.  That ran for 
another six weeks before failing on a full disk.

About six months in we started to consider the possibility of resetting the 
database and merging old data later, but that’s a much more complicated 
procedure as it involves both restructuring the corruption that broken the 
import in the first place AND massaging that data on import to avoid collisions 
with newly created rows that have unique constraints on them, all on top of the 
increased time it would take to do such an import while the service is active.  
There’s also the risk that certain tests could never be imported as-is because 
of the potential of a new test’s reference name (the unique 6 characters in a 
specific test’s URL) colliding with an old test’s name, causing any stored URLs 
out there to show the wrong test data.

And Casey isn’t the only one who looks at—or links to—old tests; there are web 
sites out there with links to old tests used as a historical record or as case 
studies of the ways DNS can be broken, so it still seems useful to get those 
tests back online somehow.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Test Zone Metalist

[Matthew Pounsett]

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

Matt Pounsett
DNS-OARC Systems Engineering


signature.asc
Description: Message signed with OpenPGP
___
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

[Matthew Pounsett]

Thanks to everyone for all the info!  That’s a ton of stuff I had no idea about.

I’ll try to organize it all into a useful list to post online (on the OARC web 
site), so hopefully this should be searchable the next time someone’s 
interested in finding test data for just the right thing.

I’ll post a link here once I get that online.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNSViz Access to C-root

[Matthew Pounsett]

We’re pleased to announce that, as of the beginning of June, OARC and Cogent 
have had in place a solution to the reachability problem between DNSViz and 
C-Root over IPv6.

The lack of a v6 path between Hurricane Electric and Cogent has been a 
long-standing problem, and since OARC is singly-hosted on HE this has been a 
problem for DNSViz since it was moved to DNS-OARC. There have been a few 
discussions on this list, and we receive frequent support questions about 
errors users receive related to C-root reachability.

We’ve been in discussion with Cogent for a while about finding a solution to 
the problem, and last month finally put something in place.  After having let 
it run for several weeks, we’re comfortable that it is a solid workaround.

We’d like to thank Hank Kilmer, Brad Belanger, and Dave Nagy for reaching out 
to us and for helping to solve the issue.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSViz Access to C-root

[Matthew Pounsett]

> On Jul 2, 2020, at 15:02, Alarig Le Lay  wrote:
> 
> 
> I’m also curious, from the NLNOG ring LG, HE doesn’t see C and Cogent
> doesn’t see DNSViz:

We have unfortunately not managed to magically solve the connectivity problem 
between HE and Cogent, so there is no expectation that singly-hosted HE and 
Cogent customers will now be able to see each other.  All we did was make 
C-root visible to DNSViz.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] 2020 Flag Day

[Matthew Pounsett]

> On Aug 3, 2020, at 11:34, jack tavares  wrote:
> 
> Hello -
> I have just subscribed to this list and before asking a question that has 
> been asked before,
> is there an archive of the list somewhere?
> I did not see one when I subscribed and the confirmation message does not 
> point to one.
> Thank you

There is a link to the list info in the footer of each message to the list.  If 
you follow that link you can find the list archives.


Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] New OARC Chat Platform

[Matthew Pounsett]

Hello everyone.

DNS OARC is pleased to announce that our new community chat server is open for 
access, augmenting the mailing lists we operate.

For many years, OARC has been operating a Jabber service which has been 
available to OARC Members.  We are replacing that service with a more modern 
chat platform using Mattermost.  OARC’s chat service is available for open 
signup at .

Anyone wishing to sign up and use the platform for discussion of the DNS is 
welcome to do so.  Please be reminded that all use of OARC services is subject 
to OARC’s Code of Conduct Policy, available at 
.

Mattermost is open source software, and has open source clients available for 
all major desktop and mobile platforms.  Information on Mattermost client 
software is available at .

Mattermost makes a number of Teams available on a chat server.  In OARC’s case, 
we have the Members and Community teams available for use.  Anyone in the DNS 
community is welcome to join our Community team and use it for discussion of 
the DNS.

The Members team is open to all OARC Member and Supporter contacts.  
Non-members who would like access to that team are welcome to contact 
ad...@dns-oarc.net for information about how to become a member.

Users of the chat service are welcome to create any public or private channels 
they find useful for discussing DNS community issues, on either the Community 
or Members teams.  OARC will be monitoring team creation and activity levels in 
order to watch for abuse and do basic house keeping, but otherwise have no 
plans to monitor channel content.  If participants witness any behaviour they 
feel is in violation of OARC’s code of conduct, we ask that it be brought to 
our attention.

If anyone has any questions about the chat service, please feel free to email 
us at ad...@dns-oarc.net, or find us on Mattermost.  We hope everyone finds 
this service useful for communicating with the rest of the DNS community.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] New OARC Chat Platform

[Matthew Pounsett]

On Tue, 25 Aug 2020 at 13:09, Fred Morris  wrote:

> That's a basic question which should be asked about any technology or
> service offering: why? what purpose is it intended to serve? By their
> actions clearly some people agree and some people disagree with me. Since
> it's a members-only service, maybe only members should care. I'm done with
> the discussion now.
>

It is not a member only service.

The jabber service which it is replacing has been open only to the listed
contacts of member organizations—about 300 people today.  While
requirements for member use drove most of the decision making around what
software we would use, using something more flexible, usable, and easy to
manage than jabber meant that opening it up to the wider community was an
easy get, and so we did.

If this were a member only service, we would not have made an announcement
about it on dns-operations, and would not have enabled open sign up in the
software.

The purpose it's intended to serve has already been discussed up-thread;
there is a perceived need for lower latency discussions than email
affords.  We have had requests from a couple of different segments of the
community over the past many months, especially during the current
lockdown, to provide a way for people to have those discussions.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Shutdown of OARC's ODVR service

[Matthew Pounsett]

For a little over ten years, OARC has been operating the Open DNSSEC
Validating Resolver service (ODVR), which consists of one instance each of
BIND and Unbound, open to the Internet.  The service was originally intended
as a way to allow people to test DNSSEC operations and software
implementations in a time when validating resolvers—in particular open
validating resolvers—were few and hard to find.  In 2020, public open resolver
services almost universally do DNSSEC validation, and it is much easier (and
often the default) for any newly configured resolver to do validation.

Given the overhead necessary to run an open resolver safely (ensuring that it
does not get abused, and dealing with attempts to abuse it), and comparing
that with the easy availability of validating resolvers, OARC is considering
closing down its ODVR service sometime before the end of Q3.

We are aware there are some community members that still use ODVR, and we are
interested to know what value the service provides that is not provided by
larger open resolver services, or by individually operated validating
resolvers.  If there is sufficient interest and financial support available,
we will consider converting it to a closed service, available by prearranged
ACL for a fee, instead of shutting it down completely.  Anyone interested in
having the service continue should contact ad...@dns-oarc.net before the 18th
of September, 2020.

More information about ODVR is available at
.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Shutdown of OARC's ODVR service

[Matthew Pounsett]

This is a reminder that OARC is intending to shut down our ODVR service (Open 
DNSSEC Validating Resolver) at the end of this month, if we haven’t heard back 
from community members using the service by the end of this week.

At present we haven’t heard from anyone who wants to keep the service open, so 
it looks like we’ll be dismantling it within a couple of weeks.

Matt Pounsett
DNS-OARC Systems Engineering




signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSViz please support DNSSEC algorithm Ed25519 (15)

[Matthew Pounsett]

> On Dec 30, 2020, at 06:42, Arsen STASIC  wrote:
> 
> Dear DNS-OARC,
> 
> Could you please support DNSSEC algorithm Ed25519 (15)?
> I think Casey Deccio has already added support for Ed25519. [0]

Hi Arsen.

First, it’s generally better to address mail to OARC to an OARC address — we 
usually point people toward ad...@dns-oarc.net for general support issues.  
There’s also a feedback link on the DNSViz site itself (“Questions and 
Comments”) which gets prompt replies.  While we watch the public lists, it’s 
not really an official support forum. :)I’m still a bit backed up on 
mailing lists after the holiday break, which is why I’ve been a bit slow to 
find/reply to this.

The DNSViz code does support ED25519, but (as Casey explained) the problem on 
the site is the underlying OpenSSL library.  That host is already on the list 
for a major overhaul, which would include an OS update, and I’m expecting to 
get to that within the next couple of weeks.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Support for ED25519/ED448 DS records by OpenSRS

[Matthew Pounsett]

On Sat, 20 Feb 2021 at 06:50, Simon Arlott via dns-operations <
dns-operati...@dns-oarc.net> wrote:

>
>
> Can you recommend another registrar that supports DNSSEC?
>

Gandi.NET appears to support .au, and they have a very nice API for
delegation management (they also support CDS/CDNSKEY).  There's a caveat
there about subscribing to their "corporate services" to be able to
register an .au domain... not sure what that is.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Planning the 2021 DITL collection

[Matthew Pounsett]

OARC is beginning planning for the 2021 Day in the Life (DITL) collection.  
Community DNS operators who wish to participate in the collection, and have not 
already done so, should join the d...@lists.dns-oarc.net mailing list[0] in the 
next few days.  Announcements will be made on Friday, on the DITL mailing list, 
regarding the specifics of this year's collection.  This is the only notice 
about the collection that will be sent to this list.

A reminder that the DITL mailing list has a strict “no spectators” policy.  
Only contributors to the collection will be permitted to subscribe.



About the Day in the Life Collection


Every year, DNS OARC runs a data collection event known as the Day in the Life 
collection.  DNS operators from around the globe run packet captures over the 
same 48 hour period, and contribute them to the community for ongoing research 
into the activity of the global DNS.  DITL data gathered will be made available 
to OARC Members and to
researchers under the terms of the OARC Data Sharing Agreement[1].  Research 
using the data sets has strict requirements regarding aggregation and 
anonymization, and is always made public.

OARC seeks to receive contributions from root server operators, TLD operators, 
operators of other significant authoritative zones, and recursive operators.

Although there are no hard and fast limits, we hope to see recursive 
contributions from recursive services with clients in the high hundreds to low 
tens of thousands of clients.  Recursive operators such as universities, small 
to medium sized ISPs, and large enterprises are ideal. Recursive server 
collections are always made “above” the server, between the recursive and 
authoritative, and not between the recursive and the end-user.

More information about the DITL collections can be found here: 




Matt Pounsett
DNS-OARC Systems Engineering


[0]: 
[1]: 


signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] slack.com bogus

[Matthew Pounsett]

On Thu, 30 Sept 2021 at 14:34, vom513  wrote:
>
>
> So perhaps a dumb question - could Google and Cloudflare be hitting some kind 
> of “manual overrride” to not validate a given zone - i.e. human intervention 
> / look the other way ?

Negative Trust Anchors, most probably.  It's standard operating
procedure, particularly for the very large operators, to work around
zones that are clearly broken and not actually being attacked to
essentially turn off DNSSEC validation for those zones for some period
of time.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSviz and G-root: EDNS issue?

[Matthew Pounsett]

On Tue, 12 Oct 2021 at 11:24, Keith Mitchell  wrote:
>
> This might be a known intermittent IPv6 routing issue with DNSviz, do
> you see this problem for v4 and/or v6 ?

That would show up as a non-answer over IPv6, rather than an apparent
PMTU/EDNS problem.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNS-OARC 2022 Day In The Life announcement

[Matthew Pounsett]

OARC is beginning planning for the 2022 Day in the Life (DITL) collection.
Community DNS operators who wish to participate in the collection, and have
not already done so, should join the d...@lists.dns-oarc.net mailing list[0]
in the next week or so.  Announcements will be made in early February, on the
DITL mailing list, regarding the specifics of this year's collection.  This is
the only notice about the collection that will be sent to this list.

A reminder that the DITL mailing list has a strict “no spectators” policy.
Only contributors to the collection will be permitted to subscribe.


About the Day in the Life Collection


Every year, DNS OARC runs a data collection event known as the Day in the Life
collection.  DNS operators from around the globe run packet captures over the
same 48 hour period, and contribute them to the community for ongoing research
into the activity of the global DNS.  DITL data gathered will be made
available to OARC Members and to researchers under the terms of the OARC Data
Sharing Agreement[1].  Research using the data sets has strict requirements
regarding aggregation and anonymization, and is always made public.

OARC seeks to receive contributions from root server operators, TLD operators,
AS112 server operators, operators of other significant authoritative zones
(such as RIR reverse zones and major commercial services), and recursive
operators.

Although there are no hard and fast limits, we hope to see contributions from
recursive services with clients in the high hundreds to low tens of thousands
of clients.  Recursive operators such as universities, small to medium sized
ISPs, and large enterprises are ideal. Recursive server collections are always
made “above” the server, between the recursive and authoritative, and not
between the recursive and the end-user, so end-user privacy should not be an
issue.

More information about the DITL collections can be found here:


Matt Pounsett
DNS-OARC Systems Engineering


[0]: 
[1]: 



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] OARC chat server outage

[Matthew Pounsett]

Those of you on the  Mattermost server may have 
noticed that it is offline.  It appears that some runaway logging filled up the 
disk and took out the back-end database.  I’m working with the managed hosting 
company that runs the service to sort out why.

While we can clear up storage and get the DB back online, we’d like to make 
sure it isn’t immediately going to fill back up again, so we’re delaying until 
we can identify and fix the root cause.

We’re hoping to have it up and running again soon.

Our apologies for the disruption.

I’ll follow up to this email when we have the service running again.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] OARC chat server outage

[Matthew Pounsett]

OARC’s chat server is back up and accessible now.  The hosting company thinks 
they’ve identified the issue, and has made changes to avoid it reoccurring. We 
expect this to be resolved, now.

Thanks for your patience everyone.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Upcoming DITL 2023 collection

[Matthew Pounsett]

OARC is beginning planning for the 2023 Day in the Life (DITL) collection.
Community DNS operators who wish to participate in the collection, and have
not already done so, should join the d...@lists.dns-oarc.net mailing list[0]
in the next week or so.  Announcements will be made in early February, on the
DITL mailing list, regarding the specifics of this year's collection.  This is
the only notice about the collection that will be sent to this list.

A reminder that the DITL mailing list has a strict “no spectators” policy.
Only contributors to the collection will be permitted to subscribe.


About the Day in the Life Collection


Every year, DNS OARC runs a data collection event known as the Day in the Life
collection.  DNS operators from around the globe run packet captures over the
same 48 hour period, and contribute them to the community for ongoing research
into the activity of the global DNS.  DITL data gathered will be made
available to OARC Members and to researchers under the terms of the OARC Data
Sharing Agreement[1].  Research using the data sets has strict requirements
regarding aggregation and anonymization, and is always made public.

OARC seeks to receive contributions from root server operators, TLD operators,
AS112 server operators, operators of other significant authoritative zones
(such as RIR reverse zones and major commercial services), and recursive
operators.

Although there are no hard and fast limits, we hope to see contributions from
recursive services with clients in the high hundreds to low tens of thousands
of clients.  Recursive operators such as universities, small to medium sized
ISPs, and large enterprises are ideal. Recursive server collections are always
made “above” the server, between the recursive and authoritative, and not
between the recursive and the end-user, so end-user privacy should not be an
issue.

More information about the DITL collections can be found here:


Matt Pounsett
DNS-OARC Systems Engineering


[0]: 
[1]: 



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] MastoDNS opening up to DNS community registration

[Matthew Pounsett]

For several months, DNS-OARC has been operating a DNS community Mastodon 
instance at MastoDNS.net. Up until now it has only been open to OARC Member & 
Supporter organizations, but we would now like to invite the wider DNS 
community to join us.  MastoDNS will join our mailing lists, Mattermost chat 
server, and regular hybrid in-person/remote workshops as another way for the 
DNS community to share experience.

If you would like an account, please go to  and register.

Thanks everyone, and see you on Mastodon!

Matt Pounsett
DNS-OARC Systems Engineering




signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

[Matthew Pounsett]

Have you tried contacting the IANA or the IAB?  Those are the two
organizations responsible for the technical and administrative for
that zone... and I note that neither of them are copied on your email.
Directly reaching out to either or both of them may be more productive
than posting to dns-operations.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

[Matthew Pounsett]

On Thu, Jun 22, 2023 at 10:44 AM Viktor Dukhovni  wrote:
>
>
> Which of the below would you suggest?
>
> SOA rname:ns...@iana.org
> WHOIS Administrative: i...@iab.org
> WHOIS Technical:  tld-cont...@iana.org

I would have started with the IANA addresses, since they publish the
zone and operate the name servers where this misconfiguration exists.
IANA also happens to be one of the more technically responsive
organizations I've ever had the pleasure to deal with.  But it looks
like you got the PTI president's attention on-list anyway. :)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Why is DNS still hard to learn?

[Matthew Pounsett]

On Mon, Jul 31, 2023 at 12:42 PM Vladimír Čunát via dns-operations
 wrote:
>
>
>
> For reference, in May there was a (slightly heated) discussion about this 
> article on OARC's public chat:
> https://chat.dns-oarc.net/community/pl/ccajpprxttnmzj5a8mh4hh1kua

Same author, different article.
https://jvns.ca/blog/2023/07/28/why-is-dns-still-hard-to-learn/
vs.
https://jvns.ca/blog/2023/05/12/introducing-implement-dns-in-a-weekend/

And, as a lot of people pointed out, the controversy was more about
the title than the content.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] cmdns.dev.dns-oarc.net down?

[Matthew Pounsett]

On Tue, Sep 5, 2023 at 6:58 AM Christoph via dns-operations
 wrote:
>
> in case that is useful: dns.google was also unable to reach the
> nameservers at the time.

What Jerry is saying is that the CMDNS application consists (in part)
of a custom DNS server.  The application was down, hence no DNS
responses.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Organizing DNS-OARC's "DITL 2024" collection

[Matthew Pounsett]

[Apologies to those who have seen this on multiple lists.]

OARC is beginning planning for the 2024 Day in the Life (DITL) collection.
Community DNS operators who wish to participate in the collection, and have
not already done so, should join the d...@lists.dns-oarc.net mailing list[0]
in the next week.  An announcement will be made on March 13th, on the DITL
mailing list, regarding the specifics of this year's collection.  This is the
only notice about the collection that will be sent to this list.

A reminder that the DITL mailing list has a strict “no spectators” policy.
Only contributors to the collection will be permitted to subscribe.


About the Day in the Life Collection


Every year, DNS OARC runs a data collection event known as the Day in the Life
collection.  DNS operators from around the globe run packet captures over the
same 48 hour period, and contribute them to the community for ongoing research
into the activity of the global DNS.  DITL data gathered will be made
available to OARC Members and to researchers under the terms of the OARC Data
Sharing Agreement[1].  Research using the data sets has strict requirements
regarding aggregation and anonymization, and is always made public.

OARC seeks to receive contributions from root server operators, TLD operators,
AS112 server operators, operators of other significant authoritative zones
(such as RIR reverse zones and major commercial services), and recursive
operators.

Although there are no hard and fast limits, we hope to see contributions from
recursive services with clients in the high hundreds to low tens of thousands
of clients.  Recursive operators such as universities, small to medium sized
ISPs, and large enterprises are ideal. Recursive server collections are always
made “above” the server, between the recursive and authoritative, and not
between the recursive and the end-user, so end-user privacy should not be an
issue.

More information about the DITL collections can be found here:


Matt Pounsett
DNS-OARC Systems Engineering


[0]: 
[1]: 



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations