Re: [dns-operations] Evaluation of NSEC3-encloser attack

[Matthew Richardson via dns-operations]

--- Begin Message ---
Viktor Dukhovni wrote:-

>I do hope that, as a community, we'll continue to steadily streamline
>acceptable NSEC3 parameters (per RFC9276) down to 0 additional
>iterations and short enough salt values (that don't result in additional
>SHA-1 input blocks).

What would be the largest salt length to ensure that such additional input
blocks are not required?

--
Best wishes,
Matthew
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] differ

[Matthew Richardson via dns-operations]

--- Begin Message ---
Randy Bush  wrote:-

>it occurred to me that it migh tme wise to have a rancid like
>(https://shrubbery.net/rancid/) equivalent for critical domains.
>i.e. to git record changes and warn of radical diffs.
>
>is there any foss tooling in this space?

For the recording, I do something similar within our systems which is
really simple, and roughly:-

cd $repodir
foreach $zone {
  dig +nocmd +nostats +onesoa @$master $zone axfr > $zone.zone
}
git add -A
git commit -m "cron script"

which runs as a daily job via cron.  Obviously, this only does the
recording into a git repo, but does not do any alerting.

--
Best wishes,
Matthew
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] anchors.atlas.ripe.net/ripe.net - DNSSEC bogus due expiration

[Matthew Richardson via dns-operations]

--- Begin Message ---
Our systems use some RIPE Atlas anchors for general connectivity
monitoring.  Just now, they all failed.

If looks as if DNSSEC has expired:-

https://dnsviz.net/d/anchors.atlas.ripe.net/dnssec/

It also looks as if other things in ripe.net may also have expired (eg
www.ripe.net when looking for a contact to advise of this).

--
Best wishes,
Matthew
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] New addresses for b.root-servers.net

[Matthew Richardson via dns-operations]

--- Begin Message ---
Dave Knight wrote:-

>> all you can validate is the NS set. The host records cannot be validated 
>> because root-servers.net is not signed.
>
>Good point!
>
>They're still used to replace what was provided in the root.hints after the 
>priming response is received though.

Without wishing to ask a really stupid question, is there any reason why
root-servers.net is not DNSSEC signed?

Would signing it provide additional any additional security?

--
Best wishes,
Matthew
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] mail.protection.outlook.com has EDNS issues

[Matthew Richardson]

Aside from today's outage, the DNS for mail.protetion.office.com seems to
have been very poor for a long time.  As an example from 2020, Brian Somers
lamented its state:-

https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020124.html

The scale of the general problem (after this fault has been fixed) can be
seen at:-

https://www.zonemaster.fr/result/e46bf2d6d1d70989

As MS is a Silver member of DNS-OARC, are there any MS folks on here who
might be involved with the authoratitive side of
mail.protection.office.com, or who might be able to get the issue raised
internally at MS?

Alternatively, is this the sort of issue in which DNS-OARC could become
involved by way of outreach to MS about the problems?  The lack of EDNS0
will probably become an increasing problem over time.  This DNS setup is
used for ALL email to Office365 business users, which is not a small
quantity.

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

Re: [dns-operations] subzone creation policy & maintenance

[Matthew Richardson]

Sue Steffen:-
>We have created numerous subzones and delegated them to AWS private hosted
>zones for our ‘move to the cloud’ efforts.  This has resulted in a sprawl
>of subzones.  Does anyone else have thoughts on how to manage the number of
>zones?  How do you maintain currency on them – like identifying ones that
>are abandoned and should be removed?

Our systems have monitoring on all zones, which basically checks that all
the delegated DNS servers give authoratitive responses and that the SOA
serial number is in sync.

Where a zone is delegated, this would also be added to this monitoring,
which catches the situation where the delegation has gone lame.

Depending on the size of the zone/organisation, some record keeping as to
who is responsible for each delegated zone might be prudent.

For registered domains, there are also monitoring checks to ensure that the
delegation does not get changed, which also catches expiries.

Hope this helps.

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

Re: [dns-operations] console.aws.amazon.com - breakage & confusing output from DNSViz?

[Matthew Richardson]

Vladimír ?unát wrote:-
>Are you sure that you used the latest version?  (5.4.4, a month old)
>Bug details: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1237

