Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-09 Thread sthaug 
> 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.

But not universal. Both of these queries work fine from my vantage
point in Oslo, Norway. Traceroute shows 2001:500:2f::f as local,
while 2001:500:2::c seems to be in Hamburg.

Steinar Haug, AS2116
___
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?

2019-10-09 Thread 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?

2019-10-09 Thread Viktor Dukhovni 
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 still see no answers from C or F from NYC via a Hurrican Electric
GRE tunnel, since my ISP (Verizon FiOS) still does not provide
native IPv6. :-(

$ dig +short -t ns arpa. | sort |
while read ns; do
  dig +short -t  $ns |
  while read ip; do
echo "@$ns[$ip]:"
dig -6 +norecur +noall +ans +nocl +nottl -t soa arpa. @$ip
  done
done

I get (for both UDP and TCP):

@a.root-servers.net.[2001:503:ba3e::2:30]:
@b.root-servers.net.[2001:500:200::b]:
@d.root-servers.net.[2001:500:2d::d]:
@e.root-servers.net.[2001:500:a8::e]:
@g.root-servers.net.[2001:500:12::d0d]:
@h.root-servers.net.[2001:500:1::53]:
@i.root-servers.net.[2001:7fe::53]:
@k.root-servers.net.[2001:7fd::1]:
@l.root-servers.net.[2001:500:9f::42]:
@m.root-servers.net.[2001:dc3::35]:
arpa.   SOA a.root-servers.net. nstld.verisign-grs.com. 
2019101000 1800 900 604800 86400

@c.root-servers.net.[2001:500:2::c]:
@f.root-servers.net.[2001:500:2f::f]:
;; connection timed out; no servers could be reached

$ traceroute6 c.root-servers.net.
 1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  5.364 ms  4.937 ms  6.851 
ms
 2  ve422.core1.nyc4.he.net  5.516 ms  5.214 ms  3.592 ms
 3  * * *
 4  * * *
 5  * * *
 6  * *^C

$ traceroute6 f.root-servers.net.
 1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  8.442 ms  6.772 ms  7.252 
ms
 2  ve422.core1.nyc4.he.net  4.641 ms  3.155 ms  5.392 ms
 3  100ge16-1.core1.ash1.he.net  10.781 ms  21.786 ms  8.046 ms
 4  100ge10-2.core1.lax1.he.net  65.768 ms  63.279 ms  62.687 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * *^C

$ traceroute6 b.root-servers.net.
 1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  7.586 ms  5.679 ms  6.274 
ms
 2  ve422.core1.nyc4.he.net  2.290 ms  3.214 ms  3.492 ms
 3  100ge16-1.core1.ash1.he.net  30.615 ms  22.676 ms  10.004 ms
 4  100ge8-2.core1.atl1.he.net  19.438 ms  21.777 ms  22.249 ms
 5  100ge5-1.core1.tpa1.he.net  32.631 ms  33.048 ms  31.741 ms
 6  100ge12-1.core1.mia1.he.net  38.909 ms  35.077 ms  36.040 ms
 7  2001:478:124::241  40.241 ms  36.194 ms  36.724 ms
 8  2800:bc0:0:42::12  36.672 ms  36.952 ms  36.865 ms
 9  2001:500:205:5::2  36.565 ms  38.712 ms  36.606 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  *^C

Perhaps the issue is on the HE.net side?  Don't know whether that's
expected.  Doing the test from a server in .DE where I have a guest
account, I get answers from all the roots:

@a.root-servers.net.[2001:503:ba3e::2:30]:
@b.root-servers.net.[2001:500:200::b]:
@c.root-servers.net.[2001:500:2::c]:
@d.root-servers.net.[2001:500:2d::d]:
@e.root-servers.net.[2001:500:a8::e]:
@f.root-servers.net.[2001:500:2f::f]:
@g.root-servers.net.[2001:500:12::d0d]:
@h.root-servers.net.[2001:500:1::53]:
@i.root-servers.net.[2001:7fe::53]:
@k.root-servers.net.[2001:7fd::1]:
@l.root-servers.net.[2001:500:9f::42]:
@m.root-servers.net.[2001:dc3::35]:
arpa.   SOA a.root-servers.net. nstld.verisign-grs.com. 
2019101000 1800 900 604800 86400

But it seems that DNSViz and I are (still) in the same situation
with regard to the C and F IPv6 roots.

http://dnsviz.net/d/arpa/dnssec/

The IPv4 anycasts work fine:

@a.root-servers.net.[198.41.0.4]:
@b.root-servers.net.[199.9.14.201]:
@c.root-servers.net.[192.33.4.12]:
@d.root-servers.net.[199.7.91.13]:
@e.root-servers.net.[192.203.230.10]:
@f.root-servers.net.[192.5.5.241]:
@g.root-servers.net.[192.112.36.4]:
@h.root-servers.net.[198.97.190.53]:
@i.root-servers.net.[192.36.148.17]:
@k.root-servers.net.[193.0.14.129]:
@l.root-servers.net.[199.7.83.42]:
@m.root-servers.net.[202.12.27.33]:
arpa.   SOA a.root-servers.net. nstld.verisign-grs.com. 
2019101000 1800 900 604800 86400

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

2019-10-09 Thread Viktor Dukhovni 
On Wed, Oct 09, 2019 at 10:46:11PM +0200, A. Schulze wrote:

> while debugging a PTR resolution problem I noticed warnings on
> http://dnsviz.net/d/ip6.arpa/dnssec/ and
> http://dnsviz.net/d/in-addr.arpa/dnssec/
> To me, it looks like some in-addr-servers.arpa servers are unable to handle 
> large responses.

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.

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

[dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-09 Thread A. Schulze 
Hello,

while debugging a PTR resolution problem I noticed warnings on 
http://dnsviz.net/d/ip6.arpa/dnssec/ and 
http://dnsviz.net/d/in-addr.arpa/dnssec/
To me, it looks like some in-addr-servers.arpa servers are unable to handle 
large responses.

$ dig ip6.arpa. dnskey +dnssec
...
;; MSG SIZE  rcvd: 1329

$ dig in-addr.arpa. dnskey +dnssec
...
;; MSG SIZE  rcvd: 1341


Anybody agree, there is potential for operational improvements?

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

Re: [dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

2019-10-09 Thread Dave Lawrence 
Viktor Dukhovni writes:
> Yes, the expected behaviour when you explicitly request a CNAME
> record is that (modulo DNAMEs in some parent zone) the qname is
> resolved without further indirection, returning a CNAME if present
> there, NXDOMAIN if the qname does not exist, or else NODATA.

Spot on.  I'd briefly considered the possibility that this was an
amusing underspecified edge-case involving language about restarting
the query when a CNAME is encountered, but even in 1980s RFC-speak,
RFC 1034 section 3.6.2 was pretty clear on this:

"When a name server fails to find a desired RR in the resource set
associated with the domain name, it checks to see if the resource
set consists of a CNAME record with a matching class."

So, looking up qtype CNAME finds the desired RR and the subordinate
clause is not triggered.  But just to make it crystal clear, it goes
on to say, regarding an example of a USC-ISIC.ARPA alias pointing to
C.ISI.EDU with an address record:

"Both of these RRs would be returned in the response to the 
type A query, while a type CNAME or * [ANY] query should return
just the CNAME."
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

2019-10-09 Thread David 

On 2019-10-09 8:36 a.m., Joe Abley wrote:

On 9 Oct 2019, at 09:51, David  wrote:


On 2019-10-09 3:28 a.m., Vladimír Čunát wrote:

On 10/9/19 8:53 AM, Xavier Beaudouin wrote:

I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.

I expect that's due to newer Androids getting to more people? (i.e. it seems 
unrelated to OP)
https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html


Yeah we see that too but you are correct we are referring to normal plain-old 
DNS over TCP. We're now at 10x the query rates compared to pre-iOS 13, which is 
still not a lot but is growing each day.


Are there any obvious patterns with QNAMEs or with the servers that receive 
those queries? I wonder whether there's some new query pattern that has started 
triggering large responses and whether what we are seeing is iOS falling back 
to TCP transport due to failures in receiving fragments. It'd be interesting to 
look for other increases within the messages being exchnged over TCP, e.g. an 
unusual preponderance of DO=1 or QTYPE=TLSA or something.


The queries I've seen from these are pretty basic and all fit without 
needing EDNS or TCP. I'm also not entirely sure it's due to any loss 
detection either, as when they do switch to doing over TCP we don't 
immediately see the previous over-UDP-query again.




The observation reminds me of the iOS release that started pulling root zone DNSSEC trust 
anchors from data.iana.org  almost a decade ago. The CDN stats 
for data.iana.org  at the time revealed what looked initially 
like a step function but in fact was a steep curve tracking iOS upgrades amongst the 
iPhone-owning public. We found someone at Apple to talk to at the time to confirm that our 
interpretation was correct. If iOS deployment is the curve you're seeing, then I imagine 
you can expect more growth than 10x before you see a plateau.



We've been in touch with the Apple NOC and provided them captures, 
hoping that they can engage the appropriate resources internally to 
confirm what is going on.



Of course, many commonly-used applications tend to upgrade around an iOS upgrade. With 
iOS 13 there seem to be many popular social media apps releasing versions with this 
"dark mode" that I understand the youth like now.



Yeah - the spread of names is not application specific so does look like 
the iOS resolver itself doing it, and not a specific application bug 
(like the snapchat NTP issue a few years ago where it probed every 
country code out there repeatedly).




Joe



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

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

2019-10-09 Thread Joe Abley 
On 9 Oct 2019, at 09:51, David  wrote:

> On 2019-10-09 3:28 a.m., Vladimír Čunát wrote:
>> On 10/9/19 8:53 AM, Xavier Beaudouin wrote:
>>> I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.
>> I expect that's due to newer Androids getting to more people? (i.e. it seems 
>> unrelated to OP)
>> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>>  
> 
> Yeah we see that too but you are correct we are referring to normal plain-old 
> DNS over TCP. We're now at 10x the query rates compared to pre-iOS 13, which 
> is still not a lot but is growing each day.

Are there any obvious patterns with QNAMEs or with the servers that receive 
those queries? I wonder whether there's some new query pattern that has started 
triggering large responses and whether what we are seeing is iOS falling back 
to TCP transport due to failures in receiving fragments. It'd be interesting to 
look for other increases within the messages being exchnged over TCP, e.g. an 
unusual preponderance of DO=1 or QTYPE=TLSA or something.

The observation reminds me of the iOS release that started pulling root zone 
DNSSEC trust anchors from data.iana.org  almost a decade 
ago. The CDN stats for data.iana.org  at the time 
revealed what looked initially like a step function but in fact was a steep 
curve tracking iOS upgrades amongst the iPhone-owning public. We found someone 
at Apple to talk to at the time to confirm that our interpretation was correct. 
If iOS deployment is the curve you're seeing, then I imagine you can expect 
more growth than 10x before you see a plateau.

Of course, many commonly-used applications tend to upgrade around an iOS 
upgrade. With iOS 13 there seem to be many popular social media apps releasing 
versions with this "dark mode" that I understand the youth like now.


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

Re: [dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

2019-10-09 Thread Daniel McCarney 
[posting in a personal capacity]

> Let's Encrypt is in general very happy to follow indirections

I believe the CNAME processing being discussed in this thread is
standard practice for CAs beyond Let's Encrypt / ACME / RFC 8555 that
perform domain validation through the "DNS change" mechanism outlined
by the CA/browser forum baseline requirements. That section of the BRs
(3.2.2.4.7 of v1.6.6) explicitly (though with limited detail) mentions
CNAMEs:

> Confirming the Applicant's control over the FQDN by confirming the presence of
> a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record
> for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name
> that is prefixed with a label that begins with an underscore character.

As a concrete example Amazon's Certificate Manager product handles DNS
validation through CNAME in a similar fashion. See "Why does ACM use
CNAME records for DNS validation instead of TXT records?" in the FAQ:
https://aws.amazon.com/certificate-manager/faqs/

On Wed, Oct 9, 2019 at 8:00 AM Tony Finch  wrote:
>
> Rob Seastrom  wrote:
> >
> > I might add that I was slightly surprised that this works - it seems
> > unaddressed in the ACME spec but kind of feels like a potential attack
> > surface tparticularly since it works even to a non-child,
> > non-same-origin (pedantically, not quite "out of baliwick" but YKWIM)
> > zone.
>
> Viktor has answered your question, but wrt this point, Let's Encrypt is in
> general very happy to follow indirections, whether CNAMEs for dns-01 or
> redirects for http-01. RFC 8555 mentions HTTP redirects but not CNAMEs.
> Both kinds of aliasing allow for lots of fun games.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Trafalgar: Northerly or northeasterly 4 to 6, increasing 7 at times in east.
> Rough or very rough. Fair. Good.
> ___
> 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] DNS over TCP query uptick with iOS 13?

2019-10-09 Thread David 

On 2019-10-09 3:28 a.m., Vladimír Čunát wrote:

On 10/9/19 8:53 AM, Xavier Beaudouin wrote:

I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.


I expect that's due to newer Androids getting to more people? (i.e. it 
seems unrelated to OP)
https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html 



