Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

[Casey Deccio]

> On Oct 18, 2022, at 4:02 PM, Scott Morizot  wrote:
> 
> I can't say why any RRSIGs or other DNSSEC records are being returned for 
> queries for records in fiscal.treasury.gov , 
> however those records are spurious. As DNSVIZ does show, the delegation from 
> the last secure zone, treasury.gov , to 
> fiscal.treasury.gov  is insecure. And thus the 
> subsequent delegation from fiscal.treasury.gov  
> to igt.fiscal.treasury.gov  is also 
> insecure. Once the chain of trust is properly broken and the status moves to 
> insecure, everything below that point is also insecure.
> 
> DNSVIZ is attempting to make some sense of the spurious DNSSEC records and 
> show what the state would be if there weren't an insecure delegation at 
> treasury.gov . Or at least that's my guess at what it's 
> doing.

I agree with both points.  I just don't know what's going on.  As it turns out, 
writing a piece of software to try to visualize complex configurations is, um, 
complex.  I'll add it to my list.  Just know that I'm a little behind... :)

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

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

[Casey Deccio]

> On Oct 18, 2022, at 1:58 PM, Mark Andrews  wrote:
> 
> Not for DS  as it is part of the parent zone. 
> 

Right.  What I meant (but didn't say) was this:

The following is a query for testing for the presence of a DS record in the 
igt.fiscal.treasury.gov zone.  The signer for the records in the response 
should be the parent zone of igt.fiscal.treasury.gov, which is 
fiscal.treasury.gov.  However, the the signer for the records in the observed 
response is treasury.gov.

$ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == "RRSIG" 
{ print $12 }'
treasury.gov.
treasury.gov.

Casey

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

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

[Casey Deccio]

> On Oct 18, 2022, at 12:02 AM, Viktor Dukhovni  wrote:
> 
> On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:
> 
>> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
>> pretty clearly a problem,
>> 
>> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> 
> DNSViz struggles to display this properly, because the same underlying
> nameservers serve both the parent and child zone, and instead of
> referrals serves authoritative data from the child.  However, the
> parent zone is signed, and the child zone is not.  A resolver
> expecting signed answers from the parent sees unsigned answers
> instead and is liable to get confused.

The one clear issue that I see here is that the signer field in RRSIGs in 
responses from fiscal.treasury.gov is treasury.gov:

$ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == "RRSIG" 
{ print $12 }'
treasury.gov.
treasury.gov.

Because there is a zone cut at fiscal.treasury.gov, the the signer should be 
fiscal.treasury.gov.  That being said, I can't tell at-a-glance why DNSViz is 
drawing ZSK 3908 in the fiscal.treasury.gov zone, rather than in the 
treasury.gov zone.

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

[Casey Deccio]

> On Oct 13, 2021, at 1:07 AM, Stephane Bortzmeyer  wrote:
> 
> On Tue, Oct 12, 2021 at 01:01:08PM -0400,
> Matthew Pounsett  wrote 
> a message of 11 lines which said:
> 
>>> 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.
> 
> DNSviz (and similar tools) may wrongly diagnose a PMTU problem if
> there are random losses.

That's true.

> 1) Try with bufsize=4096. No answer, because of a random packet loss.
> 2) Retry with bufsize=1024. Answer received, therefore it must be a
>   PMTU problem.

Actually, it give it several tries before reducing PMTU.  Here is the full 
order of diagnostic queries when a timeout occurs:

# 1 - no change
# 2 - change timeout to 2 seconds
# 3 - no change
# 4 - reduce udp max payload to 512; change timeout to 1 second
# 5 - change timeout to 2 seconds
# 6 - remove EDNS option (if any); change timeout to 1 second
# 7 - remove EDNS option (if any)
# 8 - remove EDNS option (if any)
# 9 - remove EDNS option (if any)
# 10 - clear DO flag;
# 11 - disable EDNS
# 12 - return (give up)