Thanks.  Embarrassingly I was running 5.4.2, and an upgrade to 5.4.4 has
(obviously!) fixed the issue in Knot Resolver.

Out of interest, updating the lab (which tries to use "out of the box"
configs, but with DNSSEC validation, of standard packages), also upgraded:-

Bind 9.11.26-4.el8_4 to 9.11.26-6.el8
Unbound 1.7.3-15.el8 to 1.7.3-17.el8

after which Unbound could resolve it, but Bind continued to return
SERVFAIL.


Viktor Dukhovni wrote:-
>The more likely source of trouble can be seen by clickin on the "Errors"
>button:
>
>aws.amazon.com zone: The server(s) did not respond authoritatively for the 
> namespace. (34.196.62.143, 52.9.140.222, 52.9.146.37, 52.16.221.207, 
> 52.19.138.45, 52.86.96.73)
>aws.amazon.com/CNAME: The Authoritative Answer (AA) flag was not set in 
> the response. (34.196.62.143, 52.9.140.222, 52.9.146.37, 52.16.221.207, 
> 52.19.138.45, 52.86.96.73, UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
>console.aws.amazon.com zone: The server(s) did not respond authoritatively 
> for the namespace. (34.196.62.143, 52.9.140.222, 52.9.146.37, 52.16.221.207, 
> 52.19.138.45, 52.86.96.73)
>us-east-1.console.aws.amazon.com zone: The server(s) did not respond 
> authoritatively for the namespace. (34.196.62.143, 52.9.140.222, 52.9.146.37, 
> 52.16.221.207, 52.19.138.45, 52.86.96.73)

Ah - thank you for your ever helpful observations! -:)

That suggests to me that the authoritative setup is somewhat "fragile".  Do
folks think that such a setup deserves to work?  Or should AWS be
encouraged to improve it?

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

[dns-operations] console.aws.amazon.com - breakage & confusing output from DNSViz?

[Matthew Richardson]

Having tried to access AWS's console today (for the first time in a while),
an NXDOMAIN (using Knot Resolver) was returned for
eu-west-1.console.aws.amazon.com (to which AWS had redirected the browser).

Trying a lab of 4 validating caching resolvers, PowerDNS returned the
answer:-

>; <<>> DiG 9.11.29 <<>> @dt05 -p 534 eu-west-1.console.aws.amazon.com
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51057
>;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 512
>;; QUESTION SECTION:
>;eu-west-1.console.aws.amazon.com. IN   A
>
>;; ANSWER SECTION:
>eu-west-1.console.aws.amazon.com. 60 IN CNAME   
>gr.console-geo.eu-west-1.amazonaws.com.
>gr.console-geo.eu-west-1.amazonaws.com. 60 IN CNAME 
>a1b62e4959fcbcf72.awsglobalaccelerator.com.
>a1b62e4959fcbcf72.awsglobalaccelerator.com. 300 IN A 75.2.73.50
>a1b62e4959fcbcf72.awsglobalaccelerator.com. 300 IN A 99.83.251.236
>
>;; Query time: 1166 msec
>;; SERVER: 193.201.42.59#534(193.201.42.59)
>;; WHEN: Mon Feb 07 17:24:27 GMT Standard Time 2022
>;; MSG SIZE  rcvd: 195

but Bind & Unbound returned SERVFAIL and Knot Resolver returned NXDOMAIN.

https://dnsviz.net/d/console.aws.amazon.com/YgEn7g/dnssec/

suggests a DNSSEC issue showing some things being BOGUS.  However (unless I
am missing something obvious), there is no DNSSEC involved!

Can anyone more knowledgeable shed any light on what might be going wrong
here?  I wonder whether this is relevant:-

>; <<>> DiG 9.11.29 <<>> @ns-912.amazon.com +norec -t ns aws.amazon.com
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34133
>;; flags: qr; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;aws.amazon.com.IN  NS
>
>;; ANSWER SECTION:
>aws.amazon.com. 600 IN  NS  ns-912.amazon.com.
>aws.amazon.com. 60  IN  CNAME   
>tp.8e49140c2-frontier.amazon.com.
>
>;; Query time: 156 msec
>;; SERVER: 52.9.146.37#53(52.9.146.37)
>;; WHEN: Mon Feb 07 14:17:31 GMT Standard Time 2022
>;; MSG SIZE  rcvd: 89