Yeah we see that too but you are correct we are referring to normal 
plain-old DNS over TCP. We're now at 10x the query rates compared to 
pre-iOS 13, which is still not a lot but is growing each day.





--Vladimir

___
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] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

2019-10-09 Thread Tony Finch 
Rob Seastrom  wrote:
>
> I might add that I was slightly surprised that this works - it seems
> unaddressed in the ACME spec but kind of feels like a potential attack
> surface tparticularly since it works even to a non-child,
> non-same-origin (pedantically, not quite "out of baliwick" but YKWIM)
> zone.

Viktor has answered your question, but wrt this point, Let's Encrypt is in
general very happy to follow indirections, whether CNAMEs for dns-01 or
redirects for http-01. RFC 8555 mentions HTTP redirects but not CNAMEs.
Both kinds of aliasing allow for lots of fun games.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Northerly or northeasterly 4 to 6, increasing 7 at times in east.
Rough or very rough. Fair. Good.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

2019-10-09 Thread Vladimír Čunát 

On 10/9/19 8:53 AM, Xavier Beaudouin wrote:

I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.


I expect that's due to newer Androids getting to more people? (i.e. it 
seems unrelated to OP)

https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html

--Vladimir

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

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

2019-10-09 Thread Xavier Beaudouin 
Hi !

I work for a Luxembourg company that provide Wifi in the street of luxembourg 
cities (and some other places too).

I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.

I don't have any graphs about its usage but yes our dnsdist is more and more 
used.

(have to figure how to make nice statistics with librenms)

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