(See https://github.com/dnsviz/dnsviz/blob/master/dnsviz/query.py#L1766)

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

Re: [dns-operations] validating zones before distribution to secondaries

[Casey Deccio]

> On May 4, 2021, at 7:59 AM, Klaus Darilion  
> wrote:
> 
> In my setup I receive zones from various hidden primaries to my "incoming" 
> nameserver. Before my "distribution" nameserver fetches the zone from the 
> "incoming" nameserver (and hence sends NOTIFYs to the public secondaries) I I 
> want to perform various checks on the zone loaded on the incoming nameserver.
> 
> Currently I use a freaky Bind9 setup with several perl scripts. Do you know 
> if there exists any software tool that were written for such setups? For 
> example a Secondary which fetches a zone not automatically but only on 
> request? Or a nameserver which fetches a zone but only "loads" it if an 
> external tool validates the zone?

With a focus on mostly DNSSEC, but also some general DNS, you can use DNSViz 
for pre-deployment testing, as shown here:

https://github.com/dnsviz/dnsviz#pre-deployment-dns-testing

It is not automated, so you would have to build in scripts around it.

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

Re: [dns-operations] nsec vs nsec3 use

[Casey Deccio]

> On Apr 12, 2021, at 7:51 PM, Viktor Dukhovni  wrote:
> 
> I don't monitor NSEC3 vs. NSEC on a regular basis, but a few weeks back
> I took a survey of at the time ~14.4 million DNSSEC signed domains, of
> which ~10.9 million used NSEC3.

We did a study a few years ago, with a much smaller data set that Viktor's.  
But the numbers were very much in the same ballpark:

NSEC3: 83%
NSEC: 13%

But more specifically:

NSEC3 (traditional): 53%
NSEC3 (white lies): 30%
NSEC (traditional): 11%
NSEC (black lies): 2%

Note that the remaining 4% were unclassified because of inconsistent behavior.

Also:

> On Apr 13, 2021, at 10:40 AM, Viktor Dukhovni  wrote:
> 
>- Most zones have no secrets, often just the zone apex and a couple
>  of common labels, "www", "smtp", "mx1", ...


Again, we have some empirical measurements to confirm this.  Nearly 90% of 
zones signed with NSEC3 have fewer than 10 names.

The full paper is here:
https://casey.byu.edu/papers/2019_pam_dnssec_lies.pdf

And an OARC presentation on the topic here:
https://indico.dns-oarc.net/event/32/contributions/725/attachments/699/1151/2019-11-01-dnssec-lies-oarc.pdf

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

Re: [dns-operations] Looking for someone in charge for gtm-ext.dla.mil, DNSSEC validates as Bogus

[Casey Deccio]

> On Mar 11, 2021, at 4:54 PM, Simon Arlott via dns-operations 
>  wrote:
> 
> On 11/03/2021 23:36, Casey Deccio wrote:
>> Oh, I see now.  The actual delegation is missing completely, as far as I can 
>> tell.
>> 
>> $ dig +short @ns1.dla.mil gtm-ext.dla.mil a
>> $ dig +short @ns1.dla.mil gtm-ext.dla.mil 
>> $ dig +short @ns1.dla.mil gtm-ext.dla.mil ns
> 
> The TTLs go down when querying ns1 and ns4, so it's proxying for
> something else.
> 
> There are NS records, but you can only get them if you query for ANY,
> and only some of the time depending on which load balancer you hit:

And depending on the phase of the moon and the alignment of the stars, 
apparently. :)

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

Re: [dns-operations] Looking for someone in charge for gtm-ext.dla.mil, DNSSEC validates as Bogus

[Casey Deccio]

Hi Peter!

> On Mar 11, 2021, at 11:54 AM, Peter van Dijk  
> wrote:
> 
>> 
>> That's a fair point.  *Normally* the error would be something more like: "No 
>> RRSIGs were found covering the RRset".  But in this case, there *was* an 
>> RRSIG, so it didn't get *that* error.  DNSViz used to complain when an RRSIG 
>> didn't align to a DNSKEY, but that was changed because sometimes there were 
>> legitimate reasons for that (like pre-publishing RRSIGs as part of an 
>> algorithm rollover).  So all we were left with was an error about the RRSIG 
>> itself (i.e., name didn't match).
> 
> Thank you for explaining that history. I certainly appreciate how your
> errors have to guess at the real world things that are happening.

Yes, guessing is hard :). And actually the command-line version does a little 
better in this particular case than the Web/database version because there are 
some challenges with keeping track of a DNSKEY/DS for a non-zone (see below) in 
the way that the software is currently implemented.

>>  Probably the "no RRSIG" error should be modified to be "no RRSIG for an 
>> existing DNSKEY".
> 
> But, in this case, the DNSKEY does exist, and a DS is pointing at it
> correctly, and the problems are almost unrelated to those, as far as I
> can see. My impression is that DNSViz is confused for the same reason a
> default PowerDNS Recursor gets confused on this name - conflicting
> facts from queries *other than* those DS and DNSKEY queries.

Oh, I see now.  The actual delegation is missing completely, as far as I can 
tell.

$ dig +short @ns1.dla.mil gtm-ext.dla.mil a
$ dig +short @ns1.dla.mil gtm-ext.dla.mil 
$ dig +short @ns1.dla.mil gtm-ext.dla.mil ns

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

Re: [dns-operations] Looking for someone in charge for gtm-ext.dla.mil, DNSSEC validates as Bogus

[Casey Deccio]

> On Mar 11, 2021, at 2:59 AM, Peter van Dijk  
> wrote:
> 
> On Thu, 2021-03-11 at 10:33 +0100, Peter van Dijk wrote:
>> 
>> That actually looks fine to me - DS is signed by parent (dla.mil),
>> DNSKEY is signed by child (gtm-ext.dla.mil).
> 
> This means that the error reported by DNSViz:
> 
> RRSIG quicksearch.gtm-ext.dla.mil/A alg 8, id 29085: The Signer's Name field 
> of the RRSIG RR (gtm-ext.dla.mil) does not match the name of the zone 
> containing the RRset (dla.mil).
> 
> does not seem like the right conclusion to me.
> 
> (To be clear, the name does not deserve to resolve because of all the 
> problems, but DNSViz is not correctly pointing to the pain I think.)