but it is something of a stab in the dark.

Also, is there anyone from AWS around these parts who might have an
insight?

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

Re: [dns-operations] TLD .law - non-signing KSK with referenced DS

[Matthew Richardson]

At Mon, 17 Jan 2022 09:09:42 +0100, Alexander Mayrhofer
 wrote:-

>> Yes, the non-signing KSK could be offline disaster recovery key. There’s
>> nothing wrong about having more keys in DS than used because the change
>> process for DS is more complicated than swapping the active key in the zone.
>
>[AM] I can second what Ondrej has written. We (.at) do have an identical setup
>with an (additional) emergency key that's in the root zone, but not used under
>normal operational circumstances to sign the zone. The management of that
>disaster recovery key is completely disjunct from our "main" key. 

Looking at .at in Zonemaster:-

https://www.zonemaster.fr/result/586829d6f4b5882d

it reports:-

DNSSEC
ERROR
The DNSKEY RRset is not signed by the DNSKEY with tag 19294 that the the DS
record refers to. Fetched from the nameservers with IP "185.102.12.2;
192.92.125.2; 194.0.10.100; 194.0.25.10; 194.146.106.50;
2001:628:2030:4301::2; 2001:678:1c::2; 2001:678:20::10; 2001:678:d::cafe;
2001:67c:1010:12::53; 2a02:568:281::130; 2a02:850:::2; 78.104.144.2;
81.91.173.130".

Given that having a standby key is a standard (and probably good!)
practice, should Zonemaster perhaps classify this as less of a problem,
maybe as a "warning"?

Obviously there needs to be at least one KSK signing the DNSKEYs...

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

Re: [dns-operations] TLD .law - non-signing KSK with referenced DS

[Matthew Richardson]

On Fri, 14 Jan 2022 13:25:35 +, Brett Carr 
wrote:

>This is the expected state, this TLD is mid transition when this is complete 
>the currently unused DS and DNSKEY will be used for signing. This is 
>pre-publication of the new data.

Thanks for that inforation (and also to Ondrej & Viktor).  My learning
experience for today is that a DS can point at a standby, but as yet
unused, KSK.  Re-reading bits of rfc6781, this now makes sense to me.

Out of interest, was it intentional that the authoratitives were returning
NXDOMAIN for dnsc.nic.law, dnsa.nic.law, dns1.nic.law & dns3.nic.law from
11 January for a day or two whilst they were still listed in the root
delegation?

https://www.zonemaster.fr/result/9e9d3f9ca39a9e6e

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

[dns-operations] TLD .law - non-signing KSK with referenced DS

[Matthew Richardson]

Having been looking at .law following what looks like a slightly
sub-optimal redelegation (now complete), I notice that Zonemaster is
reporting DNSSEC issues:-

https://www.zonemaster.fr/result/f9fcceaef969aea1

>DNSSEC ERROR The DNSKEY RRset is not signed by the DNSKEY with
>tag 16819 that the the DS record refers to.

whereas DNSViz reports no such problem:-

https://dnsviz.net/d/law/YeEwEg/dnssec/

Looking visually at the DNSViz output, the KSK 16819 does look strange as
it is referenced by a DS but does not sign anything.

Out of interest, do folks think this is a valid configuration?

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

[dns-operations] RRSIG expiry versus TTL

[Matthew Richardson]

I am wondering whether those more experienced with DNSSEC could cast their
eye on an issue, which is recurring monthly (seemingly at ZSK rollover).

https://dnsviz.net/d/itconsult-dns.info/YST9pA/dnssec/

which reported errors such as:-

>RRSIG itconsult-dns.info/NS alg 13, id 4992: With a TTL of 86400 the 
>RRSIG RR can be in the cache of a non-validating resolver until 13 
>hours, 39 minutes after it expires at 2021-08-25 00:30:00+00:00.

This domain is only for monitoring and the issue (which was spotted when
resolvers were periodically returning SERVFAIL) has been reported to the
provider.  It seems that their provider is in turn doing the DNSSEC, and
that provider has asserted:-

>it is not possible to query rrsig it directly but only together with
>NS, so it can not be cached on non validating resolver

and:-

>the RRSIG TTL should match the NS record TTL, but ..., the validating 
>resolver does not care, and should not, about RRSIG TTL. So the 
>difference between the expiration of the rrsig and the TTL shouldn't 
>or doesn't impact the online services.

