Re: HE.net problem

[Alarig Le Lay via NANOG]

On Thu 04 Jul 2024 18:16:28 GMT, Randy Bush wrote:
> hak whacked me to add
> http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html
> to my nagios deployment.
> 
> anyone have some known sick in various ways dns zones against which to
> test?

Those domains are broken on purpose:
https://www.internetsociety.org/resources/deploy360/2013/dnssec-test-sites/

On the domains that I host I also check for SOA consistency, AXFR isn’t
known to be that reliable.
For now I use https://github.com/paulla/check_dns_sync but if someone
has some more up to date code it could be better.

-- 
Alarig

Re: PeeringDB Hackathon - looking for feature requests

[Alarig Le Lay]

On Thu 12 Aug 2021 15:27:48 GMT, Steve McManus wrote:
> PeeringDB is looking at participating at an upcoming NANOG Hackathon.
> One of the ideas for a theme is to improve the API. Specifically by
> adding API calls for common use cases that people need to handle
> outside of the API. Typically, by dumping the entire database to SQL
> For example - given two IXes, which networks are present at both? We'd
> like to make a list of such useful queries such that people don't have
> to dump the database just to run them. A stretch goal would be to
> expose into the website instead of requiring API calls.
> 
> This issue has some more detail, including a few existing ideas:
> https://github.com/peeringdb/peeringdb/issues/1020
> 
> Comments there or in email to me would be super helpful. As always, if
> there are other feature requests for PeeringDB, feel free to create an
> issue in github (
> https://github.com/peeringdb/peeringdb/issues/new/choose ) or in
> email, even if they're not strictly Hackathon ideas. They are always
> appreciated!
> 
> Thanks! 
> 
> -Steve
> PeeringDB Product Committee chair

A nice feature could be, while logged in, to highlight the IXPs shared
with the ASN currently displayed.

-- 
Alarig

Re: BGP and The zero window edge

[Alarig Le Lay]

On Thu 22 Apr 2021 01:24:54 GMT, Job Snijders via NANOG wrote:
> One example is 
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2a0b:6b86:d15::/48
> 
> 2a0b:6b86:d15::/48 via:
> BGP.as_path: 204092 57199 35280 6939 42615 42615 212232
> BGP.as_path: 208627 207910 57199 35280 6939 42615 42615 212232
> BGP.as_path: 208627 207910 57199 35280 6939 42615 42615 212232
> (first announced April 15th, last withdrawn April 15th, 2021)

On the AS204092 side, the route is one week and two days old (so
2021-04-16). So we never received the withdrawn.

asbr01#sh bgp ipv6 uni 2a0b:6b86:d15::/48
BGP routing table entry for 2A0B:6B86:D15::/48, version 88407242
BGP Bestpath: deterministic-med: med
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
 129130145167
  Refresh Epoch 1
  57199 35280 6939 42615 42615 212232
2A0B:CBC0:1::BD (FE80::66D1:54FF:FEEF:9893) from 2A0B:CBC0:1::BD 
(80.67.167.5)
  Origin IGP, metric 10, localpref 100, valid, external, best
  Community: 24115:6939 35280:10 35280:1040 35280:2080 35280:3120 
35280:2 35280:21000 35280:21150 57199:35280 57199:65535 64496:100 
64496:57199 64999:24115
  unknown transitive attribute: flag 0xE0 type 0x20 length 0x30
value  5E33  03E9  0001  5E33
   03EA  0002  5E33  03EB
   0005  5E33  03EC  1B1B

  path 7F1E8D0F3B58 RPKI State valid
  rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  57199 35280 6939 42615 42615 212232, (received-only)
2A0B:CBC0:1::BD (FE80::66D1:54FF:FEEF:9893) from 2A0B:CBC0:1::BD 
(80.67.167.5)
  Origin IGP, metric 4294967295, localpref 100, valid, external
  Community: 24115:6939 35280:10 35280:1040 35280:2080 35280:3120 
35280:2 35280:21000 35280:21150 57199:35280 57199:65535 64999:24115
  unknown transitive attribute: flag 0xE0 type 0x20 length 0x30
value  5E33  03E9  0001  5E33
   03EA  0002  5E33  03EB
   0005  5E33  03EC  1B1B

  path 7F1E8D0EF088 RPKI State valid
  rx pathid: 0, tx pathid: 0
asbr01#sh ipv6 route 2a0b:6b86:d15::/48
Routing entry for 2A0B:6B86:D15::/48
  Known via "bgp 204092", distance 20, metric 10, type external
  Route count is 1/1, share count 0
  Routing paths:
FE80::66D1:54FF:FEEF:9893, GigabitEthernet0/0/0.24
  MPLS label: nolabel
  Last updated 1w2d ago

asbr01#

-- 
Alarig

Re: Asus wifi AP re-writing DNS packets

[Alarig Le Lay]

On Thu 29 Oct 2020 02:10:25 GMT, Anurag Bhatia wrote:
> I tried deleting the rule and it drops the traffic completely. So DNS
> resolution stops working and I am unsure why. It's not like default drop or
> anything. I can edit the rule and whatever active port 53 related rule is
> there works. But I want case of no such rule at all. :-)