That's a fair point.  *Normally* the error would be something more like: "No 
RRSIGs were found covering the RRset".  But in this case, there *was* an RRSIG, 
so it didn't get *that* error.  DNSViz used to complain when an RRSIG didn't 
align to a DNSKEY, but that was changed because sometimes there were legitimate 
reasons for that (like pre-publishing RRSIGs as part of an algorithm rollover). 
 So all we were left with was an error about the RRSIG itself (i.e., name 
didn't match).  Probably the "no RRSIG" error should be modified to be "no 
RRSIG for an existing DNSKEY".

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

Re: [dns-operations] anybody awake over at comcast.net?

[Casey Deccio]

> On Feb 9, 2021, at 12:33 AM, Viktor Dukhovni  wrote:
> 
> checks that every signature in every signed zone
> is at least 3.14 days away from expiration

3.14 sounds a little too irrational to me... :)

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

Re: [dns-operations] Edge-case, zero-length DNSKEYs

[Casey Deccio]

> On Oct 6, 2020, at 11:33 AM, Viktor Dukhovni  wrote:
> 
> these give DNSViz some indigestion:
> 
>https://dnsviz.net/d/nlagriculture.nl/X3yhPg/dnssec/ 
> 
>https://dnsviz.net/d/nlenergyandclimatechange.nl/X3yhXg/dnssec/ 
> 
> 
> the graphs fail to display.

I've just given it some Pepto.  It seems to have recovered.

Sounds like a riddle.  When is a key not a key?  When it has no key material.

Casey___
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

[Casey Deccio]

> On Mar 11, 2020, at 2:03 PM, Warren Kumari  wrote:
> 
> On Wed, Mar 11, 2020 at 3:44 PM Matthew Pounsett  wrote:
>> 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.
> 
> 
> Excuse my not remembering, but have y'all confirmed that this is
> really worth the faff? What *I* care about is being able to use the
> service *from now on*- going back and seeing the breakage of
> foo.example.net in 2018 is only mildly interesting, but certainly not
> (to me!) worth your time and effort...

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?", though it is 
arguably less important to most users, and the value diminishes over time.  
Much more important, in my opinion, is understanding trends over time.  For 
example, can we understand what the current pitfalls are and how to improve 
them, so we can get off NTAs and be more strict in DNSSEC validation adherence? 
 In other words, looking at the aggregate offered by the historical data is 
much more valuable than looking at individual setups.  An understanding of 
DNS(SEC) deployment behavior can be used to improve tools, processes, and 
standards.

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

Re: [dns-operations] DNSViz Status?

[Casey Deccio]

> On Feb 17, 2020, at 1:37 AM, Marco Davids (Private) via dns-operations 
>  wrote:
> 
> From: "Marco Davids (Private)" 
> Subject: Re: [dns-operations] DNSViz Status?
> Date: February 17, 2020 at 1:37:17 AM MST
> To: dns-operations@lists.dns-oarc.net
> 
> 
> 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!

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

Re: [dns-operations] DNSSEC issue - why?

[Casey Deccio]

On Tue, Jun 9, 2015 at 2:47 AM, Gilles Massen gilles.mas...@restena.lu
wrote:

 In short: bind and unbound fail to validate, Google, dnsviz (
 http://dnsviz.net/d/hollington.ca/dnssec/ ) or dnssec-debugger (
 http://dnssec-analyzer.verisignlabs.com/hollington.ca ) are fine.


FYI, DNSViz has been updated to reflect RFC 4509 more accurately, so it can
better identify the cause of related issues in the future.

Casey
___
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 issue - why?

[Casey Deccio]

On Tue, Jun 9, 2015 at 5:55 AM, Edward Lewis edward.le...@icann.org wrote:

 On 6/9/15, 3:12, Kevin Chen kc...@mit.edu wrote:

 
 which looks quite simple, however the KSK DNSKEY from hollington.ca is
  part of the DS set. The only notable part of the DS set is that it
  contains 4 keys, among which is an older (?) with a longer hash.
 
 RFC 4509 says:
 
 Implementations MUST support the use of the SHA-256 algorithm in DS
 RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
 digests if DS RRs with SHA-256 digests are present in the DS RRset.
 
 I assume the various resolvers are making different choices with regard
 to SHOULD.

 Hmmm, I would have never interpreted that requirement that way.  I always
 had in mind per key.


The example in the RFC seems to present it that way as well.  That might be
part of the problem (I had interpreted it--and implemented it--that way).

   o  A zone includes multiple DS records for a given child's DNSKEY,
  each of which uses a different digest type.

   o  A validator accepts a weaker digest even if a stronger one is
  present but invalid.

But when you consider a downgrade attack, the attacker only needs the
lowest hanging fruit.  That means that *any* DS (regardless of DNSKEY) with
the weaker digest type could potentially be used for falsifying a DNSKEY.

Casey
___
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] Authoritative name server replies NODATA for a non-existing domain