Paraphrasing, they seem to be suggesting that DNSVis is reporting a
theoretical issue would not affect resolution of names used by "online
services".

Is this correct and that there is no real world problem here?

Also, is there a typo in the DNSVis error message when it refers to "the
cache of a non-validating resolver"?  Does it not mean a "validating"
resolver?

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

Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Matthew Richardson]

Testing on two separate (but similarly configured) Bind 9.11.22 servers, I
also get SERVFAIL.  The logs show entries like:-

>10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT: bad cache 
>hit (_dmarc.prv.se/DS)

On a test machine running 9.11.8, and having cleared the cache beforehand,
SERVFAIL is returned with the same message logged.

Running tcpdump of the traffic from the Bind server, it gets the following
response back clearly showing NXDOMAIN with NSEC3 records:-

>Frame 106: 1081 bytes on wire (8648 bits), 1081 bytes captured (8648 bits)
>Ethernet II, Src: Xensourc_40:5c:c5 (00:16:3e:40:5c:c5), Dst: 
>Xensourc_ec:56:8d (00:16:3e:ec:56:8d)
>Internet Protocol Version 4, Src: 80.80.64.49, Dst: 193.201.42.59
>Transmission Control Protocol, Src Port: 53, Dst Port: 33761, Seq: 1, Ack: 57, 
>Len: 1027
>Domain Name System (response)
>Length: 1025
>Transaction ID: 0xf5c2
>Flags: 0x8483 Standard query response, No such name
>1...    = Response: Message is a response
>.000 0...   = Opcode: Standard query (0)
> .1..   = Authoritative: Server is an authority for domain
> ..0.   = Truncated: Message is not truncated
> ...0   = Recursion desired: Don't do query recursively
>  1...  = Recursion available: Server can do recursive 
> queries
>  .0..  = Z: reserved (0)
>  ..0.  = Answer authenticated: Answer/authority portion 
> was not authenticated by the server
>  ...0  = Non-authenticated data: Unacceptable
>   0011 = Reply code: No such name (3)
>Questions: 1
>Answer RRs: 0
>Authority RRs: 8
>Additional RRs: 1
>Queries
>_dmarc.prv.se: type TXT, class IN
>Name: _dmarc.prv.se
>[Name Length: 13]
>[Label Count: 3]
>Type: TXT (Text strings) (16)
>Class: IN (0x0001)
>Authoritative nameservers
>prv.se: type SOA, class IN, mname dns1.prv.se
>Name: prv.se
>Type: SOA (Start Of a zone of Authority) (6)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 39
>Primary name server: dns1.prv.se
>Responsible authority's mailbox: postmaster
>Serial Number: 2020111898
>Refresh Interval: 1200 (20 minutes)
>Retry Interval: 600 (10 minutes)
>Expire limit: 1209600 (14 days)
>Minimum TTL: 3600 (1 hour)
>prv.se: type RRSIG, class IN
>Name: prv.se
>Type: RRSIG (46)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 154
>Type Covered: SOA (Start Of a zone of Authority) (6)
>Algorithm: RSA/SHA-256 (8)
>Labels: 2
>Original TTL: 3600 (1 hour)
>Signature Expiration: Mar 20, 2021 00:30:42.0 GMT Standard 
> Time
>Signature Inception: Mar  9, 2021 23:30:42.0 GMT Standard 
> Time
>Key Tag: 16321
>Signer's name: prv.se
>Signature: 65005703e9ddebaeeb4b3b9441b0eee96207c2ad7fd51e2c...
>9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type NSEC3, class IN
>Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
>Type: NSEC3 (50)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 43
>Hash algorithm: SHA-1 (1)
>NSEC3 flags: 0
> ...0 = NSEC3 Opt-out flag: Additional insecure 
> delegations forbidden
>NSEC3 iterations: 50
>Salt length: 8
>Salt value: 33e9285ab62c0803
>Hash length: 20
>Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
>RR type in bit map: A (Host Address)
>RR type in bit map: NS (authoritative Name Server)
>RR type in bit map: SOA (Start Of a zone of Authority)
>RR type in bit map: MX (Mail eXchange)
>RR type in bit map: TXT (Text strings)
>RR type in bit map: DS(Delegation Signer)
>RR type in bit map: RRSIG
>RR type in bit map: DNSKEY
>RR type in bit map: NSEC3PARAM
>9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type RRSIG, class IN
>Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
>Type: RRSIG (46)
>Class: IN (0x0001)
>Time to live: 3600
>Data length: 154
>Type Covered: NSEC3 (50)
>Algorithm: RSA/SHA-256 (8)
>Labels: 3
>Original TTL: 3600 (1 hour)
>Signature Expiration: Mar 20, 2021 00:30:42.0 GMT Standard 
> Time
>Signature Inception: Mar  9, 2021 23:30:42.0 GMT Standard 
> Time
>Key Tag: 16321
>Signer's name: prv.se
>Signature: 

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

