[dns-operations] ... one of the more annoying captive portal breakages I've seen...

[Warren Kumari]

So, I'm sitting in a hotel in Melbourne (APRICOT20), trying to get
some work done[0].

They have a captive portal which a: logs you our fairly often and b:
requires you use their DNS server. Ugh, but OK.

..but, they have managed to invent some new, and interesting failure
mode - if I look up a name which isn't in the cache, I *immediatly*
get back a SERVFAIL. Ask the question a bunch more times, and after a
few seconds you start getting an answer.

$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47760
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3344
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48739
 [ continues for ~4 seconds ]
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3417
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58153
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23212

So, this is annoying, but kind-of possibly, if you squint really hard, OK.
but, the other failure mode (which I'm having a hard time capturing at
the moment) goes:
NXDOMAIN
NXDOMAIN
NXDOMAIN
ANSWER!

This behavior is baffling - other than intentionally, how do you
managed to break something this badly / in this way!?

Oh, I just needed to rant a bit...

W
[0]: Yeah, ok, I was trying to reach Reddit.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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?

[Mark Andrews]

> On 20 Feb 2020, at 03:36, 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/
> 
> 1. There are old DS keys from .arpa to in-addr.arpa still dangling around.

Which, while messy, doesn’t cause operational problems to validators.

> 2. 158.in-addr.arpa is still using ‘Algorithm 5’
> 3. Even though my 158.108.0.0/16 netblock was ROAed, APNIC did not link me to 
> the ‘reverse’ DNSsec chain:

ROAs are orthogonal to DNSSEC.  Nobody in the world had DNSSEC records changed 
because a ROA for address space was issued.

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

Who do you submit your NS records to update your delegation?  The DS records go 
to EXACTLY the same entity.  In this case it is APNIC.

The RIR’s send blobs of RRsets to each other to handle cross region delegations 
like this.  They can send DS records
just as easily as they send NS records.