[Casey Deccio]

On Wed, Apr 22, 2015 at 9:12 AM, Stephane Bortzmeyer bortzme...@nic.fr
wrote:

 Strange behavior:

 % for ns in $(dig +nodnssec +short NS adult.); do
 echo $ns
 dig @$ns NS thisdomaincertainlydoesnotexist.adult | grep status:
 done
 d0.nic.adult.
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 13433
 c0.nic.adult.
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 23111
 a0.nic.adult.
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 3358
 a2.nic.adult.
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48334
 b2.nic.adult.
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29932
 b0.nic.adult.
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 58405

 IMHO, all the name servers should reply NXDOMAIN, no?

 DNSviz does complain:


 http://dnsviz.net/d/adult/dnssec/?rr=alla=allds=alldoe=onta=.ta=dlv.isc.org.tk=


FWIW, DNSViz was complaining, but due to a bug (in DNSViz) it wasn't clear
what it was complaining about.  In this case the was that it was a NODATA
response but there was no NSEC3 record matching the QNAME in the response.
It has now been fixed.

http://dnsviz.net/d/adult/VTe7yw/dnssec/?rr=alla=allds=alldoe=onta=.ta=dlv.isc.org.tk=

The proof in the response indicated NXDOMAIN, but the response code didn't
match.

Cheers,
Casey
___
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] gov.mu inconsistency

[Casey Deccio]

On Thu, Nov 6, 2014 at 3:55 PM, S Moonesamy sm...@elandsys.com wrote:

 I have been trying to debug an issue affection domains in the gov.mu
 zone.  On 4 November, I would only get an A RR for www1.gov.mu if the DNS
 query when through udns2.tld.mu and fork.sth.dnsnode.net:


There are clearly two versions of the zone being served by gov.mu servers.
If the value of the serials is any indicator of date (as it appears), then
udns1.tld.mu and anycast1.irondns.net are serving a version of the zone
that is about ten months newer than that being served by ns{1,2,3}.gov.mu
(2014110646 vs. 2014010572).

$ dig +short @ns1.gov.mu gov.mu soa
ns1.gov.mu. hostmaster.mail.gov.mu. 2014010572 43200 3600 86400 180
$ dig +short @udns1.tld.mu gov.mu soa
ns1.gov.mu. gov.mu. 2014110646 10800 3600 43200 300

Note that udns1.tld.mu and anycast1.irondns.net are *not* in the NS RRset
for gov.mu (i.e., aren't explicitly designated as authoritative), but they
*are* authoritative for mu, and do also (stealthily) answer authoritatively
for gov.mu, which means that your resolver will accept their answer when it
queries mu for something in gov.mu (although it will learn the designated
NS names in the authority section of the response).

Cheers,
Casey
___
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 Validation Errors with Wildcards

[Casey Deccio]

On Thu, Oct 16, 2014 at 4:35 AM, Bernhard Schmidt be...@birkenwald.de
wrote:

 we have recently enabled outbound TLSA/DANE on our Postfix MTAs and have
 come across a number of validation errors. These have the following in
 common:

 - The zone where the mailserver (right side of the MX record of the
 target domain) resides in is signed
 - there is a wildcard record on the zone level
 - lookup of mailserver A/ works fine and is authenticated
 - lookup of _25._tcp.mailserver TLSA leads to SERVFAIL on our resolver
 (BIND 9.9.5), Google DNS and both DNS-OARC resolvers

 Examples:

 _25._tcp.vdlc.nl
 _25._tcp.mail.plexx.eu
 _25._tcp.relay01.tt-mb.nl
 _25._tcp.mail.cdv.cz

 Sometimes DNSVIZ shows errors in the NSEC chaining (i.e. on the tt-mb.nl
 zone), but for example the mail.cdv.cz one looks fine. Yet I cannot
 validate the response.


DNSViz was incorrectly showing the NSEC covering as valid for some of the
above wildcards.  It was checking that expanded wildcard name did not
exist, but was not checking that the wildcard expansion was valid.  It has
been corrected, e.g.,:

http://dnsviz.net/d/_25._tcp.vdlc.nl/VEAZDw/dnssec/
http://dnsviz.net/d/_25._tcp.mail.cdv.cz/VEAZdw/dnssec/

Cheers,
Casey
___
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] Google DNS used as amplification - aren't they caching?

[Casey Deccio]