[Matthew Richardson]

At Sat, 20 Feb 2021 11:48:54 + Simon Arlott wrote:-

>Can you recommend another registrar that supports DNSSEC?

I am in the processing of moving domains held at OpenSRS to EuroDNS
(www.eurodns.com) due to the low support which OpenSRS has for DNSSEC
particularly in European domains (.lu being one of many examples).

Looking at their documentation, they do support DNSSEC within .au.

When setting up DNSSEC with EuroDNS, unlike OpenSRS, they request the
DNSKEY details from which they generate the DS record.  When specifying the
DNSKEY there is a drop-down to define the algorithm, which includes ED25519
& ED448.

In addition to a web interface (which I currently use), they also have API
access.

Their support/sales are both responsive and knowledgable.

Although their list prices can look brisk(!!), they reduce depending on the
volume of domains one holds.  For roughly 400 domains, they end up being a
snifter cheaper than OpenSRS once converted into GBP.

Best wishes,
Matthew
___
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?

[Matthew Richardson]

On Tue, 9 Feb 2021 13:19:02 -0500, Viktor Dukhovni wrote:-

>My Perl script (below) just checks that none of the RRSIGs are expiring
>too soon.  If some RRset is not signed at all, that's not detected
>presently, but should be easy to add.

That is most useful - thank you!

My existing monitoring does feature a daily "dnssec-verify" of each
zonefile accessed via AXFR.  I hope this would detect any unsigned RRset.
If so, would simply parsing the zonefile to get each RRSIG with its expiry
(ie not bothering with other record types) check everything was in order?

>That said, if "dnssec-verify" had a parameter to set a minimum remaining
>signature time, I wouldn't need the Perl script.

A most splendid suggestion!  :-)

Best wishes,
Matthew
___
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?

[Matthew Richardson]

On Tue, 9 Feb 2021 16:43:20 +, Duane Wessels wrote:-

>If you use Nagios or something compatible, there is this:
>
>http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html
>
>But it only checks one RR (default SOA) since it doesn't assume access to the 
>whole zone.
>That would be a good upgrade, though, to have it axfr the zone and check 
>everything.

Are there any existing tools which would take a whole zonefile and check
the expirations?  In a similar way to (for example) dnssec-verify from
Bind.

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

Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

[Matthew Richardson]

On Tue, 19 Jan 2021 08:37:09 -0500, Viktor Dukhovni wrote:-