Did you try to add
-t nat -A POSTROUTING -p tcp -m tcp --dport 53 -j ACCEPT
-t nat -A POSTROUTING -p udp -m udp --dport 53 -j ACCEPT

after the deletion?

-- 
Alarig

Re: Centurylink having a bad morning?

[Alarig Le Lay]

https://www.youtube.com/watch?v=vQ5MA685ApE

On Wed 02 Sep 2020 20:40:35 GMT, Baldur Norddahl wrote:
> That is what the 5G router is for...
> 
> ons. 2. sep. 2020 19.47 skrev Michael Hallgren :
> 
> > While conserving connectivity? 😂
> >
> >
> > --
> > *De :* Shawn L via NANOG 
> > *Envoyé :* mercredi 2 septembre 2020 13:15
> > *À :* nanog
> > *Objet :* Re: Centurylink having a bad morning?
> >
> > We once moved a 3u server 30 miles between data centers this way.  Plug
> > redundant psu into a ups and 2 people carried it out and put them in a
> > vehicle.
> >
> >
> > Sent from my iPhone
> >
> > > On Sep 1, 2020, at 11:58 PM, Christopher Morrow 
> > wrote:
> > >
> > > On Tue, Sep 1, 2020 at 11:53 PM Alain Hebert 
> > wrote:
> > >>
> > >>As a coincidence...  I was *thinking* of moving a 90TB SAN (with
> > mechanical's) to another rack that way...  skateboard, long fibers and long
> > power cords =D
> > >>
> > >
> > > well, what you REALLY need is one of these:
> > >  https://www.cru-inc.com/products/wiebetech/hotplug_field_kit_product/
> > >
> > > and 2-3 UPS... swap to the UPS, then just roll the stack over, plug to
> > > utility and done. (minus network transfer)
> >

Re: DoD IP Space

[Alarig Le Lay]

On 04/11/2019 10:23, Chris Knipe wrote:
> I know that much - but just because it's not advertised, doesn't mean
> you're allowed to use it?  

It means that you’re not supposed to advertise it to your peers, at least.

The usage of public-but-not-used space inside networks isn’t really my
problem as long as it’s not mine (and I never did something like this).

-- 
Alarig

Re: DoD IP Space

[Alarig Le Lay]

Hi,

On lun.  4 nov. 10:55:47 2019, Chris Knipe wrote:
> Hi Guys,
> 
> Except for the email on ARIN's details, does anyone else have a contact for
> the DoD?
> 
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.
> 
> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).

There is no route inside this /8:
bird> show route primary where net ~ [ 22.0.0.0/8+ ]
bird>

Regards,
-- 
Alarig

Re: new BGP hijack & visibility tool “BGPalerter”

[Alarig Le Lay]

Hi,

You can build it yourself, see
https://github.com/nttgin/BGPalerter#more-information-for-developers

I think that the binaries are here for thoses that don’t want to install
all the build-chain.

-- 
Alarig