On Wed, Aug 6, 2014 at 11:10 AM, Paul Wouters p...@nohats.ca wrote:


 Hi,

 My nohats.ca domain has been under a couple of weeks long ANY attack. I
 assume spoofed IPs querying open resolvers that in have their upstream
 DNS send me queries.

 The vast majority of queries are coming from Google's many IP addresses.
 While I understand it must be an impressive ANYCAST network, I am still
 surprised to see millions of queries coming for data that has a TTL=1d
 It is as if Google is hardly caching anything.

 The top 30 queries in the last two weeks, based on logging at most 1q/s:

 It seems that the nsd ratelimits to send TC=1 isn't working well either
 to reduce the incoming amount of UDP queries.

 Why does google dns seems so inefficient at caching?


Google's implementation seems to recursively query for and cache ANY based
on the entire set of records for the same name, rather than on a per-record
basis.  nohats.ca includes an NSEC3PARAM record with TTL 0.  This results
in zero caching of ANY queries.

For example, contrast the following (looking at the TTLs in the answer):

casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov soa | grep SOA | awk '{ print
$1,$2,$3,$4 }'
;sandia.gov. IN SOA
sandia.gov. 20502 IN SOA
sandia.gov. 20502 IN RRSIG
casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov soa | grep SOA | awk '{ print
$1,$2,$3,$4 }'
;sandia.gov. IN SOA
sandia.gov. 20497 IN SOA
sandia.gov. 20497 IN RRSIG

with this:

casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
sandia.gov. 21599 IN SOA
sandia.gov. 21599 IN RRSIG
sandia.gov. 0 IN RRSIG
sandia.gov. 0 IN NSEC3PARAM
casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
sandia.gov. 21599 IN SOA
sandia.gov. 21599 IN RRSIG
sandia.gov. 0 IN RRSIG
sandia.gov. 0 IN NSEC3PARAM

This is a bad side effect of (at least) BIND's NSEC3 signing which doesn't
(or at least didn't last time I checked) allow a custom, longer TTL for
NSEC3PARAM.  But it's the combination of Google's ANY query/cache behaviaor
and the zero-TTL NSEC3PARAM that cause the problem.

Cheers,
Casey
___
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] Google DNS used as amplification - aren't they caching?

[Casey Deccio]

On Wed, Aug 6, 2014 at 11:33 AM, Casey Deccio ca...@deccio.net wrote:

 Google's implementation seems to recursively query for and cache ANY based
 on the entire set of records for the same name, rather than on a per-record
 basis.  nohats.ca includes an NSEC3PARAM record with TTL 0.  This results
 in zero caching of ANY queries.

 For example, contrast the following (looking at the TTLs in the answer):

 casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov soa | grep SOA | awk '{
 print $1,$2,$3,$4 }'
 ;sandia.gov. IN SOA
 sandia.gov. 20502 IN SOA
 sandia.gov. 20502 IN RRSIG
 casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov soa | grep SOA | awk '{
 print $1,$2,$3,$4 }'
 ;sandia.gov. IN SOA
 sandia.gov. 20497 IN SOA
 sandia.gov. 20497 IN RRSIG

 with this:

 casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov any | grep
 NSEC3PARAM\\\|SOA | awk '{ print $1,$2,$3,$4 }'
 sandia.gov. 21599 IN SOA
 sandia.gov. 21599 IN RRSIG
 sandia.gov. 0 IN RRSIG
 sandia.gov. 0 IN NSEC3PARAM
 casey@rome:~$ dig +dnssec @8.8.8.8 sandia.gov any | grep
 NSEC3PARAM\\\|SOA | awk '{ print $1,$2,$3,$4 }'
 sandia.gov. 21599 IN SOA
 sandia.gov. 21599 IN RRSIG
 sandia.gov. 0 IN RRSIG
 sandia.gov. 0 IN NSEC3PARAM


I neglected to provide examples from other resolver implementations.
Here's BIND:

casey@rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 0 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 3600 IN RRSIG
nohats.ca. 3600 IN SOA
casey@rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3598 IN RRSIG
nohats.ca. 3598 IN SOA
casey@rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3597 IN RRSIG
nohats.ca. 3597 IN SOA

Note that the cache started empty, and because it was empty it was
populated with all records having name nohats.ca after the first ANY
query.  BIND responded to subsequent query with whatever was still in
cache.  The zero-TTL items had already expired, and BIND did not re-fetch
them.

unbound has yet a third behavior.  It seems to cache on a per-ANY basis but
maintain TTL on a per-record basis:

casey@rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3600 IN SOA
nohats.ca. 3600 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 0 IN RRSIG
casey@rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3598 IN SOA
nohats.ca. 3598 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 0 IN RRSIG
casey@rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3596 IN SOA
nohats.ca. 3596 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 0 IN RRSIG

It's inconclusive from this quick test whether the existing records are
being updated or not from the results of the ANY query (it appears that
they are not, but I would need to check content), but at least the TTLs are
not affected.

Regards,
Casey
___
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] dnsviz having issues?

[Casey Deccio]