>On Tue, Jan 19, 2021 at 09:24:09AM +0000, Matthew Richardson wrote:
>
>> At Mon, 18 Jan 2021 13:55:21 -0500, Viktor Dukhovni wrote:-
>> 
>> >2.  Changing the salt takes some care, so "nobody" does it.
>> 
>> Any pointers to the "care" required when changing salt (or the iteration
>> count) would be appreciated.  My searches reveal little information.  In
>> particular, what timing issues exist with respect to the zone's TTLs?
>
>Sorry for leaving this vague.  Changing the salt requires rebuilding the
>entire NSEC3 chain, and so is difficult to combine with incremental zone
>signing (such as BIND's "auto-dnssec maintain").  If you're doing
>periodic whole zone signing, which reconstructs the entire chain, you
>can change the salt at will each time the zone is signed from scratch.
>
>If, on the other hand, the zone is signed incrementally as individual
>records are modified, then there is not an opportunity to change the
>salt, which needs to be consistent across the entire chain.

My tests with Bind 9.11 using "inline-signing yes; auto-dnssec maintain;"
suggests that if one issues "rndc signing -nsec3param 1 0 0 [salt] [zone]"
all the NSEC3 records are immediately replaced and fully re-signed.  The
NSEC3PARAM record always seems to have a zero TTL.

Thus (I think) the master zone is always correctly/fully signed/nsec3ed as
it reconstructs the whole chain.

I wonder however about resolvers and negative caching, as the NSEC3 records
and their signatures have the default TTL for the zone and could therefore
be cached for several hours by resolvers.

Given Bind's behaviour (which looks good), are there any issues with
caching/TTLs were one to change the salt with "rndc signing"?

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

Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

[Matthew Richardson]

At Mon, 18 Jan 2021 13:55:21 -0500, Viktor Dukhovni wrote:-

>2.  Changing the salt takes some care, so "nobody" does it.

Any pointers to the "care" required when changing salt (or the iteration
count) would be appreciated.  My searches reveal little information.  In
particular, what timing issues exist with respect to the zone's TTLs?

With any thanks.

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

Re: [dns-operations] .ag outage

[Matthew Richardson]

DNSvis has recorded two entries for hoevelmann.ag.  Whilst the latest one
looks OK, the previous one:-

https://dnsviz.net/d/hoevelmann.ag/X8DXeQ/dnssec/

is showing an amount of bogusness.

This previous one may be a clue...

Best wishes,
Matthew

 --
>From: Thomas Mieslinger 
>To: dns-operations@lists.dns-oarc.net
>Cc: 
>Date: Fri, 27 Nov 2020 12:09:08 +0100
>Subject: [dns-operations] .ag outage

>Hi,
>
>I received customer complaints that quad8 and some german broadband
>resolvers were unable to resolve .ag secondlevel domains.
>
>peak.ag
>hoevelmann.ag
>sonnenschein.ag
>hostedoffice.ag
>
>I run the authoritatives serving the first three examples and we've had
>no outage.
>
>I don't understand the DNSEC keys in .ag and the intended change carried
>out with the current setup.
>
>https://dnsviz.net/d/hoevelmann.ag/dnssec/
>
>Do you also see problems with .ag?
>
>Cheers
>
>Thomas
>
>___
>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] A strange DNS problem (intermittent SERVFAILs)

[Matthew Richardson]

Dear Stephane,

Whilst I have not got an answer, I have managed to get an example of a
failure using Cloudflare:-

>; <<>> DiG 9.11.19 <<>> @1.1.1.1 banquepopulaire.fr ns
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41975
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 1452
>;; QUESTION SECTION:
>;banquepopulaire.fr.IN  NS
>
>;; Query time: 14 msec
>;; SERVER: 1.1.1.1#53(1.1.1.1)
>;; WHEN: Sat May 30 18:02:59 BST 2020
>;; MSG SIZE  rcvd: 47

and thereafter:-

>; <<>> DiG 9.11.19 <<>> @1.1.1.1 www.banquepopulaire.fr
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53725
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 1452
>;; QUESTION SECTION:
>;www.banquepopulaire.fr.IN  A
>
>;; Query time: 4148 msec
>;; SERVER: 1.1.1.1#53(1.1.1.1)
>;; WHEN: Sat May 30 18:03:21 BST 2020
>;; MSG SIZE  rcvd: 51

I wonder whether the first one (SERVFAIL for NS) is a clue.  bcpe.fr is
delegated to the same servers which do not answer NS queries.  Thus, NS
RRSET is only available from the parent (.fr) and not the child.  Maybe
this upsets child-centric resolvers.

I am just guessing though...

The whole thing is très mauvaise pratique as reported, all the more so for
a bank!

Best wishes,
Matthew

 --
>From: Stephane Bortzmeyer 
>To: DNS Operations List 
>Cc: 
>Date: Sat, 30 May 2020 18:09:24 +0200
>Subject: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

>Several users on Twitter reported problems accessing Banque Populaire
>(a French bank) https://www.banquepopulaire.fr
>https://www.ibps.loirelyonnais.banquepopulaire.fr
>https://www.ibps.bpaca.banquepopulaire.fr
>https://www.ibps.mediterranee.banquepopulaire.fr/
>
>From the limited reports, all errors point to a DNS issue. (For one
>user, adding the IP address in /etc/hosts solved the problem.)
>
>But testing with existing resolvers and with the RIPE Atlas probes do
>not show a widespread outage.
>
>The existing DNS configuration is clearly very questionable, such as a
>zone delegated to just one name server, and a broken one, replying
>REFUSED for NS and SOA queries.
>
>The question is "how did this incorrect setup can produce *sometimes*
>a resolution failure?"
>
>Details in french, plus dig outputs (not in french) are at
>.
>
>___
>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] NXDOMAIN vs NOERROR/no answers for non-existant records