On 14/08/2019 19:06, Ryan Hamel wrote:
> Job,
>
> I appreciate the effort and the intent behind this project, but why
> should the community contribute to an open source project on GitHub
> that is mainly powered by a closed source binary?
>
> Ryan
>
> On Wed, Aug 14, 2019, 10:55 AM Job Snijders  > wrote:
>
> Dear NANOG,
>
> Recently NTT investigated how to best monitor the visibility of
> our own and our subsidiaries’ IP resources in the BGP Default-Free
> Zone. We were specifically looking how to get near real-time
> alerts funneled into an actionable pipeline for our NOC &
> Operations department when BGP hijacks happen.
>
> Previously we relied on a commercial “BGP Monitoring as a Service”
> offering, but with the advent of RIPE NCC’s “RIS Live” streaming
> API [1] we saw greater potential for a self-hosted approach
> designed specifically for custom integrations with various
> business processes. We decided to write our own tool “BGPalerter”
> and share the source code with the Internet community.
>
> BGPalerter allows operators to specify in great detail how to
> distribute meaningful information from the firehose from various
> BGP data sources (we call them “connectors”), through data
> processors (called “monitors”), finally outputted through
> “reports” into whatever mechanism is appropriate (Slack, IRC,
> email, or a call to your ticketing system’s API). 
>
> The source code is available on Github, under a liberal open
> source license to foster community collaboration:
>
>     https://github.com/nttgin/BGPalerter 
>
> If you wish to contribute to the project, please use Github’s
> “issues” or “pull request” features. Any help is welcome! We’d
> love suggestions for new features, updates to the documentation,
> help with setting up a CI regression testing pipeline, or
> packaging for common platforms.
>
> Kind regards,
>
> Job & Massimo
> NTT Ltd
>
> [1]: https://ris-live.ripe.net/
>

Re: BCP for securing IPv6 Linux end node in AWS

[Alarig Le Lay]

On dim. 14 mai 09:29:45 2017, Eric Germann wrote:
> Good morning all,
> 
> I’m looking for some guidance on best practices to secure IPv6 on
> Linux end nodes parked in AWS.
> 
> Boxes will be running various services (DNS for starters) and I’m
> looking to secure mainly ICMP at this point.  Service filtering is
> fairly cut and dried.  
> 
> I’ve reviewed some of the stuff out there, but apparently I’m catching
> too many of the ICMP types in the rejection as routing eventually
> breaks.  My guess is router discovery gets broken by too tight of
> filters.
> 
> Thanks for any guidance.
> 
> EKG

Hi,

Filtering ICMP breaks Internet and it is even more true with IPv6 as
almost all the bootstrap is based on ICMP (ND, RD, RA, etc.). Plus, you
will break connections where there is a MTU change on the path.

So, my advise is simply to not filter ICMP and ICMPv6. And by the way,
why do want to filter ICMP? You will not be DDoSed with pings.

-- 
alarig


signature.asc
Description: PGP signature

Re: nanog: SixXS is shutting down

[Alarig Le Lay]

On jeu. 23 mars 11:35:05 2017, LHC (k9m) wrote:
> Many people still don't have native IPv6. Why must 6XS die?

The whole reflection is explained here: https://www.sixxs.net/sunset/ but
to abstract, it’s because SixXS became an argument for large provider to
not deploy IPv6 to their end users, as those that want it can use a
broker.

-- 
alarig


signature.asc
Description: PGP signature

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On mer.  8 mars 09:29:11 2017, Marty Strong via NANOG wrote:
> I wouldn’t be surprised if that’s unwanted, where Telstra domestic is
> announcing to Telstra International, who in turn announces to Cogent.

I wouldn’t too, especially since I don’t see it anymore:
alarig@nominoe:~ % birdc6 show route for 2a00:1450:4001:811::2003
BIRD 1.5.0 ready.
2a00:1450:4001::/48 via 2a06:e040:3501:101:2::1 on em0.21 [bgp_quantic 
13:09:29] * (100) [AS15169i]
   via 2a00:5881:8100:ff00::142 on gre0 [bgp_arn_hwhost1 
2017-01-30] (50) [AS15169i]
   via 2a00:5884:ff::13 on gre1 [bgp_arn_hwhost2 2017-01-30] 
(50) [AS15169i]

And quantic now reaches them via HE.

-- 
alarig


signature.asc
Description: PGP signature

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On sam. 25 févr. 09:49:56 2017, Aaron wrote:
> Hi, I'm new to the nanog list, hope this isn't out of scope for what is
> usually discussed here.
> 
>  
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
>  
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?
> 
>  
> 
> -Aaron

Hi,

Since this morning, I see again google routes from cogent:
https://paste.swordarmor.fr/raw/wnFQ

But, with very bad latency. To go from Rennes (France) to Frankfurt
(Germany), it transits via Sydney, and still thought other ASes:
https://paste.swordarmor.fr/raw/PlSM

-- 
alarig


signature.asc
Description: PGP signature

Re: IPv6 doc. prefix (2001:db8::/32) - APNIC object ?

[Alarig Le Lay]