On Tue, Jul 29, 2014 at 4:49 PM, Doug Barton do...@dougbarton.us wrote:

 not loading up for me, and http://www.downforeveryoneorjustme.com/
 dnsviz.net seems to agree.


Erg - thanks for the heads up.  It should be back up now.

FYI, the DNSViz service (and the underlying analysis and visualization
engine) has been undergoing a huge rework, and the service will soon be
migrated to a new, more stable platform (the old system is hanging on by a
thread...).  More to come later.

Casey
___
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] www.factorymoneystore.gov DNSSec Failures

[Casey Deccio]

On Sat, Jul 26, 2014 at 2:30 PM, Ryan Rawdon r...@u13.net wrote:

 http://dnssec-debugger.verisignlabs.com/www.moneyfactorystore.gov

 RRSIG=51869 and DNSKEY=51869 does not verify the A RRset (RSA
 Verification failed)
 RRSIG=54410 and DNSKEY=54410 does not verify the A RRset (RSA
 Verification failed)
 None of the 2 RRSIG and 4 DNSKEY records validate the A RRset
 The A RRset was not signed by any keys in the chain-of-trust

 Validation for moneyfactorystore.gov succeeds, however
 www.moneyfactorystore.gov fails.  Came across this when a user pointed
 out that it was not resolving.


Hmm, DNSViz doesn't see any problems [1], and the DNS-OARC resolvers give
an authenticated response [2].  I'm not sure about the reported RSA
verification failures, but it could be that your resolver is (incorrectly)
expecting a closest encloser NSEC3 record, which isn't necessary for
wildcard responses, but which some older versions of BIND required it [3].
What resolver are you running?

Cheers,
Casey

[1] http://dnsviz.net/d/www.moneyfactorystore.gov/U9P4fQ/dnssec/
[2] https://www.dns-oarc.net/oarc/services/odvr
[3] See the following thread:
http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html
___
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] dig 9.8.5-P1 not seeing 'aa' flag set from authoritative nameservers?

[Casey Deccio]

On Fri, Jul 25, 2014 at 1:32 AM, Mark E. Jeftovic mar...@easydns.com
wrote:

 Note that there is no 'aa' flag set. I've been checking everybody's
 nameservers, they are all not doing it.


Do you mean name servers authoritative for other DNS zones have/had the
same issue (no AA bit) from the perspective of your client?

Is/was your affected client behind a transparent DNS proxy perhaps?

It wasn't clear from your post since you didn't include the actual answers,
but were the answers and TTLs what you would expect from the authoritative
server?

But all my other dig's on other boxes are working fine


Were the other clients you tested from on the same subnet?

Casey
___
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] dig 9.8.5-P1 not seeing 'aa' flag set from authoritative nameservers?

[Casey Deccio]

On Fri, Jul 25, 2014 at 8:22 AM, Mark E. Jeftovic mar...@easydns.com
wrote:

 As I was drifting off to sleep I realized that had to be it. I'm on
 vaction at the moment and I noticed this as I was connected on the
 hotel's WIFI.


I suppose no one can sleep well with DNS interceptors on the loose...
(except those running validating resolvers and resolving signed zones, of
course :) ).

Casey
___
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] 172.in-addr.arpa DNSSEC broken

[Casey Deccio]

On Tue, May 20, 2014 at 4:22 PM, Stephane Bortzmeyer bortzme...@nic.frwrote:

 The problem is indeed in
 172.in-addr.arpa (botched rollover, it seems, old KSK 30729 removed
 from the zone while the DS was - is - still in many caches).


Not only in caches, but while it was still being served from the
in-addr.arpa parent zone.

http://dnsviz.net/d/172.in-addr.arpa/U3tPeg/dnssec/

Casey
___
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] Fun with DNAME and DNSSEC

[Casey Deccio]

On Tue, Jan 28, 2014 at 5:26 PM, Wessels, Duane dwess...@verisign.comwrote:


 On Jan 28, 2014, at 7:51 AM, Tony Finch d...@dotat.at wrote:

  The Verisign Labs DNSSEC debugger does quite well, though it does not
  understand that CNAME records synthesized from DNAME records do not have
  RRSIG records.


 You should find that the Debugger now properly recognizes the DNAME record.
 It previously only used the DNAME record when the owner name was equal to
 the zone name.


DNSViz should now work too--no longer discombobulated :), but still slow
(needs a performance facelift).  It was actually handling DNAME properly;
it just wasn't querying for PTR outside of arpa, so it wasn't following the
synthesized CNAME.

http://dnsviz.net/d/252.252.232.128.in-addr.arpa/UuiYkg/dnssec/

Note that there are two bubbles for CNAME because one server provided a
different TTL (0) than the others (86400), the former following RFC 2672,
and the latter following updated TTL guidelines in RFC 6672.  Curiously,
for the server returning the 0 TTL, the corresponding IPv6 address (i.e.,
by the same name) returns the 86400 TTL.

Casey
___
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] Fun with DNAME and DNSSEC