> Shall we move on to another netblock?
> 
> 
> Pirawat.
> 
> 
> On Wed, Feb 19, 2020 at 10:25 PM Edward Lewis  wrote:
> I've been doing some examinations of ip6.arpa and in-addr.arpa as part of 
> other work and I'd say they are pretty darn clean as they are.  So I (too) am 
> curious what would be needed as part of a "Flag Day" level clean up.
> 
>  
> 
> I'm looking at the delegation information in the two zones and the 
> information at the zones they delegate.  As far as delegations from those 
> zones to RIR run zones, I'd say they are perfect.  For a while there were two 
> zones with misaligned NS sets, but they were "fixed" rather speedily last 
> week.  (There's no glue in the zones.)
> 
>  
> 
> What I mean by "delegations from those zones to RIR run zones" means that 
> there are a few delegations from ip6.arpa and in-addr.arpa that go to 
> non-RIRs or are "special" (like 10.in-addr.arpa).  Of those, there are some 
> hiccups but that is something that is best handled by addressing the 
> individual situation.  I don't see a "Flag Day" level concern - thus my 
> curiosity above.
> 
>  
> 
> On 2/14/20, 2:24 PM, "dns-operations on behalf of Ondřej Surý" 
>  wrote:
> 
>  
> 
> Hi, 
> 
>  
> 
> the DNS Flag Days initiative focus on protocol issues, and neither forward or 
> reverse zones are in the focus.
> 
>  
> 
> If you have anything specific you could bring this up here. How is the .arpa 
> neglected?
> 
> Ondrej
> 
> -- 
> 
> Ondřej Surý 
> 
> 
> 
> 
> On 14 Feb 2020, at 18:22, Pirawat WATANAPONGSE  wrote:
> 
> 
> If you think my topic is irrelevant to DNS Flag Day 2020, or if someone has 
> already mentioned it, I do apologize.
> 
> My reasoning is that the campaign is lopsided; we are focusing on the 
> ‘forward’ zones (because those are our children, bear our names, and we like 
> to brag), but the 2 huge ‘reverse’ zones are neglected (because they are the 
> bastard children).
> 
> Anyone plans to clean up the ‘in-addr.arpa.’ and ‘ip6.arpa.’ this upcoming 
> Flag Day? Or it is not a priority (just yet) at this moment?
> 
> By the way, do not confuse properly scaffolding the (reverse) zones from 
> populating them; from my point of view, they are separate issues. Even if you 
> are ever going to put just one PTR into it, a properly secured, hierarchized, 
> delegated (reverse) zone is still crucial.
> 
> 
> My two cents’ worth,
> 
> Pirawat.
> 
>  
> 
> -- 
> 
> _/_/  _/_/ _/_/   _/_/ Assist.Prof. Pirawat WATANAPONGSE, 
> Ph.D.
> 
>_/_/_/_/   _/_/   _/_/ Department of Computer Engineering
> 
>   _/_/  _/_/ _/_/   _/_/ Kasetsart University, Bangkhen (Main) 
> Campus
> 
>  _/_/_/_/   _/_/   _/_/ Bangkok 10900, THAILAND
> 
> _/_/_/_/   _/_/   _/_/ eMail: pirawa...@ku.th or 
> pirawa...@ku.ac.th
> 
>_/_/  _/_/ _/_/   _/_/ Tel: +66 2 797 0999 extension 1417
> 
>   _/_/_/_/_/_/_/_/_/_/ Fax: +66 2 579 6245
> 
> _/_/  _/_/  _/_/_/_/http://www.cpe.ku.ac.th/~pw/
> 
>  
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> 
> -- 
> _/_/  _/_/ _/_/   _/_/ Assist.Prof. Pirawat WATANAPONGSE, 
> Ph.D.
>_/_/_/_/   _/_/   _/_/ Department of Computer Engineering
>   _/_/  _/_/ _/_/   _/_/ Kasetsart University, Bangkhen (Main) 
> Campus
>  _/_/_/_/   _/_/   _/_/ Bangkok 10900, THAILAND
> _/_/_/_/   _/_/   _/_/ eMail: 

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

[Edward Lewis]

I think the reaction you are getting is due to the call for a "DNS Flag Day" 
and not the issues you are experiencing.  On this list (DNS-operations), DNS 
Flag Day (2019) was a significant event involving many implementations of the 
DNS protocol to adhere more closely with the specifications of the protocol.  A 
goal was to simplify the code bases involved.

You seem to be asking for some changes in the registration information 
regarding (for one here) a netblock.

On 2/19/20, 11:45 AM, "dns-operations on behalf of 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/
>
>1. There are old DS keys from .arpa to in-addr.arpa still dangling around.
>2. 158.in-addr.arpa is still using ‘Algorithm 5’
>3. Even though my http://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.

As this is a DNS operations list and not an RIR list, you may be addressing the 
wrong audience.

Think of ARIN as the DNS hoster.  They produce the 158 zone.  They take data 
from the other RIRs to assemble it.  That's why the SOA RNAME has arin.net in 
it.

Think of APNIC as the registry.  Your registration interaction is with APNIC.  
... ummm ... When I wrote that I recalled you mentioning an NIR.  I am not sure 
how the TH NIR runs.  As in, the JP NIR does run 133.in-addr.arpa, but no other 
NIR runs such a zone; and only JP's NIR has a whois service that uniquely 
services their registrations.  So, I don't know if you need to find the TH NIR 
or go to APNIC directly. ... which leads me to believe you might be on the 
wrong list with this.




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

[Tony Finch]

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

This might be part of a rollover plan (I don't track changes to .arpa so
I can't tell how old the DS records are)

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

Yes, this needs fixing.

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

Yes, it is complicated, especially for legacy allocations, but I don't
think it is particularly broken.

I have a similar situation with the reverse DNS for 131.111.0.0/16. The
registration for the address block is with RIPE, but the reverse DNS
delegation is via ARIN.

The way this works is that I do all administration via RIPE (configuring
NS and DS records, etc.), and RIPE send zone file fragments to ARIN, which
incorporate them into the DNS. I think I found out about this from an
outage report a few years ago:

https://labs.ripe.net/Members/anandb/reverse-dns-outage-for-out-of-region-address-space

The situation for whois is somewhat worse than the reverse DNS. I've done
some work on the FreeBSD whois client, which tries to work by following
referrals instead of having built-in knowledge about which whois servers
to ask. This mostly works OK, except that APNIC and RIPE don't put any
kind of referral in their whois responses even though they know which
other RIR is responsible for the adress block. When that happens my whois
client tries ARIN (which usually works) or falls back to trying each RIR
in turn...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Northeasterly 5 to 7, occasionally gale 8 later in southeast,
becoming variable 4 in northwest. Moderate or rough. Showers. Moderate or
good.___
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

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

[Pirawat WATANAPONGSE]

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/

1. There are old DS keys from .arpa to in-addr.arpa still dangling around.
2. 158.in-addr.arpa is still using ‘Algorithm 5’
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.

Shall we move on to another netblock?


Pirawat.


On Wed, Feb 19, 2020 at 10:25 PM Edward Lewis 
wrote:

> I've been doing some examinations of ip6.arpa and in-addr.arpa as part of
> other work and I'd say they are pretty darn clean as they are.  So I (too)
> am curious what would be needed as part of a "Flag Day" level clean up.
>
>
>
> I'm looking at the delegation information in the two zones and the
> information at the zones they delegate.  As far as delegations from those
> zones to RIR run zones, I'd say they are perfect.  For a while there were
> two zones with misaligned NS sets, but they were "fixed" rather speedily
> last week.  (There's no glue in the zones.)
>
>
>
> What I mean by "delegations from those zones to RIR run zones" means that
> there are a few delegations from ip6.arpa and in-addr.arpa that go to
> non-RIRs or are "special" (like 10.in-addr.arpa).  Of those, there are some
> hiccups but that is something that is best handled by addressing the
> individual situation.  I don't see a "Flag Day" level concern - thus my
> curiosity above.
>
>
>
> On 2/14/20, 2:24 PM, "dns-operations on behalf of Ondřej Surý" <
> dns-operations-boun...@dns-oarc.net on behalf of ond...@sury.org> wrote:
>
>
>
> Hi,
>
>
>
> the DNS Flag Days initiative focus on protocol issues, and neither forward
> or reverse zones are in the focus.
>
>
>
> If you have anything specific you could bring this up here. How is the
> .arpa neglected?
>
> Ondrej
>
> --
>
> Ondřej Surý 
>
>
>
> On 14 Feb 2020, at 18:22, Pirawat WATANAPONGSE  wrote:
>
>
> If you think my topic is irrelevant to DNS Flag Day 2020, or if someone
> has already mentioned it, I do apologize.
>
> My reasoning is that the campaign is lopsided; we are focusing on the
> ‘forward’ zones (because those are our children, bear our names, and we
> like to brag), but the 2 huge ‘reverse’ zones are neglected (because they
> are the bastard children).
>
> Anyone plans to clean up the ‘in-addr.arpa.’ and ‘ip6.arpa.’ this upcoming
> Flag Day? Or it is not a priority (just yet) at this moment?
>
> By the way, do not confuse properly scaffolding the (reverse) zones from
> populating them; from my point of view, they are separate issues. Even if
> you are ever going to put just one PTR into it, a properly secured,
> hierarchized, delegated (reverse) zone is still crucial.
>
>
> My two cents’ worth,
>
> Pirawat.
>
>
>
> --
>
> _/_/  _/_/ _/_/   _/_/ Assist.Prof. Pirawat WATANAPONGSE,
> Ph.D.
>
>_/_/_/_/   _/_/   _/_/ Department of Computer Engineering
>
>   _/_/  _/_/ _/_/   _/_/ Kasetsart University, Bangkhen (Main)
> Campus
>
>  _/_/_/_/   _/_/   _/_/ Bangkok 10900, THAILAND
>
> _/_/_/_/   _/_/   _/_/ eMail: pirawa...@ku.th or
> pirawa...@ku.ac.th
>
>_/_/  _/_/ _/_/   _/_/ Tel: +66 2 797 0999 extension 1417
>
>   _/_/_/_/_/_/_/_/_/_/ Fax: +66 2 579 6245
>
> _/_/  _/_/  _/_/_/_/http://www.cpe.ku.ac.th/~pw/
>
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>

-- 
_/_/  _/_/ _/_/   _/_/ Assist.Prof. Pirawat WATANAPONGSE,
Ph.D.
   _/_/_/_/   _/_/   _/_/ Department of Computer Engineering
  _/_/  _/_/ _/_/   _/_/ Kasetsart University, Bangkhen (Main)
Campus
 _/_/_/_/   _/_/   _/_/ Bangkok 10900, THAILAND
_/_/_/_/   _/_/   _/_/ eMail: pirawa...@ku.th or
pirawa...@ku.ac.th
   _/_/  _/_/ _/_/   _/_/ Tel: +66 2 797 0999 extension 1417
  _/_/_/_/_/_/_/_/_/_/ Fax: +66 2 579 6245
_/_/  _/_/  _/_/_/_/http://www.cpe.ku.ac.th/~pw/
___
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?

[Tony Finch]

Edward Lewis  wrote:
>
> I'm looking at the delegation information in the two zones and the
> information at the zones they delegate.  As far as delegations from
> those zones to RIR run zones, I'd say they are perfect.

Except that ARIN and LACNIC use RSASHA1 :-(

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Mull of Kintyre to Ardnamurchan Point: South 6 to gale 8 veering southwest 4
or 5, then west 6 to gale 8 later. Moderate in shelter, otherwise rough or
very rough, but occasionally high later near Tiree. Rain then showers.
Moderate or good, occasionally poor.
___
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?

[Edward Lewis]

I've been doing some examinations of ip6.arpa and in-addr.arpa as part of other 
work and I'd say they are pretty darn clean as they are.  So I (too) am curious 
what would be needed as part of a "Flag Day" level clean up.

I'm looking at the delegation information in the two zones and the information 
at the zones they delegate.  As far as delegations from those zones to RIR run 
zones, I'd say they are perfect.  For a while there were two zones with 
misaligned NS sets, but they were "fixed" rather speedily last week.  (There's 
no glue in the zones.)

What I mean by "delegations from those zones to RIR run zones" means that there 
are a few delegations from ip6.arpa and in-addr.arpa that go to non-RIRs or are 
"special" (like 10.in-addr.arpa).  Of those, there are some hiccups but that is 
something that is best handled by addressing the individual situation.  I don't 
see a "Flag Day" level concern - thus my curiosity above.

On 2/14/20, 2:24 PM, "dns-operations on behalf of Ondřej Surý" 
mailto:dns-operations-boun...@dns-oarc.net>
 on behalf of ond...@sury.org> wrote:

Hi,

the DNS Flag Days initiative focus on protocol issues, and neither forward or 
reverse zones are in the focus.

If you have anything specific you could bring this up here. How is the .arpa 
neglected?

Ondrej
--
Ondřej Surý 


On 14 Feb 2020, at 18:22, Pirawat WATANAPONGSE  wrote:

If you think my topic is irrelevant to DNS Flag Day 2020, or if someone has 
already mentioned it, I do apologize.

My reasoning is that the campaign is lopsided; we are focusing on the ‘forward’ 
zones (because those are our children, bear our names, and we like to brag), 
but the 2 huge ‘reverse’ zones are neglected (because they are the bastard 
children).

Anyone plans to clean up the ‘in-addr.arpa.’ and ‘ip6.arpa.’ this upcoming Flag 
Day? Or it is not a priority (just yet) at this moment?

By the way, do not confuse properly scaffolding the (reverse) zones from 
populating them; from my point of view, they are separate issues. Even if you 
are ever going to put just one PTR into it, a properly secured, hierarchized, 
delegated (reverse) zone is still crucial.


My two cents’ worth,

Pirawat.

--
_/_/  _/_/ _/_/   _/_/ Assist.Prof. Pirawat WATANAPONGSE, Ph.D.
   _/_/_/_/   _/_/   _/_/ Department of Computer Engineering
  _/_/  _/_/ _/_/   _/_/ Kasetsart University, Bangkhen (Main) 
Campus
 _/_/_/_/   _/_/   _/_/ Bangkok 10900, THAILAND
_/_/_/_/   _/_/   _/_/ eMail: 
pirawa...@ku.th or 
pirawa...@ku.ac.th
   _/_/  _/_/ _/_/   _/_/ Tel: +66 2 797 0999 extension 1417
  _/_/_/_/_/_/_/_/_/_/ Fax: +66 2 579 6245
_/_/  _/_/  _/_/_/_/http://www.cpe.ku.ac.th/~pw/

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

Re: [dns-operations] DNSViz Status?

[Arsen STASIC]

Hi Casey,

* Casey Deccio  [2020-02-18 15:54 (-0700)]:

On Feb 17, 2020, at 1:37 AM, Marco Davids (Private) via dns-operations 
 wrote:
Op 14-02-2020 om 16:09 schreef Vladimír Čunát:


For me personally, the old historical data isn't much interesting.  What
I'm missing most is the feature of sending a link to a recent
measurement (and keeping the data for, say, a week at least).


Exactly!

I really hope we can have that functionality back, someday soon.


Hi Marco and all,

Thanks for the valuable feedback.  Matt and I were working just last week on getting a 
new database up and running, so "permalinks" can be used to save an analysis.  
We hope to have it done very soon!


Thats great news!
I really appreciate your effort.

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