On lun.  6 mars 10:55:18 2017, Brandon Applegate wrote:
> Just did a whois on the documentation prefix and was surprised to see what 
> looks like a user object registered for it:
> 
> % Information related to '2001:0DB8::/32AS132111'
> 
> route6: 2001:0DB8::/32
> descr:  FUTURE D SDN BHD
> origin: AS132111
> country:MY
> mnt-by: MAINT-FUTUREDSDNBHD-MY
> changed:hm-chan...@apnic.net 20160523
> source: APNIC
> 
> Any idea what this is ?  I would have thought there might be some sanity 
> check that would have stopped this from getting registered ?

Hi,

If you look for TEST-NET-3, it is also registered to APNIC:
alarig@pikachu ~ % whois 203.0.113.1
% [whois.apnic.net]
% Whois data copyright termshttp://www.apnic.net/db/dbcopyright.html

% Information related to '203.0.113.0 - 203.0.113.255'

inetnum:203.0.113.0 - 203.0.113.255
netname:TEST-NET-3
descr:  IANA
descr:  RFC5737 Documentation Address Block
country:AU
admin-c:HM20-AP
tech-c: HM20-AP
mnt-by: APNIC-HM
mnt-routes: APNIC-HM
status: ASSIGNED PORTABLE
remarks:-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks:This block is reserved for use in documentation and
remarks:should not be used in any real networks.
remarks:Please see more details at
remarks:http://www.iana.org/go/rfc5737
remarks:-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
source: APNIC
mnt-irt:IRT-APNICRANDNET-AU
changed:hm-chan...@apnic.net 20100617

irt:IRT-APNICRANDNET-AU
address:PO Box 3646
address:South Brisbane, QLD 4101
address:Australia
e-mail: ab...@apnic.net
abuse-mailbox:  ab...@apnic.net
admin-c:AR302-AP
tech-c: AR302-AP
auth:   # Filtered
mnt-by: MAINT-AU-APNIC-GM85-AP
changed:hm-chan...@apnic.net 20110922
source: APNIC

role:   APNIC Hostmaster
address:6 Cordelia Street
address:South Brisbane
address:QLD 4101
country:AU
phone:  +61 7 3858 3100
fax-no: +61 7 3858 3199
e-mail: helpd...@apnic.net
admin-c:AMS11-AP
tech-c: AH256-AP
nic-hdl:HM20-AP
remarks:Administrator for APNIC
notify: hostmas...@apnic.net
mnt-by: MAINT-APNIC-AP
changed:hm-chan...@apnic.net 1998
changed:hm-chan...@apnic.net 20020211
changed:hm-chan...@apnic.net 20070612
changed:hm-chan...@apnic.net 20100217
changed:hm-chan...@apnic.net 20101217
changed:hm-chan...@apnic.net 20110815
changed:hm-chan...@apnic.net 20121024
changed:hm-chan...@apnic.net 20131023
source: APNIC

% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 
(UNDEFINED)

As long as APNIC is a RIR, I don’t see a big issue with that.

-- 
alarig


signature.asc
Description: PGP signature

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> Well, I asked my (3) upstream providers to only send me a ipv6 default
> route and they sent me ::/0...here's one of them... 

Why did you don’t ask for a full view? With that, you can easily deal
with that kind of problem.

-- 
alarig


signature.asc
Description: PGP signature

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On sam. 25 févr. 09:49:56 2017, Aaron wrote:
> Hi, I'm new to the nanog list, hope this isn't out of scope for what is
> usually discussed here.
> 
>  
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
>  
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?
> 
>  
> 
> -Aaron

Hi,

Cogent is not able to receive traffic from Google since February 2016,
the case is the same with HE since 2010.

So, as a quick workaround, you have to connect your network to another
IPv6 transit operator for these destinations.

I you don’t have this possibility, you can set up an IPv6-in-IPv4 tunnel
to HE; the IPv4 traffic flows normally.

-- 
alarig


signature.asc
Description: PGP signature

Re: [outages] ntp.org DNS lookups failing

[Alarig Le Lay]

Hi,

On Wed Jan 18 21:25:23 2017, Gert Doering via Outages wrote:
> Trying to query directly, ns1/ns2.ntp.org return SERVFAIL as well,
> and ns1/ns2.everett.org do not reply at all... so pure guesswork on
> my side says "the original set is broken / under attack / ..., so
> new servers have been added, but as long as the old NS records are
> still being cached, things keep failing".

I see the same behaviour:

alarig@pikachu ~ % dig -t NS ntp.org   

; <<>> DiG 9.11.0-P2 <<>> -t NS ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44422
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ntp.org.   IN  NS

;; Query time: 52 msec
;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1)
;; WHEN: Wed Jan 18 21:28:08 CET 2017
;; MSG SIZE  rcvd: 36