[Casey Deccio]

On Wed, Jan 29, 2014 at 10:15 AM, Tony Finch d...@dotat.at wrote:

 Well, mostly. It's complaining about being unable to get the
 in-addr.arpa.cam.ac.uk DNSKEY RRset from 129.169.8.8, which I thought my
 colleagues fixed yesterday - it works when I try the query from a couple
 of off-campus locations.


The analysis link I posted was a snapshot from hours ago.  The newest
DNSViz analysis doesn't show any issues, and I confirmed that from command
line.

This is ns.ripe.net which appears to be load-balancing across multiple
 name server implementations, on IPv4 and IPv6 - that is, the difference
 you saw was due to the load balancing not the different IP version. I can
 see three distinct behaviours when I repeat the following queries:


I wondered if that might be the case, but I hadn't dug in as far as you
did :)

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

[Casey Deccio]

On Tue, Jan 21, 2014 at 10:55 AM, Matthew Pounsett m...@conundrum.comwrote:

 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.


In this case of DS query, you won't receive an answer (i.e., record(s) in
the answer section) because no DS records exist.  If there is no
delegation to the child zone in the parent, then the parent will either
answer NXDOMAIN or NOERROR with NSEC(3) records having no NS bit set.
Either case is problematic, but I believe the outcome depends on the
existence of sibling glue in the parent zone.

Casey
___
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] Resolution of sandia.gov from Verizon

[Casey Deccio]

On Tue, Oct 29, 2013 at 1:08 PM, Mark Andrews ma...@isc.org wrote:

 I would be getting on the phone as REFUSED is not a response that
 is cached then returned in the down stream responses.  Normally
 upstream REFUSED become down stream SERVFAIL.  The usual way to get
 this is to configure a zone then set the acl to prevent respones.


This is exactly why this is so bizarre to me.  Additionally dnsviz.net has
NS records with server names in sandia.gov, yet dnsviz.net does not have
issues, so it doesn't appear to be a resolution issue, but rather a
resolver issue.

Anyway, we do have a call in to Verizon, but the callback time is 24-48
hrs.  I thought I'd try the list to see if we could find someone that knows
what they're talking about a bit sooner.

Cheers,
Casey
___
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] Resolution of sandia.gov from Verizon

[Casey Deccio]

On Tue, Oct 29, 2013 at 12:42 PM, Casey Deccio ca...@deccio.net wrote:

 I seem to be having trouble resolving names in sandia.gov from Verizon
 Wireless resolvers (well, one at least), which are giving me REFUSED
 responses.  Other names, in .gov and otherwise, resolve just fine.  Anyone
 know anything?


Apparently verizon's resolvers are being hit with a high number of queries
for sandia.gov (ANY?), for which they've begun refusing queries for
sandia.gov altogether.  These resolvers aren't generally open (as far as
I can tell), which means that if these are being used for
amplification/reflection (the latter they have not fixed by sending REFUSED
messages), the target (source) is verizon's own.

In the mean time, Sandia is inaccessible to legitimate verizon customers.

Casey
___
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] .US problems?

[Casey Deccio]

On Thu, Aug 15, 2013 at 12:42 PM,  wbr...@e1b.org wrote:
 Is anyone else seeing problems resolving .us addresses?


Hmm, availability doesn't look good from my vantage point:

http://dnsviz.net/d/us/Ug0wfw/servers/
http://dnsviz.net/d/us/Ug0wfw/responses/

All servers except one (b's IPv6 interface) appear to be sending
REFUSED messages.

Casey
___
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] Way to test remote EDNS capability?

[Casey Deccio]

On Fri, Jun 7, 2013 at 12:33 AM, Doug Barton do...@dougbarton.us wrote:
 I'm looking at some resolver logs and seeing the success resolving $blah
 after reducing the advertised EDNS UDP packet size to 512 octets messages
 for some authoritative servers run by organizations that I would think ought
 to know better. :)  I've tested the path on my side using
 https://www.dns-oarc.net/oarc/services/replysizetest and both my IPv4 and
 IPv6 paths show as clear (which I would expect of course).

 Is there any simple way test the remote side's actual capabilities?


Issues with payload size or fragmentation could occur anywhere in the
path between your resolver and the server, so it's a game of
intersecting components of paths where lower payloads fail and
subtracting out the components of paths that succeed to help zero in
on the problem area.  More often than not the issue is closer to one
of the ends.  If replysizetest succeeds, then it's probably closer to
them.

You can also narrow down the PMTU.  First determine what the message
size would (likely) be by querying with TCP.  Now issue a UDP query
with bufsize 1 byte less than the message size to see if you get a
response.  If you get a (perhaps truncated) response, the PMTU is
somewhere between the size of the message you received last and the
size of the full response you received over TCP.  If no response,
split the difference between that and 512 and try again.