[Matthew Richardson]

Thanks - I had also missed the subtelty that monitor.itconsult.net shared
servers with itconsult.net.

For testing, I have setup testmon.itconsult.net which is delegated in the
same way (ie insecure) as mtgmon.itconsult.net.  However, I get the same
results, namely NOERROR for mtgmon and NXDOMAIN for testmon:-

>; <<>> DiG 9.11.13 <<>> +norec +noadditional @dns3.mtgsy.com 
>doesnotexist.mtgmon.itconsult.net
>; (2 servers found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38925
>;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>;; QUESTION SECTION:
>;doesnotexist.mtgmon.itconsult.net. IN  A
>
>;; AUTHORITY SECTION:
>mtgmon.itconsult.net.   86400   IN  SOA dns0.mtgsy.com. 
>hostmaster.mtgmon.itconsult.net. 2016072809 3600 1200 1209600 3600
>
>;; Query time: 102 msec
>;; SERVER: 162.243.59.139#53(162.243.59.139)
>;; WHEN: Mon Apr 06 11:23:01 BST 2020
>;; MSG SIZE  rcvd: 143

and:-

>; <<>> DiG 9.11.13 <<>> +norec +noadditional @dt01.itconsult.net 
>doesnotexist.testmon.itconsult.net
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53268
>;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>; COOKIE: aaca28581cfb0aee52c39f995e8b033847b494952922316b (good)
>;; QUESTION SECTION:
>;doesnotexist.testmon.itconsult.net. IN A
>
>;; AUTHORITY SECTION:
>testmon.itconsult.net.  43200   IN  SOA dt01.itconsult.net. 
>hostmaster.itconsult.net. 1 7200 900 1814400 43200
>
>;; Query time: 1 msec
>;; SERVER: 193.201.42.33#53(193.201.42.33)
>;; WHEN: Mon Apr 06 11:23:53 BST 2020
>;; MSG SIZE  rcvd: 143

This confirms that the difference in behaviour is not due to the sharing of
DNS servers.

Best wishes,
Matthew

 --
>From: Shumon Huque 
>To: Stephane Bortzmeyer 
>Cc: DNS Operations List 
>Date: Fri, 3 Apr 2020 09:06:20 -0400
>Subject: Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant 
>records

>On Fri, Apr 3, 2020 at 8:20 AM Stephane Bortzmeyer 
>wrote:
>
>> On Fri, Apr 03, 2020 at 07:48:16AM -0400,
>>  Shumon Huque  wrote
>>  a message of 98 lines which said:
>>
>> > The second one,  doesnotexist.monitor.itconsult.net., does not appear
>> to be
>> > delegated from its parent.
>>
>> This is not what I see. Both are delegated from itconsult.net
>> (source: their SOA).
>>
>
>Ah, yes. The subtlety here (which I didn't notice at first) is that
>monitor.itconsult.net is served by the same name servers as its parent.
>Since most authority servers answer from their closest enclosing zone, most
>iterative debugging tools like dig+trace etc won't see the delegation.
>
>Shumon.

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

Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records

[Matthew Richardson]

Thanks - I also had thought the NODATA response was wrong, but wanted a
second opinion...

However, is this going to cause any practical problems?

There are many domains being responded to in this way, and I do not think
any use DNSSEC.

Best wishes,
Matthew

 --
>From: Stephane Bortzmeyer 
>To: Matthew Richardson 
>Cc: dns-operati...@dns-oarc.net
>Date: Fri, 3 Apr 2020 14:18:45 +0200
>Subject: Re: NXDOMAIN vs NOERROR/no answers for non-existant  records

>On Fri, Apr 03, 2020 at 12:31:38PM +0100,
> Matthew Richardson  wrote 
> a message of 75 lines which said:
>
>> where mtgmon.itconsult.net & monitor.itconsult.net are delegated to
>> different authoratitives.
>
>IMHO, the authoritative name servers for monitor.itconsult.net are
>correct and those for mtgmon.itconsult.net are wrong (sending NODATA
>instead of NXDOMAIN, even for ANY queries.)

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

[dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records

[Matthew Richardson]

I am observing responses from particular authoratitive servers for
non-existant domains, which is puzzling me.  I thought I understood this
topic, but am now having doubts...

Consider two (real) non-existant records (which are not empty non-terminals
- there is nothing below them):-

doesnotexist.mtgmon.itconsult.net
doesnotexist.monitor.itconsult.net

where mtgmon.itconsult.net & monitor.itconsult.net are delegated to
different authoratitives.

Querying each against the authoratitives returns NOERROR with "ANSWER: 0"
for the first one and NXDOMAIN for the second, behaviour which is
consistent across all the authoratitives:-

>; <<>> DiG 9.11.13 <<>> +norec +noadditional @dns3.mtgsy.com 
>doesnotexist.mtgmon.itconsult.net
>; (2 servers found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19211
>;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>;; QUESTION SECTION:
>;doesnotexist.mtgmon.itconsult.net. IN  A
>
>;; AUTHORITY SECTION:
>mtgmon.itconsult.net.   86400   IN  SOA dns0.mtgsy.com. 
>hostmaster.mtgmon.itconsult.net. 2016072809 3600 1200 1209600 3600
>
>;; Query time: 116 msec
>;; SERVER: 66.228.62.33#53(66.228.62.33)
>;; WHEN: Fri Apr 03 12:19:35 BST 2020
>;; MSG SIZE  rcvd: 143

and:-

>; <<>> DiG 9.11.13 <<>> +norec +noadditional @c.itconsult-dns.je 
>doesnotexist.monitor.itconsult.net
>; (2 servers found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24100
>;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>; COOKIE: 9c5d1336b65682124007962c5e871bf967c716afd443a7df (good)
>;; QUESTION SECTION:
>;doesnotexist.monitor.itconsult.net. IN A
>
>;; AUTHORITY SECTION:
>monitor.itconsult.net.  43200   IN  SOA a.itconsult-dns.net. 
>hostmaster.itconsult.net. 67 7200 900 1814400 43200
>
>;; Query time: 160 msec
>;; SERVER: 108.61.207.208#53(108.61.207.208)
>;; WHEN: Fri Apr 03 12:20:25 BST 2020
>;; MSG SIZE  rcvd: 154

I had thought that the first behaviour returning NOERROR without answer for
doesnotexist.mtgmon.itconsult.net is incorrect, but would value the opinion
of those more learned than myself.

Also, if the behaviour were to be incorrect, what practical problems might
it cause?

With many thanks.

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

Re: [dns-operations] Request for Help: Who is looking after .org DNSsec?

[Matthew Richardson]

Looking at the whois for that domain, it is showing:-

>Updated Date: 2020-02-02T14:44:44Z

which suggests that something was changed 4 days ago...

Best wishes,
Matthew

 --
>From: Jim Reid 
>To: pirawa...@ku.th
>Cc: dns-operations@lists.dns-oarc.net
>Date: Thu, 6 Feb 2020 16:43:59 +
>Subject: Re: [dns-operations] Request for Help: Who is looking after .org 
>DNSsec?

>
>
>> On 6 Feb 2020, at 09:08, Pirawat WATANAPONGSE  wrote:
>> 
>> So I am now wondering whether we were contacting the wrong team, and 
>> register.com is no longer responsible for DNSsec operations of .org
>
>register.com have never been responsible for the DNSSEC operations of .org. 
>These lie with PIR, the .org registry.
>
>If you’re having problems with the signed delegation for kasetsart.org, that’s 
>almost certainly a matter for your registrar. Which appears to be 
>register.com. You’ll need to contact them to find out how to get a new DS 
>record(s) for that domain into the .org TLD.  [Just like you’d contact them to 
>get the delegation’s NS records changed.] You will probably have to ask them 
>why they’ve not done anything in response to your earlier attempts to update 
>the DS record(s). Perhaps you’re talking to the wrong people at your registrar?
>
>Another possible explanation is you’ve given register.com the wrong keying 
>material and that is preventing the DS record(s) from being updated in .org 
>because they wouldn’t point at the right KSK(s) in kasetsart.org? Though if 
>that happened, you should have received error notifications.
>
>
>___
>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