alarig@pikachu ~ % ssh ala...@log.bzh 
alarig@log:~$ sudo unbound-control flush_zone ntp.org
[sudo] password for alarig: 
ok removed 8 rrsets, 0 messages and 0 key entries
^D
alarig@log:~$ déconnexion
Connection to log.bzh closed.
alarig@pikachu ~ % dig -t NS ntp.org 

; <<>> DiG 9.11.0-P2 <<>> -t NS ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53621
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ntp.org.   IN  NS

;; ANSWER SECTION:
ntp.org.3600IN  NS  ns1.everett.org.
ntp.org.3600IN  NS  ns2.everett.org.
ntp.org.3600IN  NS  ns4.p20.dynect.net.
ntp.org.3600IN  NS  dns2.udel.edu.
ntp.org.3600IN  NS  anyns.pch.net.
ntp.org.3600IN  NS  dns1.udel.edu.
ntp.org.3600IN  NS  ns1.p20.dynect.net.
ntp.org.3600IN  NS  ns2.p20.dynect.net.
ntp.org.3600IN  NS  ns3.p20.dynect.net.

;; Query time: 178 msec
;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1)
;; WHEN: Wed Jan 18 21:31:51 CET 2017
;; MSG SIZE  rcvd: 236

-- 
alarig


signature.asc
Description: PGP signature

Re: IPv6 deployment excuses

[Alarig Le Lay]

On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
> > 
> > http://ipv6excuses.com/
> 
> That website only supports IPv4.

It’s on your side.

alarig@pikachu ~ % telnet ipv6excuses.com http
Trying 2403:7000:8000:500::26...
Connected to ipv6excuses.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

-- 
alarig


signature.asc
Description: Digital signature

Re: IPV6 planning

[Alarig Le Lay]

On Mon Mar  7 15:51:06 2016, Owen DeLong wrote:
> To the best of my knowledge, Windows actually generates three
> addresses…
> 
> 1. Subnet Stable quasi-randomized address unrelated (or at least not
> reversable to) MAC address.
> 2. Privacy address which rotates frequently (for some definition of
> frequently).
> 3. Stable address related to MAC address.
> 
> The 3rd one is standard SLAAC.
> The second one is standard privacy extensions.
> THe first one is unique to Windows. You’ll get the same address every
> time you connect to the same subnet, but you won’t see that suffix for
> that host on any other subnet.

It’s not exactly specific to Windows, dhcpcd use a something like that
(my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
there is a RFC related to that, https://tools.ietf.org/html/rfc7217.

-- 
alarig


signature.asc
Description: Digital signature

Re: Level3 DNS not resolving for our domains

[Alarig Le Lay]

On Wed Dec 30 15:48:26 2015, Otto Monnig wrote:
> rocketktg.com <http://rocketktg.com/>

;; ADDITIONAL SECTION:
ns1.rocketktg.com.  244 IN  A   68.235.47.109
ns2.rocketktg.com.  244 IN  A   68.235.47.110

Both are in the same AS, perhaps a routing issue?

-- 
Alarig Le Lay


signature.asc
Description: Digital signature

Re: IPv6 Cogent vs Hurricane Electric

[Alarig Le Lay]

On Tue Dec  1 14:39:14 2015, Andrew Kirch wrote:
> Might I suggest cake pleas?

You mean
http://www.datacenterknowledge.com/wp-content/uploads/2009/10/Hurricane-Cake.jpg
 ?

-- 
Alarig


signature.asc
Description: Digital signature

Re: DNSSEC and ISPs faking DNS responses

[Alarig Le Lay]

On Fri Nov 13 04:27:36 2015, Jean-Francois Mezei wrote:
> I'll have to research how other countries tried to implement similar
> schemes (I believe the UK has with some of the popular torrent sites.
> 
> I know the Australian attempt to filter porn failed miserably.

We also have some torrent sites blocked in France, for exemple:
alarig@HP-Z210:~$ dig +noall +comments +answer t411.me @193.252.19.3
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38309
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
;; ANSWER SECTION:
t411.me.16418   IN  A   127.0.0.1

alarig@HP-Z210:~$ dig +noall +comments +answer t411.me 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41652
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
t411.me.70  IN  A   104.18.37.180
t411.me.70  IN  A   104.18.36.180

But, if you look at the flags, there’s no ad, so no DNSSEC (my resolver
has DNSSEC enabled)

-- 
alarig


signature.asc
Description: Digital signature