DNSViz does something like this as part of its online analysis.  Other
tools might do something similar.

 Meanwhile I've been trying 'dig +bufsize=4096' and it seems to succeed more
 often than it fails. In one particular zone 4 of the 5 auth name server
 addresses succeeded, but the one that failed failed with both +bufsize=4096
 and +bufsize=512. Is it possible that named (BIND 9.9.3-p1) just happened to
 hit the failing server first, then it happened to work when it backed the
 packet size off and tried another server?


I would think that reducing the EDNS maximum UDP payload size is done
on a per-server basis, not on a per-zone basis, but that's pure
speculation.

Casey
___
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] Recently closed open resolver and reflection attacks

[Casey Deccio]

On Wed, Mar 6, 2013 at 8:36 AM, wbr...@e1b.org wrote:

 I recently help close down an open recursive resolver.  It is still
 getting a lot of queries for isc.org/ANY which get a refused response
 (unless slipped/dropped by RRL).  Granted, this doesn't amplify the attack
 since REFUSED is a fairly small packet, but it is still traffic to the
 attacked site.


Seems like a REFUSED response fits into its own RRL category.  Is there any
reason why name servers wouldn't simply drop them if they exceed the
configured RRL threshold--or even perhaps a lower threshold?

Casey
___
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] Recently closed open resolver and reflection attacks

[Casey Deccio]

On Wed, Mar 6, 2013 at 10:12 AM, Vernon Schryver v...@rhyolite.com wrote:

  From: Casey Deccio ca...@deccio.net


  Seems like a REFUSED response fits into its own RRL category.  Is there
 any
  reason why name servers wouldn't simply drop them if they exceed the
  configured RRL threshold--or even perhaps a lower threshold?

 The current version of the BIND9 RRL implementation has the
 errors-per-second parameter.


Thanks - I had forgotten about this parameter.


 For documentation, follow the link labeled
 Draft text for BIND9 Administrators Reference Manual (ARM) describing
 on http://www.redbarn.org/dns/ratelimits
 The paragraph in that text describing slip concludes with:

  A value of 0 does not slip or sends no rate limiting truncated
  responses. Some error responses includinge REFUSED and SERVFAIL
  cannot be replaced with truncated responses and are instead
  leaked at the slip rate.


Is there any benefit to a non-zero slip value for these responses?
Certainly they're not amplifying, but I understand the purpose of non-zero
slip is to give legitimate clients some chance of response amid the large
quantity of queries from spoofed clients.  REFUSED messages seem more like
a courtesy in the interest of timely failure than anything else.  It seems
unlikely that legitimate clients would be much affected by lack of response
for REFUSED queries in the interest of eliminating noise.

Casey
___
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] responding to spoofed ANY queries

[Casey Deccio]

On Thu, Jan 10, 2013 at 2:24 PM, Vernon Schryver v...@rhyolite.com wrote:

  thumb for reasonable response rate given query rates, but it seems like
 50%
  is in fact a good starting place.



 With slip=2 and the victim trying and retrying a total 3 times, the
 probability that all of the victims responses will be dropped is
 0.5*0.5*0.5 = 0.125.  That makes the probability that the victim
 will get a response despite matching the DoS flood about 88%.  That's
 not perfect, but not bad.


Thanks for correcting my math.  I was thinking that the probability that
the victim got a response was dependent on query rate, but of course that
would only be the case if response rate was a function of responses per
time interval, not responses per number of queries.  It's simply a function
of response rate and retry, i.e., p = 1 - (1 - (1/slip))^retries -- a much
better success rate than the alternative in the midst of a flood of forged
queries.

Casey
___
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] Validation problems for nal.usda.gov

[Casey Deccio]

On Thu, Nov 15, 2012 at 6:12 PM, Mark Andrews ma...@isc.org wrote:


 In message 50a53ad6.70...@ack.berkeley.edu, Rune Stromsness writes:
 
  We've been seeing DNSSEC validation problems (using the ISC DLV trust
  anchor) for nal.usda.gov for about 3 weeks now.  We've been unable to
  get in touch with anyone at the NAL who knows anything about DNSSEC, and
  we're not happy about turning off use of the DLV for our campus.  Our
  customers are getting more unhappy with their inability to use the
  nal.usda.gov resources from campus, however.
 
  Does anyone know of a USDA or .gov contact who knows what DNSSEC is who
  might be able to help get the NAL to fix or mitigate their issues?
 
 
  Rune
  --=20
  Rune Stromsness
  Network Operations  Services
  Telecommunications
  University of California, Berkeley
  ru...@berkeley.edu

 They have a large DNSKEY RRset (;; MSG SIZE  rcvd: 2731) so you may
 be seeing issues with fragmentation.  The DLV records match the
 DNSKEY records.


For nearly two weeks they were operating with expired RRSIGs, but
apparently they fixed that as of at least 7 hours ago:

http://dnsviz.net/d/nal.usda.gov/UKT0sg/dnssec/
http://dnsviz.net/d/nal.usda.gov/UKVeIg/dnssec/

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