Re: [dns-operations] ag.gov not providing NXDOMAIN responses

[Viktor Dukhovni]

On Tue, Apr 09, 2024 at 01:09:20PM -0500, David Zych wrote:

> Does anyone happen to know the folks responsible for ns1.usda.gov. and
> ns2.usda.gov.?

No, but you could also try the SOA "rname", with the first label as
email address local part:

ag.gov. IN SOA ns1.usda.gov. duty.offi...@usda.gov 2005252386 9 9000 
9 900

and if that fails, then perhaps fall back to Cameron Dixon at CISA, if
you feel the issue warrants escalation.

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

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

[Viktor Dukhovni]

On Wed, Mar 27, 2024 at 07:17:01PM +, Matthew Richardson via dns-operations 
wrote:

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

The SHA-1 hash function "comresses" 64 bytes of input (a 512-bit block)
to 20 bytes of output, 8 of the trailing input bytes are a 64-bit
message length, and there's at least 1 byte (0x80) of padding.

https://datatracker.ietf.org/doc/html/rfc3174#section-4

Whether additional SHA-1 blocks are required depends on the length of
the owner-name:

https://datatracker.ietf.org/doc/html/rfc5155#section-5

If the owner name and salt fit into 55 bytes, a single SHA-1 block would
be sufficient, otherwise a second or more SHA-1 block may be required.
Worst case is 255 bytes of owner name (wire form) + 255 bytes of salt,
which would require 9 SHA-1 blocks.

With a zero length salt, one gets to hash 55 bytes of owner-name in a
single SHA-1 block.

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

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

[Viktor Dukhovni]

On Mon, Mar 25, 2024 at 09:27:06AM +0100, Haya Shulman wrote:

> Our evaluations demonstrate that the two attack vectors are fundamentally
> different from the perspective of their practical impact: KeyTrap
> introduces a realistic immediate threat for exploitation by hackers. In
> contrast, with NSEC3-encloser attack a comparable load on resolvers is not
> possible, not only that with a single NSEC3-encloser attack no packet is
> lost, but also no latency is introduced to the resolvers. The high volume
> of NSEC3-encloser attack traffic, of more than hundreds of packets per
> second, makes the NSEC3-encloser attack visible. Therefore, the high attack
> volume in tandem with the meager benefit for adversaries (only a small
> fraction of benign packets dropped) implies that such attacks do not pose a
> practical threat.

Reading the paper, I get an impression that the described attack isn't
nearly as stressful on the resolver CPU as it could be.  If I understood
the measured attack correctly, a more "malicious" approach could
substantially (~100x) increase the per-query-response CPU cost.  Perhaps
qualitatively changing the relative impact assessment?

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

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

Re: [dns-operations] Anybody know if .FI is realtime updates?

[Viktor Dukhovni]

On Tue, Feb 13, 2024 at 02:12:07PM -0500, Mark E. Jeftovic wrote:

> Would anybody know how often the .FI registry updates?
> 
> Is it realtime? Once-per-hour?
> 
> asking for a friend... thx

The signature inception times of 40 random DS records under .fi suggest
signing happens every 20 minutess (at ~11, 31 and 51 minutes past the
hour):

2024-02-09T17:31:18
2024-02-09T18:51:16
2024-02-09T19:11:13
2024-02-09T20:31:28
2024-02-09T23:11:16
2024-02-09T23:11:16
2024-02-10T01:31:14
2024-02-10T02:51:24
2024-02-10T05:31:30
2024-02-10T14:31:13
2024-02-10T18:31:34
2024-02-10T19:51:10
2024-02-10T21:11:10
2024-02-11T00:31:17
2024-02-11T19:31:10
2024-02-11T19:51:09
2024-02-11T22:31:10
2024-02-12T00:51:09
2024-02-12T01:31:30
2024-02-12T05:31:26
2024-02-12T07:11:10
2024-02-12T07:31:11
2024-02-12T08:11:10
2024-02-12T09:11:11
2024-02-12T09:51:11
2024-02-12T11:31:30
2024-02-12T18:11:12
2024-02-12T21:31:15
2024-02-12T21:31:15
2024-02-12T21:51:10
2024-02-13T00:31:12
2024-02-13T06:11:12
2024-02-13T07:11:18
2024-02-13T09:31:12
2024-02-13T09:31:12
2024-02-13T11:31:47
2024-02-13T12:51:10
2024-02-13T14:11:30
2024-02-13T15:11:12
2024-02-13T16:51:10

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

Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation

[Viktor Dukhovni]

On Thu, Feb 08, 2024 at 12:24:08PM +, Edward Lewis wrote:

> Between non-unique key tags and the possibility of hash collisions,
> it's possible two DS resource records could share either a key  tag or
> a hash representing different keys.  From this, I wish we hadn't
> defined the key tag field - and maybe stuck with the entire key in the
> DS resource record.  Over the long term, ... I see things differently.

Collisions in SHA2-256 (with SHA1 in DS records being deprecated for
some time now), would be major news indeed.  There's not even a hint of
such collisions being found in the next few decades.  SHA1 collisions
are of course a possibility, but require considerable computing
resources and don't just happen "at random" (as is the case with key
tags).

There is no issue with DS record confusion.  And even if two keys
produced the same DS record, that'd be fine too, just publish one DS
record in support of both!  The only theoretical risk is erroneously
publishing two identical RRs in the DS RRset, which is not allowed,
and validators may balk...  In practice, this won't happen.

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

Re: [dns-operations] Digicert DNS aka dnsmadeeasy poc?

[Viktor Dukhovni]

On Thu, Jan 18, 2024 at 09:51:45PM +, Renee Burton via dns-operations wrote:

> Can anyone on the list connect me with Digicert DNS? I can’t figure
> out who this really is although they are big name servers.

If this is the real DigiCert, then perhaps the "digicert.com" SOA rname
might work?  With the `rname` RFC5322 form, it is:

digicert.com. IN SOA ns20.digicertdns.com. d...@digicertdns.com ...

-- 
Viktor.

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

Re: [dns-operations] COM referral responses from root without glue and TC bit

[Viktor Dukhovni]

On Fri, Jan 12, 2024 at 02:40:22PM -0800, Wes Hardaker wrote:
> Viktor Dukhovni  writes:
> 
> > > Relevant text from RFC 9471 abstract: If message size constraints
> > > prevent the inclusion of all glue records for in-domain name servers,
> > > the server must set the TC (Truncated) flag to inform the client that
> > > the response is incomplete.
> > 
> > Indeed, and so 6 out of 13 roots need to be updated to set TC=1 as
> > required.
> 
> Definitely true.  Having said that, different software behaves
> differently (as we run multiple different software packages, I see
> differences across our deployment even).
> 
> Note that although this should be done, the specification mandating this
> is from September of last year so the software hasn't likely caught up
> yet.  Though there is some argument that RFC1034 said this too, but less
> well stated.
> 
> I'll further note that this is not a root specific problem.  This is
> likely true across the deployed DNS ecosystem, but the root does serve
> as a good test case.

However, in partial defense of the root servers, it should be noted that
while "gtld-servers.net" is in-bailiwick for the root servers, it is not
in- bailiwick for the "com." delegation, and so a glueless response
should be handled gracefully.  The "missing" glue is *sibling* glue.

The more severe form of the problem is for essentially the same query at
the ".net" TLD, with the same results:

; <<>> DiG 9.16.40-RH <<>> +norecur +ignore +noedns @m.root-servers.net -t 
a 
kcmbrvwjafupdyztdq2ifvi6ye7fcacaaben6jaavmoaaaeqnqaaa2qnh7j.a5erjsqwn7zic34e7psoufcfue6rsznpw34cx57gjhhqqj6edwr6o57wikagcdv.ard6pjajyuo6kmpbm6ohbbjppyhmkivhxxmgqgb5xjpl2cvvlzo34erwypot4fw.lh4aa5rzkni7yihszvyxxw43w4aa3cysaws7jtjg.dns.uas-1.optnl.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3211
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:

;kcmbrvwjafupdyztdq2ifvi6ye7fcacaaben6jaavmoaaaeqnqaaa2qnh7j.a5erjsqwn7zic34e7psoufcfue6rsznpw34cx57gjhhqqj6edwr6o57wikagcdv.ard6pjajyuo6kmpbm6ohbbjppyhmkivhxxmgqgb5xjpl2cvvlzo34erwypot4fw.lh4aa5rzkni7yihszvyxxw43w4aa3cysaws7jtjg.dns.uas-1.optnl.net.
 IN A

;; AUTHORITY SECTION:
net.172800  IN  NS  k.gtld-servers.net.
net.172800  IN  NS  g.gtld-servers.net.
net.172800  IN  NS  m.gtld-servers.net.
net.172800  IN  NS  c.gtld-servers.net.
net.172800  IN  NS  d.gtld-servers.net.
net.172800  IN  NS  b.gtld-servers.net.
net.172800  IN  NS  e.gtld-servers.net.
net.172800  IN  NS  f.gtld-servers.net.
net.172800  IN  NS  h.gtld-servers.net.
net.172800  IN  NS  a.gtld-servers.net.
net.172800  IN  NS  i.gtld-servers.net.
net.172800  IN  NS  j.gtld-servers.net.
net.172800  IN  NS  l.gtld-servers.net.

This time, the response is a dead-end glueless in-bailiwick delegation
for ".net".

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

Re: [dns-operations] COM referral responses from root without glue and TC bit

[Viktor Dukhovni]

On Fri, Jan 12, 2024 at 02:25:15PM -0500, Puneet Sood via dns-operations wrote:

> Note: query does not use EDNS0; response does not set TC bit and has no glue.

> ; <<>> DiG 9.10.6 <<>> @m.root-servers.net 
> kcmbrvwjafupdyztdq2ifvi6ye7fcacaaben6jaavmoaaaeqnqaaa2qnh7j.a5erjsqwn7zic34e7psoufcfue6rsznpw34cx57gjhhqqj6edwr6o57wikagcdv.ard6pjajyuo6kmpbm6ohbbjppyhmkivhxxmgqgb5xjpl2cvvlzo34erwypot4fw.lh4aa5rzkni7yihszvyxxw43w4aa3cysaws7jtjg.dns.uas-1.optnl.com
>  +noedns +ignore
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44314
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;kcmbrvwjafupdyztdq2ifvi6ye7fcacaaben6jaavmoaaaeqnqaaa2qnh7j.a5erjsqwn7zic34e7psoufcfue6rsznpw34cx57gjhhqqj6edwr6o57wikagcdv.ard6pjajyuo6kmpbm6ohbbjppyhmkivhxxmgqgb5xjpl2cvvlzo34erwypot4fw.lh4aa5rzkni7yihszvyxxw43w4aa3cysaws7jtjg.dns.uas-1.optnl.com.
> IN A

This rather violates "Glue is not optional".  The (mis)behaviour is
reproducible.

> We confirmed similar behavior from some of the other root operators.
>
> b;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
> c;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> g;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> i;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> k;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> m;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

> a;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
> d;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> e;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
> f;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
> h;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
> j;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
> l;; flags: qr tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

> Relevant text from RFC 9471 abstract: If message size constraints
> prevent the inclusion of all glue records for in-domain name servers,
> the server must set the TC (Truncated) flag to inform the client that
> the response is incomplete.

Indeed, and so 6 out of 13 roots need to be updated to set TC=1 as
required.

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

Re: [dns-operations] Old version of dig on macOS

[Viktor Dukhovni]

On Mon, Dec 18, 2023 at 06:48:30PM +, Weinberg, Matt wrote:

> The latest patched versions of macOS Ventura (13.6.3) and Sonoma
> (14.1.2) both include an old version of the dig client:
> 
> % dig -v
> DiG 9.10.6
> 
> I only noticed the issue when I attempted to retrieve the ZONEMD
> record of the root zone from my MacBook (it didn’t work).  I can’t
> speak to whether this older version of dig is missing any other
> features (or addresses any security concerns).
> 
> Anyone know how best to nudge Apple into updating the default dig
> client on macOS?  Thoughts either way?

A starting point (per https://opensource.apple.com/) might be:
.  The github repo is perhaps a bit behind
the shipped binary, it shows 9.9.7-p3:

https://github.com/apple-oss-distributions/bind9/blob/main/bind9/version

-- 
Viktor.

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

Re: [dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone

[Viktor Dukhovni]

On Wed, Dec 06, 2023 at 08:36:22PM +, Wessels, Duane via dns-operations 
wrote:

> I’m happy to announce that the second phase of ZONEMD deployment for the root 
> zone is now complete.  As of serial 2023120602, the hash algorithm field is 
> set to 1:
> 
> ;; ANSWER SECTION:
> . 86400 IN ZONEMD 2023120602 1 1 
> 9E877AB7584FF83F738D3F51CC914AF396741B7A49E50D0C9ED9BA05 
> ACA08FC9B62A56673D2D93D5720E4DD505733932

Congratulations and thanks!  Today, I did not receive what has recently
been a daily automated zone validation warning for my localroot slave
zone, since the zone now fully validates via ldns-verify-zone:

$ named-compilezone -i local -jD -f raw -o - . root.slave |
ldns-verify-zone -e P0Y0M3DT3H23M54S -V1 /dev/stdin
zone ./IN: loaded serial 2023120602 (DNSSEC signed)
OK

-- 
Viktor.

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

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

[Viktor Dukhovni]

On Fri, Nov 03, 2023 at 11:09:02AM +0100, Vladimír Čunát via dns-operations 
wrote:

> On 01/11/2023 17.18, Viktor Dukhovni wrote:
> > Should authoritative [nameservers] have knobs to perform internal checks on
> > the signed zones they serve and at least syslog loud warnings?
> 
> My understanding is that in this case the signer was producing loud syslog
> warnings immediately when the issue happened (i.e. long before validation
> could fail).

Sure, but the warnings were far from a clear indication that resigning
of the entire zone has stopped.  In any case, logging isn't exactly the
best interface for realtime monitoring.

I do think that exposing the next expiration time for monitoring and
likewise a list of zones where that time is too soon would be of value
to operators.  It doesn't obviate the need for active query probes,
those should still also happen, but I do think that operators would
benefit from such a (new) signal.

-- 
Viktor.

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

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

[Viktor Dukhovni]

On Thu, Nov 02, 2023 at 09:34:17AM +0100, Stephane Bortzmeyer wrote:

> > Specifically, in the case of signed zones, monitoring MUST also include
> > regular checks of the remaining expiration time of at least the core
> > zone apex records (DNSKEY, SOA and NS), and ideally the whole zone, both
> > on the primary server and the secondaries.
> 
> Indeed. If you use Nagios or compatible (such as Icinga), I recommend
> this plugin for signatures monitoring:
> 
> http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html

I wonder whether the widely authoritative resolvers could do more to
to help?

For example, BIND loads zone data into memory.  It should be able to
know the time of the soonest signature expiration for a zone, or at
least (if not loaing the whole zone into memory) the soonest expiration
time is of recently queried records.

There could be a new "rdnc" protocol verb that asks the nameserver for a
list of all the zones where the soonest expiration time is below some
threshold, or askes about a particular zone.

Of course in that case the monitoring agent would be a in a "privileged"
position to query the nameserver's internal control plane, rather than
having to send queries through "the front door".

Both kinds of monitoring are likely important, but more visibility via
the control plane may be able to offer a precise/timely view.

- Check each nameserver's control plane.
- Check as much of the zone as possible.
- Check each nameserver VIP over each supported protocol
  (UDP, TCP, DoT, DoQ, ...)
- From multiple vantage points if possible/applicable when
  service is on anycast IPs.

Perhaps through OARC support development of monitoring plugins that
many operators can use?

If after all the past incidents minor and not so minor operators
still aren't doing adequate monitoring, perhaps we (the software
and standards) developers and haven't given them adequate tools?

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

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

[Viktor Dukhovni]

On Wed, Nov 01, 2023 at 04:49:01PM +0100, Mark Andrews wrote:

> It shouldn’t take any time as the bogus records shouldn’t have been cached.
> 

Right, unlike mismatched parent-side DS RRs, RRSIG expiration heals
fairly promptly once the zone is resigned at the origin.

I am repeatedly surprised when I hear of operators finding out about
RRSIG expiration after the fact from 3rd parties.

Somehow the reflexive knowlege that DNS monitoring means not only:

- Is it still working at this very moment

but also:

- Is it about to stop working if nothing is done soon

appears to not have become an ingrained part of the operator culture.

* What can we as a community do to get the message out?
* What tooling improvements could make this easier for operators?

Specifically, in the case of signed zones, monitoring MUST also include
regular checks of the remaining expiration time of at least the core
zone apex records (DNSKEY, SOA and NS), and ideally the whole zone, both
on the primary server and the secondaries.

There needs to be a minimum acceptable remaining RRSIG time that's some
reasonable fraction of the total RRSIG lifetime, which if crossed leaves
enough time for the responsible operator to react and rectify any
issues.  My tiny zones are monitored to not go below ~π days of
remaining RRSIG validity. :-)

ldns-verify-zone -e P0Y0M3DT3H23M54S -V1 ...

[ Of course that minimum time needs to be less than the threshold at which
  extant records are normally resigned. ]

Should authoritative resolvers have knobs to perform internal checks on
the signed zones they serve and at least syslog loud warnings?

If there were some protocol to get a message into a monitoring system,
that would be even better...

Ideally, if operators cannot or do not on their own implement the
requisite monitoring, is it possible to make it easy enough for them to
do, and is sufficiently prominently documented or otherwise becomes well
known, that they start doing it?

"Unmonitored critical service", especially when it involves security,
should be an oxymoron.

-- 
Viktor.

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

Re: [dns-operations] xn--mgbai9azgqp6j broken

[Viktor Dukhovni]

On Thu, Oct 19, 2023 at 02:02:22PM +, Carr, Brett via dns-operations wrote:

> From: "Carr, Brett" 
> Date: Thu, 19 Oct 2023 14:02:22 +
> Subject: xn--mgbai9azgqp6j broken
> To: "dns-operati...@dns-oarc.net" 
> 
> This may have been mentioned before as I think it has been broken for
> quite some time but:
> 
> None of the delegated NS’s for xn--mgbai9azgqp6j (IDN for .pk) seem to
> be responding to queries.
> 
> Anyone on list from .pk or who knows them?  If not I’ll report
> directly to their tech contact.

I vaguely recall that indeed this has been the case for quite some time.
Perhaps, if there are no active delegations, it hardly matters...

-- 
Viktor.

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

Re: [dns-operations] NSEC3PARAM change strange behaviour

[Viktor Dukhovni]

On Wed, Oct 11, 2023 at 07:32:28PM +0400, Misak Khachatryan wrote:

> I'm maintaining a rather big DNS zone - around 2.5 Megabytes in ASCII
> format, more than 40k records overall.

40k records is neither small, nor unusually large.  This should work
without issues.

> Authoritative server software is Bind. NSEC3PARAM in dnssec-policy was
> defined as:
>
>   nsec3param optout yes salt-length 24;
> 
> Today i decided to change it to:
>
>   nsec3param optout yes;
> 
> which according to defaults for my Bind version expands to:
> nsec3param iterations 5 optout yes salt-length 8;
> 
> After issuing rndc reconfig for around 3 minutes my monitoring went crazy,
> sending notifications about dnssec errors, but checking the zone with
> DNSViz and DNSSEC Analyzer reporting that everything is normal. Using dig
> @server zone NSEC3PARAM at problematic time server didn't return NSEC3PARAM
> record, reporting it as missing.

The new NSEC3 chain should be constructed in full, before the nameserver
switches to the resulting chain once it is fully built.

At that point, the SOA would be bumped, and zone transfers can start.
The key question is whether the transfers will IXFR or AXFR (which may
be more appropriate for such a bulk change).

> Three minutes later everything went normal. In the Bind log I see several
> zone transfers to slaves around every second. I presume that such a big
> zone can't be transferred in one part, which causes this behavior.

For this change, The zone transfer needs to be atomic.  It is not OK to
have half an NSEC3 chain.

> My question to other maintainers of big zones - do you have such
> experience, and what is the correct way to update NSEC3 parameters in
> order to have a smooth transition?

I don't have relevant experience, but you should be able to reproduce
the scenario in a test environment, and if not using the latest version
of BIND, try a newer (or else earlier) version and compare.

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

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

[Viktor Dukhovni]

On Sat, Oct 07, 2023 at 01:38:10PM -0400, Viktor Dukhovni wrote:

> So, it looks like "unbound" is not fond of empty NODATA replies with no
> SOA.  It is I think reasonable to ask Microsoft to address the "no SOA"
> NODATA response.

This was addressed upstream three days ago:

https://github.com/NLnetLabs/unbound/issues/946

Not yet in any release...

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

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

[Viktor Dukhovni]

On Sat, Oct 07, 2023 at 09:12:31AM -0700, jack tavares wrote:

> Interesting, it works fine with dig, but I get the same error the
> author does when I use "host"
> 
> I used to know the significant differences between "host" and "dig" but I
> have
> not used "host" in so long, I have forgotten them.

The "host" command, performs three lookups:

- hostname IN A ?
- hostname IN  ?
- hostname IN MX ?

In the case of "outlook-com.olc.protection.outlook.com", the ""
query elicits an uncacheable "empty" NODATA response from the
authoritative server, with just the EDNS(0) OPT record, and no SOA.

$ dig +nocmd +norecur -t  outlook-com.olc.protection.outlook.com 
@ns1-gtm.glbdns.o365filtering.com.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38963
;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;outlook-com.olc.protection.outlook.com.IN 

;; Query time: 54 msec
;; SERVER: 104.47.44.8#53(ns1-gtm.glbdns.o365filtering.com.) (UDP)
;; WHEN: Sat Oct 07 13:18:02 EDT 2023
;; MSG SIZE  rcvd: 67

In contrast, the "MX" query response is more "normal".

$ dig +nocmd +norecur -t mx outlook-com.olc.protection.outlook.com 
@ns1-gtm.glbdns.o365filtering.com.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39567
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;outlook-com.olc.protection.outlook.com.IN MX

;; AUTHORITY SECTION:
olc.protection.outlook.com. 300 IN  SOA 
bn1ffonetglb003.protection.outlook.com. 
hostmaster.bn1ffonetglb003.protection.outlook.com. 2023060907 10800 3600 604800 
300

;; Query time: 58 msec
;; SERVER: 104.47.44.8#53(ns1-gtm.glbdns.o365filtering.com.) (UDP)
;; WHEN: Sat Oct 07 13:21:52 EDT 2023
;; MSG SIZE  rcvd: 130

When I pose the "" and "MX" questions to "unbound", the results are:

 1. $ dig +nocmd -t  outlook-com.olc.protection.outlook.com @127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7009
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1400
;; QUESTION SECTION:
;outlook-com.olc.protection.outlook.com.IN 

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Oct 07 13:24:26 EDT 2023
;; MSG SIZE  rcvd: 67

 2. $ dig +nocmd -t mx outlook-com.olc.protection.outlook.com @127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13868
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1400
;; QUESTION SECTION:
;outlook-com.olc.protection.outlook.com.IN MX

;; AUTHORITY SECTION:
olc.protection.outlook.com. 300 IN  SOA 
bn1ffonetglb003.protection.outlook.com. 
hostmaster.bn1ffonetglb003.protection.outlook.com. 2023060907 10800 3600 604800 
300

;; Query time: 90 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Oct 07 13:23:07 EDT 2023
;; MSG SIZE  rcvd: 130

So, it looks like "unbound" is not fond of empty NODATA replies with no
SOA.  It is I think reasonable to ask Microsoft to address the "no SOA"
NODATA response.

Meanwhile, the OP can configure "outlook.com" for IPv4-only delivery as
a work-around, if his MTA[1] is unable/unwilling to use the IPv4 addresses
when IPv6 address lookups tempfail.

-- 
Viktor.

[1] Or consider switching to Postfix, which is able to tolerate failure
to resolve one of the candidate address families, so long as the other
resolves:

$ posttls-finger -c -l verify -F /etc/ssl/cert.pem outlook.com
posttls-finger: outlook-com.olc.protection.outlook.com[52.101.73.7]:25: 
matched peername: *.olc.protection.outlook.com
posttls-finger: outlook-com.olc.protection.outlook.com[52.101.73.7]:25: 
subject_CN=mail.protection.outlook.com, issuer=DigiCert Cloud Services CA-1, 
cert 
fingerprint=E3:67:91:83:13:1F:AB:10:42:E7:93:D3:33:8A:6A:BC:87:7C:43:44:23:17:AE:5E:75:0F:7E:A3:41:66:40:65,
 pkey 
fingerprint=7B:8F:75:94:E0:08:F8:6E:32:5A:CE:17:27:09:B7:D2:23:08:20:42:1D:C1:DD:0A:B5:AF:F5:41:65:A3:ED:EB
posttls-finger: Verified TLS connection established to 
outlook-com.olc.protection.outlook.com[52.101.73.7]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

[ Of course with the matched hostname derived from an unsigned MX
  lookup, the security value of the certificate match is fairly modest.
  DANE is coming to Microsoft in 2024, and at least one (canary?) domain
  is already live.  Perhaps "outlook.com" will have working inbound
  DANE some time next year. ]

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

[Viktor Dukhovni]

On Fri, Oct 06, 2023 at 01:36:26PM -0700, Craig Leres wrote:

> > So long as you don't try to look up TLSA records, or insist on using
> > EDNS(0), even after a FORMERR response, you should be fine.
> 
> I've had edns0 in resolv.conf for a really long time but even if I comment
> that out I'm still unable to deliver mail. Also I get SERVFAIL or a timeout
> if I lookup outlook-com.olc.protection.outlook.com.

It is your resolv.conf's EDNS(0) setting that matters.  That's just
between your stub resolver library and your local "unbound" resolver.
What would matter is whether your **unbound** resolver is willing to
fall back from EDNS(0) to legacy DNS.

However, I was thinking of the "mail.protection.outlook.com" zone,
handling customer domains.  The nameservers handling Microsoft's
own "outlook.com" domain seem to handle EDNS(0) just fine:

  - protection.outlook.com. IN NS ns1-gtm.glbdns.o365filtering.com.
protection.outlook.com. IN NS ns2-gtm.glbdns.o365filtering.com.

  $ dig @ns2-gtm.glbdns.o365filtering.com -t a +ignore +norecur +nocmd 
+bufsize=1400 outlook-com.olc.protection.outlook.com.

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16548
;; flags: qr aa ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;outlook-com.olc.protection.outlook.com.IN A

;; ANSWER SECTION:
outlook-com.olc.protection.outlook.com. 30 IN A 104.47.11.225
outlook-com.olc.protection.outlook.com. 30 IN A 104.47.11.97

;; Query time: 76 msec
;; SERVER: 104.47.40.8#53(ns2-gtm.glbdns.o365filtering.com) (UDP)
;; WHEN: Sat Oct 07 02:04:43 EDT 2023
;; MSG SIZE  rcvd: 99

In contrast with, e.g., the nameservers for the "nist.gov" MX host:

  - mail.protection.outlook.com. IN NS ns1-proddns.glbdns.o365filtering.com.
mail.protection.outlook.com. IN NS ns2-proddns.glbdns.o365filtering.com.

  $ dig @ns2-proddns.glbdns.o365filtering.com. -t a +ignore +norecur +nocmd 
+bufsize=1400 nist-gov.mail.protection.outlook.com.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 20587
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;; Query time: 51 msec
;; SERVER: 104.47.68.17#53(ns2-proddns.glbdns.o365filtering.com.) (UDP)
;; WHEN: Sat Oct 07 02:09:06 EDT 2023
;; MSG SIZE  rcvd: 12

So whatever the problem is, it is perhaps not EDNS(0).  And specific to
your network.  DNSViz also gets adequate results:

https://dnsviz.net/d/outlook-com.olc.protection.outlook.com/ZSCCwA/dnssec/

-- 
Viktor.

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

Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues

[Viktor Dukhovni]

On Fri, Oct 06, 2023 at 11:08:39AM -0700, Craig Leres wrote:

> I routinely find messages stuck in my sendmail queue with the error,
> "Deferred: Name server: outlook-com.olc.protection.outlook.com". This system
> uses unbound (with DNSSEC validation enabled -- perhaps not relevant) and
> the only way I was able to get one message I really needed to deliver was to
> temporarily aim resolv.conf at the google public dns resolver.
> 
> outlook.com has a MX to outlook-com.olc.protection.outlook.com and the NS
> records for olc.protection.outlook.com are in o365filtering.com which has
> "issues":
> 
> https://dnsviz.net/d/o365filtering.com/dnssec/
> 
> An easy way to provoke this is to send a message to t...@outlook.com.
> 
> This has been broken for months and there are an impressive number of
> domains that use outlook.com for their mail...
> 
> Rather than go down the rabbit hole of trying to engage msn...@microsoft.com
> (which itself is broken for me) perhaps someone on this list can poke the
> right person at microsoft?

While the nameservers behind that domain have various unfortunate
limitations, they're minimally usable, and you should be able to
resolve the A/ records of the MX hosts with no issue.

What specific problems is your unbound running into.  I also use
"unbound" and do not run into substatial issues with that domain:

$ dig -t a outlook-com.olc.protection.outlook.com

; <<>> DiG 9.18.14 <<>> -t a outlook-com.olc.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63936
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1400
;; QUESTION SECTION:
;outlook-com.olc.protection.outlook.com.IN A

;; ANSWER SECTION:
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.73.0
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.11.6
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.8.37
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.11.5
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.73.27
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.42.12
outlook-com.olc.protection.outlook.com. 300 IN A 52.101.73.31

;; Query time: 119 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Oct 06 14:32:53 EDT 2023
;; MSG SIZE  rcvd: 179

So long as you don't try to look up TLSA records, or insist on using
EDNS(0), even after a FORMERR response, you should be fine.

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

Re: [dns-operations] DHL.com failures

[Viktor Dukhovni]

On Wed, Oct 04, 2023 at 04:46:42PM +0200, Martin Wismer wrote:

> we could get answer from all of the dhl.com NS RR TXT.  It's a big
> Answer, biger than 2200 Byte. May be they have rate-limit's on it.

That's not the issue.  The OP also reported that answers arrive when no
EDNS options are used (no NSID and no COOKIEs), but EDNS option
intolerance is EDNS-noncompliance.  Unsupported options must be simply
ignored, rather than cause the query to be dropped.

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

Re: [dns-operations] DHL.com failures

[Viktor Dukhovni]

On Wed, Oct 04, 2023 at 03:10:13PM +0200, Borja Marcos via dns-operations wrote:

> dhl.com/TXT: No response was received from the server over UDP (tried
> 7 times) until the NSID EDNS option was removed (however, this server
> appeared to respond legitimately to other queries with the NSID EDNS
> option present).

Also, the NS RRset at the ".COM" parent zone has only 3 of the six
nameservers listed at the child zone apex.  And the text RRset is rather
rich with "domain verification" tokens, perhaps at least some need not
be persisted after the initial verification?

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

Re: [dns-operations] DNS over TCP response fragmentation

[Viktor Dukhovni]

On Tue, Oct 03, 2023 at 02:10:50PM +0100, Ben Cox via dns-operations wrote:

> I would suspect this is caused by NO_DELAY being enabled (as it
> should) and some code writing out the dns response buffer in two
> parts. That server in the pcap appears to be running unbound 1.4.22:

I assume you mean to say "NO_DELAY *not* being enabled (as it should)".

Without "NO_DELAY", Nagle's algorithm may kick in, and subsequent
"short" writes may be delayed waiting for even more data, as reported.

So, certainly, a 2-byte initial response with a following delay is
entirely consistent with sloppy server code (not consolidating the
writes) and Nagle.

The one-byte writes are a bit more surprising, but perhaps this is how
some programmers handle network byte order, instead of using htons(3).

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

Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

[Viktor Dukhovni]

On Tue, Sep 19, 2023 at 11:00:34PM +0100, Joe Abley wrote:

> Apart from mail and some degree of debugging courtesy, what
> operational reasons exist to put effort into reverse DNS in 2023? Are
> there any? Or is the whole reverse tree just a weird anachronism?

Perhaps "apart from mail", it largely is.  Often unhelpful, and
sometimes trending on harmful (e.g. I've recently seen a few hundred PTR
records for a single address in an over 32kB DNS response).

The email ecosystem would benefit if a lot *fewer* addresses had PTR
records, ideally just those of MTAs.  With at least all the consumer
dynamic pool nodes unlisted, unless the customer has or obtains a static
IP and specifically requests a reverse mapping.

Reverse IPs for routers do make debugging easier, not only for
strangers, but also I would guess for the operators of said routers.
So PTR RRs in support of traceroute are also helpful, and are don't
get in the way of distinguishing MTAs from botnets.

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

Re: [dns-operations] cmdns.dev.dns-oarc.net down?

[Viktor Dukhovni]

On Mon, Sep 04, 2023 at 02:28:23PM -0400, Lee wrote:

> dig txt +short  o-o.myaddr.l.google.com
>   gives me the ipv6 address of the resolver

When the resolver happens to use IPv6.  The output is not by itself
IPv6-specific.

> dig txt +short  o-o.myaddr.l.google.com @ns{1,2,3,4}.google.com
>   gives me the ipv4 address

This query is not like the others, it directs the request to Google's
authoritative servers, so you learn your Internet-facing IP address for
reaching those servers, but this need not be how your DNS queries
normally reach those servers.

; <<>> DiG 9.18.14 <<>> -t txt o-o.myaddr.l.google.com @ns1.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42730
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
--->;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;o-o.myaddr.l.google.com.   IN  TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60 IN  TXT "192.0.2.1"

Which address family is used depends on local address preference
configuration.  On my FreeBSD server, IPv4 is preferred, because IPv6 is
only available via a GRE tunnel to Hurricane Electric.

$ cat /etc/ip6addrctl.conf
# Prefer IPv4
:::0.0.0.0/96100 4

# Prefer IPv6 loopback
::1/128   50 0

...

On another system with good IPv6 connectivity, that's what's used by
default in preference to IPv4.

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

Re: [dns-operations] CDS query issues (google issue?)

[Viktor Dukhovni]

On Mon, Aug 21, 2023 at 02:56:58PM +, Jacques Latour via dns-operations 
wrote:

> We're getting an error when doing this CDS query over TCP?  Just me?
> Seems like a Google bug?
> 
> $ dig ewmc.ca cds @ns-cloud-c4.googledomains.com. +tcp
> netmgr/tcpdns.c:302: fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS) 
> failed
> Aborted (core dumped)

A quick look at the current (BIND 9.18) code for netmgr/tcpdns.c shows
that all the assertions of the form:

RUNTIME_CHECK(result == ISC_R_SUCCESS)

are checking the success of basic socket API operations, and are
unrelated to the payload of DNS responses.  This was likly the case
also in the version of `dig` that ran into the failure.

atomic_store(>connecting, false);

result = isc_sockaddr_fromsockaddr(>peer, (struct sockaddr 
*));
RUNTIME_CHECK(result == ISC_R_SUCCESS);
--

/* 2 minute timeout */
result = isc__nm_socket_connectiontimeout(sock->fd, 120 * 1000);
RUNTIME_CHECK(result == ISC_R_SUCCESS);
--
uv_os_sock_t sock;

result = isc__nm_socket(sa_family, SOCK_STREAM, 0, );
RUNTIME_CHECK(result == ISC_R_SUCCESS);
--
/* FIXME: set mss */

result = isc__nm_socket_reuse(sock);
RUNTIME_CHECK(result == ISC_R_SUCCESS);

if (mgr->load_balance_sockets) {
result = isc__nm_socket_reuse_lb(sock);
RUNTIME_CHECK(result == ISC_R_SUCCESS);

Since you have a core dump, it may be possible to obtain a backtrace to
discern which operation failed.  Perhaps the system ran out of file
descriptors, or there's a per-user limit.

Is this by some chance part of a concurrent bulk scan for CDS records?
I wouldn't recommend `dig` as the tool for that task.

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

Re: [dns-operations] DNSSEC resolution failure for the "مصر" TLD (xn--wgbh1c)

[Viktor Dukhovni]

On Mon, Jul 24, 2023 at 09:13:30AM +, Manal Ismail wrote:

> We are in the middle of updating the records .. The update is
> currently pending one approval .. Once done, today, all problems will
> hopefully be fixed ..

Congratulations, looks much better now:

https://dnsviz.net/d/xn--wgbh1c/ZMG2OA/dnssec/

The only minor nit is that in addition to a SHA256 key hash DS RR your
DS RRset also includes a SHA-1 key hash DS RR.

$ dig +noidnout +noall +ans +nottl +nosplit -t ds xn--wgbh1c
xn--wgbh1c. IN DS 65350 13 2 
5ECE34228C4114FC455E07F4BB4B3DF8B501D874C4A4070ACBB378F41F17A0E5
xn--wgbh1c. IN DS 65350 13 1 746DD718F1BDAE3B4F2578767C4B47A039501641

Though additional SHA-1 DS records do not break anything, they also are
deprecated, no longer needed, and are best not published.  At your
convenience, I'd like to recommend pruning the DS RRset to just:

xn--wgbh1c. IN DS 65350 13 2 
5ECE34228C4114FC455E07F4BB4B3DF8B501D874C4A4070ACBB378F41F17A0E5

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

[dns-operations] FYI: Google Public DNS now reports EDEs

[Viktor Dukhovni]

Google Public DNS (also "dns.google", or, colloquially, "Quad8") now
includes EDEs in most error responses.  For details see:


https://developers.google.com/speed/public-dns/docs/troubleshooting/domains#edes

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

Re: [dns-operations] [DNSSEC] Venezuela ccTLD broken

[Viktor Dukhovni]

On Thu, Jul 20, 2023 at 07:25:17AM -0400, Hugo Salgado wrote:

> They are aware and working on this. Thanks!

The final working state is still somewhat suboptimal:

- The KSKs are 4096 bit RSA.  This is pointless, the DS RRset from
  the root is signed with a 2048-bit RSA key.  The additional bits
  are just packet size and computational bloat.

- The ZSK need not (and so in practice should not) also sign the DNSKEY
  RRset, just the KSK signatures are sufficient.

Finally, for the RSAC (yes not the right forum to formally lodge the
question), should the root zone DS TTL still be 1 day?  Would a change
to one hour be acceptable (aligning with it with the practice of many
TLDs and aiding in more time recovery from mistakes)?

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 18, 2023 at 10:25:01PM +0200, Ondřej Surý wrote:

> It’s exactly like the serve-stale. The inception of the protocol
> change is driven by this isolated incident. That’s not a proper
> design, that’s slapping more bandaids on the camel.

I don't even see a "protocol change" here.  A bogus (possibly forged)
answer arrived from server A, perhaps server B should be tried.

> There’s already mechanism for not serving a stale RRSIGs. The EXPIRE
> field in the SOA record should be set to a value that’s lower than the
> RRSIG resigning interval (the minimal interval between now and
> shortest RRSIG expiry in the zone).

We're not just talking about expired RRSIG as the sole use-case.  Some
servers have bugs, some primaries failed to implement AXFR atomically,
propagating the RRSet update sans RRSIG update (or the other way
around). Some mishandle ENTs, ...

> Currently, it’s 7 days for .com which almost exactly matches the RRSIG
> expiry-inception difference and that doesn’t give any wiggle room if
> things go wrong.

Expiry in the SOA applies to AXFR, but may deployments are not
AXFR-based.  And Verisign apparently did try to isolate the server,
sadly that didn't work out as expected.

> . - 7 days SOA expiry and 14 days signature validity
> .cz - 7 days SOA expiry and 14 days signature validity
> .nl - 28 days SOA expiry and 14 days signature validity
> .org - 14 days SOA expiry and 3 weeks signature validity

Do any of these use AXFR?  If all the servers are effectively "primary",
with incremental zone updates driven by some other process, the SOA
expiry is of little relevance.  Sure they should go offline before
signatures start to go stale (as Verisign tried to do, but failed).

The "go offline" logic should therefore be robust, but that's not
the topic at hand I think.  The topic is whether "bogus" should
generally be retriable (or even required to be retriable within
reasonable retry limits, and with error caching holddowns to
avoid thundering herd storms, ...).

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 18, 2023 at 12:51:39PM -0700, Gavin McCullagh wrote:

> We definitely saw Unbound returning SERVFAIL for unsigned com domains
> though.

Failures for even for some "unsigned" domains were to be expected if
retries were either not happening or the retry count was at times
exceeded.

The reason is of course that validation of denial of existence of the DS
RRset was failing, due to expired NSEC3 RRSIGs.  So as far as the
resolver was concerned the domain wasn't "veriably" unsigned.

With 4 out of 13 problem servers:

- 3 tries gives a 2.9% failure rate.
- 4 tries gives a 0.9% failure rate.

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 18, 2023 at 07:38:51PM +, Matt Nordhoff via dns-operations 
wrote:

> ³ Actually the xn--wgbh1c TLD is broken right now but I haven't told anyone.

Well, at least that IDN ccTLD (Egypt, "dotmasr") is broken for all
servers.

Nice to see a rollover in progress to algorithm 13, but of course the DS
RRset needs to include the new algorithm (13) before the RSA keys for
algorithm 8 can be dropped from the zone apex.

I am not aware of any signed delegations from that ccTLD, and have
scrounged up only ~30 unsigned delegations.

xn--izegabcba2adcq5gqc5b8l6afceemeyq8a4a9a.xn--wgbh1c. IN SOA 
ns.mcit.gov.eg. msot. 2021082543 900 600 86400 3600
xn--nzeabcaaa2adcq5gqc5b8l6afceemeyq8a0df.xn--wgbh1c. IN SOA 
ns.mcit.gov.eg. msot. 2021082566 1200 600 1209600 18000
xn-btdcaaatdcm7e1byb0nejqo0e.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082541 1200 600 1209600 18000
xnrmckbbajlc6dj7bxne2c.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082566 1200 600 1209600 18000
xnvmcebbajlc6dj7bxne2c.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082567 1200 600 1209600 18000
xnvmcebbatck5dvb7me6a.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082569 1200 600 1209600 18000
xnymcbaaajlc6dj7bxne2c.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082573 1200 600 1209600 18000
xnymcbaaatck5dvb7me6a.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082575 1200 600 1209600 18000
xn--igbajdnsj6exe2aeff.xn--wgbh1c. IN SOA junade.ns.cloudflare.com. 
d...@cloudflare.com. 2310655149 1 2400 604800 1800
xn--kgbdabaijc0di3b7me9b.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082547 900 600 86400 3600
xn--kgbdabaqcj9c7a4me4a.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 2021082548 
900 600 86400 3600
xn--mgb0a5b.xn--wgbh1c. IN SOA dara.ns.cloudflare.com. d...@cloudflare.com. 
2303194067 1 2400 604800 3600
xn--mgb1d.xn--wgbh1c. IN SOA ns1.parkingcrew.net. 
hostmas...@xn--mgb1d.xn--wgbh1c. 168971 28800 7200 604800 86400
xn--mgbijc0di3b7me9b.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 
2021082551 900 600 86400 3600
xn--mgbqcj9c7a4me4a.xn--wgbh1c. IN SOA ns.mcit.gov.eg. msot. 2021082551 
900 600 86400 3600
xn--mgbaebbvlfmds0sebc4d3ag.xn--wgbh1c. IN SOA ns8017.hostgator.com. 
r...@gator4009.hostgator.com. 2023051901 86400 7200 360 86400
xn--mgbbg4b5dfslw.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--mgbcd6dsca.xn--wgbh1c. IN SOA ns10.linkdatacenter.net. 
n...@linkdatacenter.net. 2022072511 86400 7200 360 86400
xn--mgbfg5gflobt.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--mgbg4a8ciipn.xn--wgbh1c. IN SOA usmsc2-extxfr-001.dns.apple.com. 
hostmas...@apple.com. 34 1800 900 2419200 1800
xn--mgbui1dh0a.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--mgbvbz7f.xn--wgbh1c. IN SOA isla.ns.cloudflare.com. 
d...@cloudflare.com. 2286884028 1 2400 604800 3600
xn--ngbd0a2dlb.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--ngbe4a8cepkt.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--ngbe9emjm.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--ngbnf2f1a.xn--wgbh1c. IN SOA pdns91.ultradns.com. doma...@redbull.com. 
2017012711 86400 86400 86400 86400
xn--ngbp3e.xn--wgbh1c. IN SOA ns1.tedata.net. hostmas...@tedata.net. 
2010062000 18000 3600 1209600 3601
xn--ngby7bdmjq.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023052001 86400 7200 360 86400
xn--pgb9c.xn--wgbh1c. IN SOA get.desec.io. g...@desec.io. 2021107296 86400 
3600 2419200 3600
xn--sgb0db.xn--wgbh1c. IN SOA cns289.hostgator.com. 
r...@cloud145.hostgator.com. 2023061801 86400 7200 360 86400
xn--ugbej3fk.xn--wgbh1c. IN SOA ns1.bluehost.com. 
r...@box2342.bluehost.com. 2023062300 86400 7200 360 300

Don't know whether any are popular/critical services.

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 18, 2023 at 08:54:04PM +0200, Ondřej Surý wrote:

> With my implementor’s hat on, I think this is wrong approach. It
> (again) adds a complexity to the resolvers and yet again based
> (mostly) on isolated incident. I really don’t want yet another
> “serve-stale” in the resolvers. I have to yet see an evidence that
> serve-stale has helped anything since the original incident, but now
> every resolver has to have it because people want it.

How is this akin to "serve stale"?  We're talking about retrying
response that fail to validate, just one might/would retry a response
that is "REFUSED", "SERVFAIL", has TC=1 over UDP, contains garbage, ...

The "serve stale" situation is quite different, here substantial new
logic is required, whereas with invalid responses, it is just a matter
of trying the next server up to some reasonable work limit.

Retries to reach a better authoritative server are core element of DNS
resilience in the face if inevitable partial degradation of service.

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Thu, Jul 13, 2023 at 12:16:37PM -0700, Gavin McCullagh wrote:

> When faced with ~4x obviously bogus, broken nameservers (the stale pop) and
> ~9x fresh working nameservers with valid signatures, the DNSSEC RFCs appear
> to specify (and Unbound appears to implement) that resolvers must accept
> and cache the obviously bogus (expired rrsig) answers and return SERVFAIL
> to clients until those bogus answers expire (apparently 24 hours later in
> this case?), rather than immediately considering those responses invalid,
> those nameservers as lame and retrying against another - assuming this
> response is either coming from an attacker or from a broken nameserver.

I don't believe that's a valid reading of the DNSSEC RFCs.  Bogus
answers are not cached by the resolver I'm working on these days, beyond
the usual query rate limits for failures.

And to the extend that a only some servers have stale data, I am also
working to make sure that we'll try go get a better answer from another
server.  Some resolvers already do.

> Obviously we need to be careful about creating retry storms, but that retry
> storm is pretty much equivalent to what would happen if that PoP were to
> return SERVFAIL or not respond, so that doesn't seem like a new problem.

Correct.  Within reasonable retry limit counts and error response
hold-downs, bad/stale/... data from a single server should not be final
whether it is DNSSEC-related or not.

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 11, 2023 at 10:51:47PM -0400, Viktor Dukhovni wrote:

> In .COM CZDS zone file snapshot of .COM from ~midnight UTC 2023-07-11
> the range of non-apex RRSIG inception times was:
> 
> 20230707025004 – 20230710225021
> 
> With corresponding expiration times:
> 
> 20230714040004 – 2023071821
> 
> With expiration of the oldest RRSIGS 3 days and 4 hours away, and the
> newest a full 7 days.

Apart from some records that are signed intra-day, the expiration times
of records in .COM are strongly clustered around once a day signing
events that cover roughly 25% of the zone.  For example, the CZDS
snapshot for the 11th has expiration times clustered near:

2023-07-14T04:00 ~3.4M RRsets
2023-07-15T04:00 ~3.4M RRsets
2023-07-16T04:00 ~3.4M RRsets
2023-07-17T04:00 ~3.4M RRsets

So the affected delegations would have been ~0%, ~25%, ~50%, ~75% or
~100% of the zone, depending on how many days the issue went unnoticed.

Finally, if, e.g., Verisign were to support an automated error reporting
channel for .COM/.NET, would it look like the current error reporting
draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/)?
Or would it have to be something different?

The monitoring agent would ideally be different at each server cluster
sharing a common code base and zone database.  (Salted with something
akin to an NSID).  So that the report identifies the problem instance.
Just knowing that some .COM delegations somewhere look expired, is not
nearly as useful as knowing exactly where.

Is it reasonable to include the error reporting channel signal with
every query response, or (law of large numbers) is it sufficient to
include it some small enough fraction of the time, to make it less
instusive, and yet frequent enough that a errors that happen often
enough will soon be noticed.

What other tweaks should error reporting include?  (Explicit transport
protocol hints? ...)

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 11, 2023 at 05:24:57PM -0700, Gavin McCullagh wrote:

> > Consequently, some users unlucky enough to have switched providers or
> > moved to new NS hosts at the same a provider after the site was cut off
> > from updates also observed some issues, whether or not DNSSEC happened
> > to be involved.
> 
> That is true of course, but the magnitude of this event was made much worse
> by dnssec.  The entire COM and NET zones being bogus (including the
> unsigned delegations) is very different to the few that saw record changes
> in the prior 1-2 days.

For most .COM RRsets the RRSIG lifetime is 7 days, 1 hour and 10
minutes:

com. IN RRSIG NS 8 1 172800 20230717042337 20230710031337 46551 com. 
[omitted]
verisign.com. IN RRSIG DS 8 2 86400 20230716041715 20230709030715 46551 
com. [omitted]

[ The one exception seems to be the zone apex DNSKEY with 15 days and
  minutes. ]

In .COM CZDS zone file snapshot of .COM from ~midnight UTC 2023-07-11
the range of non-apex RRSIG inception times was:

20230707025004 – 20230710225021

With corresponding expiration times:

20230714040004 – 2023071821

With expiration of the oldest RRSIGS 3 days and 4 hours away, and the
newest a full 7 days.

My impression is that not all the signatures had expired during the
incident, and, for example, the "validity" of insecure delegations in
the middle of an unexpired NSEC3 range was unaffected (leaving
potentially stale NS records, NXDOMAIN for newly registered domains, ...
as the residual issue).

Yes, likely the blast radius from the RRSIG expiration was higher than
from stale records, since much of the zone is quite static otherwise.
On the other hand, this way the issue was identified sooner... :-)

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

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Viktor Dukhovni]

On Tue, Jul 11, 2023 at 10:24:21PM +, Wessels, Duane wrote:

> Last week, during a migration of one of our DNS resolution sites in
> Singapore, from one provider to another, we unexpectedly lost
> management access and the ability to deliver changes and DNS updates
> to the site. Following our standard procedure, we disabled all transit
> links to the affected site. Unfortunately, a peering router remained
> active, which was not immediately obvious to our teams due to the lack
> of connectivity there.

Thanks for the PM details, much appreciated.

> Over the weekend, this caused an issue that may have affected the
> ability of some internet users in the region to reach some .com and
> .net domains, as DNSSEC signatures on the site began expiring. The
> issue was resolved by powering off the site’s peering router, causing
> the anycast route announcement to be withdrawn and traffic to be
> directed to other sites.

I should note that DNSSEC was not the only fallout from outdated zone
files.  Some delegations had stale NS records, for which the outdated
nameservers were already returning REFUSED (or outdated answers).

Consequently, some users unlucky enough to have switched providers or
moved to new NS hosts at the same a provider after the site was cut off
from updates also observed some issues, whether or not DNSSEC happened
to be involved.

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

Re: [dns-operations] Single label queries on Windows (11)

[Viktor Dukhovni]

On Sat, Jul 08, 2023 at 12:36:12PM -0700, David Conrad wrote:

> Instead, we recommended dig as (a) it provides all sorts of options
> that help with pretty much every form of diagnostic you can imagine
> and (b) it doesn’t try to “help”.  We obviously didn’t succeed and
> it’s far too late now (it was back then too).  Ah well…

I think you succeeded everywhere but on Windows.  In MacOS, /usr/bin/dig
is part of the base OS!  I haven't used "nslookup" in a couple of
decades or more.  We now also have "drill", "kdig", "delv", ... a wealth
of much better than "nslookup", I am guessing inspired by "dig",
alternatives.

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

Re: [dns-operations] Single label queries on Windows (11)

[Viktor Dukhovni]

On Fri, Jul 07, 2023 at 08:09:39PM +0200, Petr Menšík wrote:

> I have tested recently how Windows 11 behaves when resolving single 
> label queries.
>
> I have expected it might try to use LLMNR. But I did not expect it would 
> do so also when trying nslookup, a tool which should be DNS only tool.
> 
> I have tried:
> 
> nslookup -type=ns com 9.9.9.9

It is not too surprising if this is also subject to the default suffix
list of the network "connection", which initialises the resolution
context, and then just overrides the server.  Have you tried:

nslookup -type=ns com. 9.9.9.9

with an explicit trailing "."?


> Got NXDOMAIN. I were very suprised, learned that does not exist. Even 
> more suprising were fact, that it presented the result came from the 
> specified server.

But the result should have been for "com.."
What happens when you configure the network connection with a default
suffix of "."?

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

Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

[Viktor Dukhovni]

On Fri, Jun 23, 2023 at 07:42:47AM +1000, Mark Andrews wrote:

> There should be an insecure delegation for 127.in-addr.arpa. in the
> in-addr.arpa zone. IANA have instructions from the IETF to do this in
> RFC 6303.
> 
> There has been a ticket open for years with IANA to correct the
> missing insecure delegations. 

Any chance this issue could help to unblock progress on that front?
FWIW, an insecure delegation for the "127" zone makes sense to me.

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

Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

[Viktor Dukhovni]

On Thu, Jun 22, 2023 at 10:30:33AM -0400, Matthew Pounsett wrote:

> Have you tried contacting the IANA or the IAB?  Those are the two
> organizations responsible for the technical and administrative for
> that zone... and I note that neither of them are copied on your email.
> Directly reaching out to either or both of them may be more productive
> than posting to dns-operations.

Which of the below would you suggest?

SOA rname:ns...@iana.org
WHOIS Administrative: i...@iab.org
WHOIS Technical:  tld-cont...@iana.org

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

[dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

[Viktor Dukhovni]

The nameservers for in-addr.arpa are:

in-addr.arpa.   NS  a.in-addr-servers.arpa.
in-addr.arpa.   NS  b.in-addr-servers.arpa.
in-addr.arpa.   NS  c.in-addr-servers.arpa.
in-addr.arpa.   NS  d.in-addr-servers.arpa.
in-addr.arpa.   NS  e.in-addr-servers.arpa.
in-addr.arpa.   NS  f.in-addr-servers.arpa.

this is a signed zone, and denial of existence is mostly(!) accompanied
by the required NSEC records.  However, in the case of:

1.0.0.127.in-addr.arpa. IN PTR ?

the "A" server response is wrong, it leaks an internal empty zone for
"0.0.127.in-addr.arpa" for which there is no insecure delegation in
the parent zone, so the unsigned denial of existence is BOGUS.

While all the servers respond with an NXDOMAIN rcode, the authority
section from the "A" server contains only:

   0.0.127.in-addr.arpa.SOA localhost. root.localhost. 1 604800 
86400 2419200 604800

While from all the other servers:

  in-addr.arpa. SOA b.in-addr-servers.arpa. nstld.iana.org. 
2022091523 1800 900 604800 3600
  in-addr.arpa. RRSIG   SOA 8 2 3600 20230712183222 20230622021342 
48561 in-addr.arpa. [omitted]
  in-addr.arpa. NSEC1.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY
  in-addr.arpa. RRSIG   NSEC 8 2 3600 20230706072654 20230615102113 
48561 in-addr.arpa. [omitted]
  126.in-addr.arpa. NSEC128.in-addr.arpa. NS DS RRSIG NSEC
  126.in-addr.arpa. RRSIG   NSEC 8 3 3600 20230704100647 20230613061852 
48561 in-addr.arpa. [omitted]

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

Re: [dns-operations] service.gov.scot erroneous NXDOMAIN from "scot" auth servers

[Viktor Dukhovni]

On Tue, Jun 20, 2023 at 02:44:34PM +0200, Stephane Bortzmeyer wrote:
> On Tue, Jun 20, 2023 at 01:36:10PM +0200,
>  CORE DNS Support Team  wrote 
>  a message of 43 lines which said:
> 
> > since anycast9 is only responsible for scot and not for gov.scot, I
> > believe the desired answer is a delegation to the name servers of
> > gov.scot, and not, as you wrote, a "NODATA" response
> 
> No, Viktor is right, and a NODATA (the correct answer) is indeed what
> the servers return for other query types:

Well, a delegation is in some sense a NODATA response that happens to
have referral NS records (and no SOA) in the authority section.  So in
that sense both are correct, but a delegation is I think closer.

> % dig @anycast23.irondns.net. A service.gov.scot
> 
> ; <<>> DiG 9.18.12-1-Debian <<>> @anycast23.irondns.net. A service.gov.scot
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30666
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;service.gov.scot.IN  A
> 
> ;; AUTHORITY SECTION:
> gov.scot. 86400   IN  NS  ns0.ja.net.
> gov.scot. 86400   IN  NS  ns4.ja.net.
> gov.scot. 86400   IN  NS  ns2.ja.net.
> gov.scot. 86400   IN  NS  ns3.ja.net.

That's of course a delegation.

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

Re: [dns-operations] service.gov.scot erroneous NXDOMAIN from "scot" auth servers

[Viktor Dukhovni]

On Tue, Jun 20, 2023 at 01:36:10PM +0200, CORE DNS Support Team wrote:

> > The gov.scot zone is unsigned, with "service.gov.scot" as a subdomain,
> > but "DS" queries for "service.gov.scot" incorrectly elicit NXDOMAIN,
> > rather than NODATA responses from the "scot" auth servers.
> > 
> >  $ dig -t ds service.gov.scot @anycast9.irondns.net +norecur +nocmd 
> > +noall +nostats +comment +noedns
> >  ;; Got answer:
> >  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22729
> >  ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> The answer is indeed not correct. We will investigate the problem and
> fix it in the next days.

Thanks, that's great.

> However, since anycast9 is only responsible for scot and not for
> gov.scot, I believe the desired answer is a delegation to the name
> servers of gov.scot, and not, as you wrote, a "NODATA" response.

Yes, more precisely a delegation is the expected response, ultimately
(from gov.scot) the response will be NODATA (neither gov.scot, nor
service.gov.scot are signed).

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

[dns-operations] service.gov.scot erroneous NXDOMAIN from "scot" auth servers

[Viktor Dukhovni]

The gov.scot zone is unsigned, with "service.gov.scot" as a subdomain,
but "DS" queries for "service.gov.scot" incorrectly elicit NXDOMAIN,
rather than NODATA responses from the "scot" auth servers.

$ dig -t ds service.gov.scot @anycast9.irondns.net +norecur +nocmd +noall 
+nostats +comment +noedns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22729
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

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

[dns-operations] .GL (Greenland) 2LD DS denial of existence problems

[Viktor Dukhovni]

The .GL TLD returns bogus NXDOMAIN responses to DS queries for:

com.gl. IN DS ? ; NXDomain https://dnsviz.net/d/com.gl/ZJEMOQ/dnssec/
gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 3600
gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl.  [...]
s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]
BBTTMJM743SRPQ6J4KQDIUC73E3C1HOA.gl. IN NSEC3 1 1 10 504d114b 
BSHTF866A32E02RJ617EUE8CCP45A6V4 NS DS RRSIG
BBTTMJM743SRPQ6J4KQDIUC73E3C1HOA.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]
6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]

edu.gl. IN DS ? ; NXDomain https://dnsviz.net/d/edu.gl/ZJEKYw/dnssec/
gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 3600
gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]
O3DN0L28MEKMTHMNP658AQ4UUG4CDHTP.gl. IN NSEC3 1 1 10 504d114b 
OE6EUSIJCPGO9R8RG0RO7Q9TPS7L9A46 NS DS RRSIG
O3DN0L28MEKMTHMNP658AQ4UUG4CDHTP.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]
6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]

org.gl. IN DS ? ; NXDomain https://dnsviz.net/d/org.gl/ZJEMkg/dnssec/
gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 3600
gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN NSEC3 1 1 10 504d114b 
SAGKR73F41OMFFI8TDE1CGHOQM502SIH NS SOA RRSIG DNSKEY NSEC3PARAM
s2uojg57gtbj0m12ecau9csfd38ejndn.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]
EB30Q0MC6UJD3MIGICRL31Q4SNSIT4T7.gl. IN NSEC3 1 1 10 504d114b 
EE4KJQ89ME2PR0AOHKV4G9OACUF3367V NS DS RRSIG
EB30Q0MC6UJD3MIGICRL31Q4SNSIT4T7.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]
6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN NSEC3 1 1 10 504d114b 
742MB65DHD2D8BG0846S1RKRER2E8CUB NS DS RRSIG
6LJARAG1OKGTS55S0KMDAS442VDOTMTH.gl. IN RRSIG NSEC3 8 2 3600 2023070505 
2023061805 39306 gl. [...]

All three 2LDs exist, are delegated, have SOA records and child zones.

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

Re: [dns-operations] DNSSEC parameter BCP

[Viktor Dukhovni]

On Sun, Jun 18, 2023 at 06:12:27AM +, Geoff Huston wrote:

> >> The BCP algorithm is ECDSAP256SHA256(13).  This is both more secure and
> >> more compact than RSA.  It is in wide use:
> >> 
> >>https://stats.dnssec-tools.org/
> >>https://stats.dnssec-tools.org/#/?dnssec_param_tab=0
> >> 
> >> Today, out of 22,010,850 known signed zones, the number with algorithm
> >> 14 KSKs is 9,982,219 or just over 45%.

[ Apologies on the typo, that should also have been 13 not 14. ]
Some days later, the total signed with algorithm 13 has crossed 10
million.

> The last time I looked at the capabilities of validators in recursive 
> resolvers
> comparing levels of support for RSA and ECDSA P256 SHA256 was in November 2021
> (https://www.potaroo.net/ispcol/2021-11/ecdsa.html)

A more recent internal study shows negligible differences in validation
rates between RSA(8) and ECDSA (13), the expected/unexpected
success/failure rates are effectively the same.

Any validating resolver that supports only RSA would be unable to
validate 90 TLDs and ~45% of signed zones (10.04 million out of 22.45
million).

At this point there should be no concerns about support for ECDSA P-256.
If anything, given e.g. recent "crypto policies" in RedHat systems,
there are now potential problems with RSA validation for the remaining
pockets of zones signed with algorithms 5 and 7 (~20k and ~127k zones
respectively).

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

Re: [dns-operations] "off label" use of PTR records for fanout

[Viktor Dukhovni]

On Thu, Jun 15, 2023 at 01:05:50PM -0700, Fred Morris wrote:

> I'm using DNS to retrieve some distributed telemetry data from multiple
> servers. To facilitate this I have an FQDN which resolves to a set of
> PTR records. If there's a generally accepted better option, let me know.
> 
> If you just want to bike shed this fine, I invite you to email me
> directly as I think this is already tangential to the purpose of this list.

I see, this is then just a way to publish multiple names in one RRset.

There is nothing wrong with doing this.  Unlike CNAME RRs you don't get
any implicit indirection, the application has to make explicit
subsequent queries for each name, as it sees fit.

PTR records also have the advantage of being "old enough" to support
name compression, so the representation will be reasonably efficient
(will share common suffixes) in most cases.

myserverlist.example. IN PTR server1.example.
myserverlist.example. IN PTR server2.example.
...
myserverlist.example. IN PTR server19.example.

The main limitation is that RRset in its entirety has to ultimately fit
in a single DNS message, so you're typically "limited" to O(100) names,
with a list of ~10k names becoming impractical.

Of course there already exist more elaborate ways to list target servers
in the form of SRV, SVCB and HTTPS RRs, but if all you need is a name
list, and you don't expect generic support for such lists outside your
own application, then sure, PTR will do.

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

Re: [dns-operations] DNSSEC parameter BCP

[Viktor Dukhovni]

On Mon, Jun 12, 2023 at 10:41:12AM -0400, Viktor Dukhovni wrote:

> On Mon, Jun 12, 2023 at 10:37:22AM -0300, daniel majela wrote:
> 
> > What is the best algorithm for ksk and zsk?
> 
> The BCP algorithm is ECDSAP256SHA256(13).  This is both more secure and
> more compact than RSA.  It is in wide use:
> 
> https://stats.dnssec-tools.org/
> https://stats.dnssec-tools.org/#/?dnssec_param_tab=0
> 
> Today, out of 22,010,850 known signed zones, the number with algorithm
> 14 KSKs is 9,982,219 or just over 45%.
> 
> If you choose NSEC3, set the additional iteration count to 0, and avoid
> opt-out unless you're operating a particularly large (10M+ delegations)
> zone that is thinly signed.  An empty salt is also sensible.

I was reminded off-list that I neglected to recommend NSEC as the BCP
default choice for end-user zones.  Much simpler than NSEC3, and again
smaller response sizes.

In addition, best to optimise for "agility": keep your TTLs reasonably
short, rarely more than one hour, and ideally shorter.  That way, if
anything does go wrong, you should be able to recover faster.

You don't currently get to choose (through your registrar) the TTL of
the DS RRs in the parent zone, perhaps some day...  In the mean time,
many registry now default DS TTLs to 1 hour or less.  Some still have
DS TTLs as high as one day.

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

Re: [dns-operations] (no subject)

[Viktor Dukhovni]

On Mon, Jun 12, 2023 at 10:37:22AM -0300, daniel majela wrote:

> What is the best algorithm for ksk and zsk?

The BCP algorithm is ECDSAP256SHA256(13).  This is both more secure and
more compact than RSA.  It is in wide use:

https://stats.dnssec-tools.org/
https://stats.dnssec-tools.org/#/?dnssec_param_tab=0

Today, out of 22,010,850 known signed zones, the number with algorithm
14 KSKs is 9,982,219 or just over 45%.

If you choose NSEC3, set the additional iteration count to 0, and avoid
opt-out unless you're operating a particularly large (10M+ delegations)
zone that is thinly signed.  An empty salt is also sensible.

> Is there, after generating the ksk and zsk keys, automatic rollover of keys
> and automatic signature of zones from the point of view that technical
> interaction is no longer necessary for this?

BIND supports automatic zone resigning and also automatic ZSK rollovers.
IIRC BIND also supports KSK rollovers with IIRC prior KSK deactivation
gated on the publication of matching parent DS records for the new KSKs

Don't choose automatic transition based on just a timer, if the parent
DS is not ready stick with the old KSK indefinitely!

> An example:
> Zone example.com.br signed!
> Zonaone.example.com.br ( to sign this zone ) I need to copy something
> inside the zone because it is a daughter of the example.com.br zone.

I haven't looked into whether BIND automatically does the right thing
vis. DS records when it serves both sides of a zone cut.  Best to check
the documentation, but it would seem like something that *should be* taken
care of in a sufficiently recent release.

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

Re: [dns-operations] Route 53 Unexpected geo location behavior

[Viktor Dukhovni]

On Sat, Jun 10, 2023 at 05:52:27AM -0400, Dan McCombs via dns-operations wrote:

> > dig -b 64.227.108.32 +short +subnet=64.227.108.32/32 \
> >   @ns-1339.awsdns-39.org doitb-synthetic.atlassian.net

FWIW, though it seems to not matter with the server in question, note
that a scope prefix length of 32 is not recommended, a better choice
would be 24, mirroring the typical behaviour of ECS-enabled recursive
resolvers.

https://datatracker.ietf.org/doc/html/rfc7871#section-11.1

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

Re: [dns-operations] Enabling DNSSEC signing for pagerduty.com

[Viktor Dukhovni]

On Tue, Jun 06, 2023 at 11:00:29AM -0600, Andy Smith via dns-operations wrote:

> We (PagerDuty) are in the process of enabling DNSSEC signing across
> our domains, and today (June 6th) we’re planning to enable it for
> pagerduty.com and associated subdomains (e.g. eu.pagerduty.com). Given
> the potential impact and the large number of organizations using our
> services, we thought it would be a good idea to let people know it’s
> happening in case any problems occur. If you do see any issues, feel
> free to contact me directly or support via supp...@pagerduty.com.

According to DNSViz: 
sibling  glue is missing for ns-474.awsdns-59.com.  This is not
something pagerduty.com can do anything about (except pass it along to
AWS).  Since I am not much of a fan of sibling glue anyway, not a
problem really, but if there is IPv4 glue for an NS host it should
also have IPv6 glue if the auth  RR exists.

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

[Viktor Dukhovni]

On Sun, Jun 04, 2023 at 08:44:19AM +0100, Matthew Richardson via dns-operations 
wrote:

> Without wishing to ask a really stupid question, is there any reason
> why root-servers.net is not DNSSEC signed?
> 
> Would signing it provide any additional security?

For the glue records to be beneficially signed, two things would likely
have to happen:

- The current 13 names would probably have to become a single name with
  13 records, so that the combined A and  RRsets would incur just 2
  additional signatures, rather than 26 signatures (too many even after
  a potential rollover of the root zone KSK/ZSK to P-256).

- Resolvers would have to expect RRSIGs for additional records!

https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.1

   o  When placing a signed RRset in the Answer section, the name server
  MUST also place its RRSIG RRs in the Answer section.  The RRSIG
  RRs have a higher priority for inclusion than any other RRsets
  that may have to be included.  If space does not permit inclusion
  of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Authority section, the name
  server MUST also place its RRSIG RRs in the Authority section.
  The RRSIG RRs have a higher priority for inclusion than any other
  RRsets that may have to be included.  If space does not permit
  inclusion of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Additional section, the name
  server MUST also place its RRSIG RRs in the Additional section.
  If space does not permit inclusion of both the RRset and its
  associated RRSIG RRs, the name server MAY retain the RRset while
  dropping the RRSIG RRs.  If this happens, the name server MUST NOT
  set the TC bit solely because these RRSIG RRs didn't fit.

Note that while authoritative servers MUST (strive to) include RRSIGs also
in the additional section, if space does not permit, they can omit them
*without* setting TC=1.

The upshort is that presently resolvers need to be prepared to process
additional records sans RRSIGs, and, therefore, RRSIGs for additional
records don't add much security value, an attacker can always strip
them and the response is still valid.

Since glue A/ records go in the additional section, signing them
does not protect the resolver against (infra) cache poisoning.  Their
signatures could obviate later explicit DO=1 queries for the A/
records in question, but can't really help with priming unless resolvers
special-case the root zone after we've all learned that it will be
signed, and will return signed glue.

Only resolvers that promptly revalidate the A/ records via explicit
queries for each nameserver will benefit from signed root nameserver
IP RRsets.  And to make this more efficient, we'd want a single root
NS host:

a-m.root-zone. IN A ...
...
a-m.root-zone. IN RRSIG A ...
a-m.root-zone. IN  ...
...
a-m.root-zone. IN RRSIG  ...

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

Re: [dns-operations] Compact denial of existence (NODATA sentinel RRtype)

[Viktor Dukhovni]

> On 11 Apr 2023, at 9:57 am, Edward Lewis  wrote:
> 
> Sure, the cost of replacing NSEC and NSEC3 would be another resource record 
> type code roll
> (such as 5->8, RSA-SHA1 vs RSA-SHA1-NSEC3).  But a new on-the-fly denial of 
> existence might
> prove to be worth it in operations.

No such hefty investment is needed.  All that's required is to invert the 
sentinel
RRTYPE from signalling NXDOMAIN to signalling "NODATA", with just "RRSIG" and 
"NSEC"
in the type bit signalling NXDOMAIN.

The reason to use the sentinel RRTYPE for NODATA, is that this provides sensible
semantics for responses to:

nodata.example. IN  ?

This type can have a mandatory 0 length RDATA:

; The "" is cosmetic, no other payload is supported.
nodata.example. IN  ""
nodata.example. IN RRSIG  ...

This response is consistent with the (effectively NODATA) original response,
in that unmodified validating resolvers will find no issues with it, or
conflict with the original response.

On the other hand, promosing some sentinel RRTYPE with NXDOMAIN is problematic,
since there is no correct response to explicit query for that type.

That's all that's needed.  Resolvers that wish to remap "RRSIG NSEC" -> 
NXDOMAIN to upstream
clients that sent DO=0 can do so, or not.  Nothing breaks either way.

-- 
Viktor.


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

Re: [dns-operations] [DNSOP] bind fails to continue recursing on one specific query

[Viktor Dukhovni]

On Wed, Mar 29, 2023 at 08:57:51AM -0400, jmur...@pdknox.org wrote:

> * Viktor Dukhovni  [230328 00:05]:
> > The queries for "_.extglb.tn.gov. IN A ?" in your PCAP are a novelty to
> > me.  Are these some form of query minimisation, or some sort of sanity
> > check of the delegation?  Sadly, the "tn.gov" nameserver just drops
> > these without responding, so their failure could well contribute to the
> > problems you observe.
> 
> A little more info here. My informant was cagey, but I think I
> understand that they are providing a whitelist of extant domains and
> their upstream is using that to filter queries as a mitigation
> measure. "Scrubbing terabytes of malicious traffic" was mentioned. 
> 
> Having found this,
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3331
> 
> though I can't access the ticket mentioned, I was inspired to try
> finding the zone cuts on tn.gov using NS queries; none my queries were
> dropped as those with underscore labels were.

Dropping all queries for which the response would be NXDOMAIN is a
terrible idea.  They may have outsourced their DNS to a plausibly
well-meaning, but not obviously skilled operator.

> Take it with a grain of salt as I really have no idea what I'm doing,
> but if this is a common anti-ddos technique then maybe this goes on
> the NS side of the qname minimization balance.

If always dropping instead of NXDOMAIN were particularly common, we'd be
hearing about a lot more breakage, both from BIND users and from senders
doing DANE SMTP where dropping of queries for TLSA records that aren't
there leads to deferring and ultimately bouncing email.

This doesn't mean that one wants to deliberately "poke the bear", and
perhaps "NS" for the apex is more prudent than "A" for "_.", but
both are reasonably expected to work (as are _25._tcp., when
the  zone is DNSSEC signed, whether or not the TLSA RRs exist).

Out of 21.6 million DNSSEC-signed zones, only ~3k have TLSA denial of
existence issues, and the vast majority are NSEC chain issues, with
roughly six or so TLSA non-responders).

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

Re: [dns-operations] [DNSOP] bind fails to continue recursing on one specific query

[Viktor Dukhovni]

[ Redirecting to dns-operations, I don't believe this is an IETF dnsop WG topic 
]

On Mon, Mar 27, 2023 at 12:13:58PM -0400, jmur...@pdknox.org wrote:

> www.tn.gov.   CNAME   www.extglb.tn.gov.
> extglb.tn.gov.NS  sdcgtm02.tn.gov.
> extglb.tn.gov.NS  ndcgtm01.tn.gov.
> extglb.tn.gov.NS  ndcgtm02.tn.gov.
> extglb.tn.gov.NS  sdcgtm01.tn.gov.
> 7VIFF5QRM0PHTVOHKKJ31SMHH09RAE81.tn.gov. NSEC3 1 0 100 D317AC7ABABEF654 
> 7VP1VJA5RP6KBKTVVS2IP1FCA30S4GF4 NS

[Above trace trimmed to the essential records]

$ ldns-nsec3-hash -t 100 -s D317AC7ABABEF654 extglb.tn.gov.
7viff5qrm0phtvohkkj31smhh09rae81.

- Does BIND still support 100 NSEC3 iterations?

The returned NSEC3 record is a proof of insecure delegation of
extglb.tn.gov. Given also:

ndcgtm01.tn.gov. IN A 170.141.169.33
ndcgtm02.tn.gov. IN A 170.141.169.34
sdcgtm01.tn.gov. IN A 170.141.172.33
sdcgtm02.tn.gov. IN A 170.141.172.34

we can check the server @170.141.167.222 queried in your PCAP and the
above:

$ while read ip; do
dig +norecur +dnssec +nocmd +nostats @$ip -t a www.extglb.tn.gov.
  done <<-EOF
170.141.167.222
170.141.169.33
170.141.169.34
170.141.172.33
170.141.172.34
EOF

That first address returns what would be a lame delegation, if it were
believed to be the right server for the zone.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57075
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: f94662e4382b0701010064222094f3dcfcd52f692d24 (good)
;; QUESTION SECTION:
;www.extglb.tn.gov. IN  A

;; AUTHORITY SECTION:
extglb.tn.gov.  300 IN  NS  ndcgtm01.tn.gov.
extglb.tn.gov.  300 IN  NS  sdcgtm01.tn.gov.
extglb.tn.gov.  300 IN  NS  ndcgtm02.tn.gov.
extglb.tn.gov.  300 IN  NS  sdcgtm02.tn.gov.
7VIFF5QRM0PHTVOHKKJ31SMHH09RAE81.tn.gov. 600 IN NSEC3 1 0 100 
D317AC7ABABEF654 7VP1VJA5RP6KBKTVVS2IP1FCA30S4GF4 NS
7VIFF5QRM0PHTVOHKKJ31SMHH09RAE81.tn.gov. 600 IN RRSIG NSEC3 7 3 600 
20230416173711 20230317173148 16643 tn.gov. 
ZxWY7y+RLEifC89LyPAtq0TQIPFuH0mrSbSCb3K44IJfqIwM8z7BuKb/ 
aM7gtPmApI2zxw2XpKaN7AK+XtBXdHJ29IRJQgQTnatIc+v8rU/hws/g 
fW8C5uQkq0XOU/YAzUGjOmtNdnzSEQZVi9CCYSsw7AqhVlUYssvAMbXE M5I=

The queries for "_.extglb.tn.gov. IN A ?" in your PCAP are a novelty to
me.  Are these some form of query minimisation, or some sort of sanity
check of the delegation?  Sadly, the "tn.gov" nameserver just drops
these without responding, so their failure could well contribute to the
problems you observe.

The rest are fine, but your resolver never asks:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16420
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.extglb.tn.gov. IN  A

;; ANSWER SECTION:
www.extglb.tn.gov.  30  IN  A   170.141.221.177

--

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49212
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.extglb.tn.gov. IN  A

;; ANSWER SECTION:
www.extglb.tn.gov.  30  IN  A   170.141.165.146

--

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34806
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.extglb.tn.gov. IN  A

;; ANSWER SECTION:
www.extglb.tn.gov.  30  IN  A   170.141.165.146

--

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29916
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.extglb.tn.gov. IN  A

;; ANSWER SECTION:
www.extglb.tn.gov.  30  IN  A   170.141.221.177

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

Re: [dns-operations] Cloudflare TYPE65283

[Viktor Dukhovni]

On Mon, Mar 27, 2023 at 06:57:13PM -0600, Paul Ebersman wrote:

> viktor> Do the CPU and packet size reductions justify the additional
> viktor> protocol complexity?
> 
> As IPv6 slowly creeps up in usage amongst folks not well versed in PMTUD
> and such (particularly more and more smaller middleware/firewall vendors
> or crap consumer routers), I think keeping response packet size down
> wherever we can is prudent.

Perhaps, but until the mythical post-quantum DNSSEC is needed, online
signers will use ECDSA, for which denial of existence is already
sufficiently compact, even with 4 RRSIGs (SOA + 3 NSEC3).

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

Re: [dns-operations] Cloudflare TYPE65283

[Viktor Dukhovni]

On Tue, Mar 28, 2023 at 06:01:40AM +0900, Shumon Huque wrote:

> I've spoken to both NS1 and Route53, and both are amenable to adjusting
> their implementations to support the changes specified in
> draft-huque-dnsop-compact-lies. So, we hope that the end result will be
> that all known implementations of compact lies will support this common
> mechanism to distinguish NXDOMAIN vs ENT vs (other) NODATA.
> 
> If there are any other implementations of Compact Lies that folks are aware
> of, we should make them aware of this and bring them into the fold.

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling are compact lies?

The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would have resolvers responding
differently to queries with the DO bit set (tell them the truth) vs.
queries that don't request validated answers (unmask the lie).

The savings vs. actual by-the-book NSEC responses appear to be a 2x
reduction in the number of signatures to compute (the SOA RRSIG is
presumably easily cached) and a 1.5x reduction in the number of
signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC).

Do the CPU and packet size reductions justify the additional protocol
complexity?

-- 
Viktor.

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

Re: [dns-operations] Cloudflare TYPE65283

[Viktor Dukhovni]

On Mon, Mar 27, 2023 at 06:30:02PM +0200, Emmanuel Fusté wrote:

> > Do you have a list of operators that currently return just "RRSIG NSEC"
> > for ENTs?  Do you [know] what software they are running?
>
> I double check: route53/AWS currently return just "RRSIG NSEC"for ENTs.

Anyone else?

> Even worse, it seems that they infer answers to non edns or cleared DO 
> bit questions from a internal DNSSEC response even for non DNSSEC 
> enabled zone:

I am struggling to understand this, can you give an example?

> - they currently return NXDOMAIN for ENT on apparently non DNSSEC signed 
> zones.

The ENT handling at AWS has been known to be broken for some time.

https://twitter.com/VDukhovni/status/1443681398905360384
https://twitter.com/VDukhovni/status/1445236728269258753

> > The only other option is to introduce yet another sentinel that signals
> > that the node in question is an ENT, so that the bare "RRSIG NSEC"
> > combination is ultimately never used.
>
> Yes it was my conclusion too.

I am not entirely keen on yet another sentinel, but feel free to suggest it.
The draft is currently under discussion.

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

Re: [dns-operations] Cloudflare TYPE65283

[Viktor Dukhovni]

On Mon, Mar 27, 2023 at 04:28:30PM +0200, Emmanuel Fusté wrote:

> > definitely does not exist.  The issue I take it that the
> > sentinel-free:
> >
> >  nxdomain.example. IN NSEC \0.nxdomain.example. RRSIG NSEC
> >
> > which is an ENT per:
> >
> >  
> > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01#section-3.2
> >
> > may for some time be ambiguous while still used for NXDOMAIN by earlier
> > implementations.  For that, sure, we should encourage those
> > implementations to adopt whatever becomes the published protocol at
> > their earliest convenience (realistically a year or two based on prior
> > experience nagging operators to resolve compliance issues).
>
> Thank you Viktor.
> That confirm my understanding and my analysis in my answers to Petr.

Do you have a list of operators that currently return just "RRSIG NSEC"
for ENTs?  Do you what software they are running?

On the fly signing with compact denial of existence is a bleeding-edge
behaviour, and one might expect that the software in question is not
ossified and operators might be proactive.  So with a bit of luck any
ambiguity might be resolved before long.

The only other option is to introduce yet another sentinel that signals
that the node in question is an ENT, so that the bare "RRSIG NSEC"
combination is ultimately never used.

And, FWIW, the sentinel value will surely need to change (once a better
codepoint is assigned).  The current 0xff03 is in the private-use range.

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

Re: [dns-operations] Cloudflare TYPE65283

[Viktor Dukhovni]

On Mon, Mar 27, 2023 at 03:27:34PM +0200, Emmanuel Fusté wrote:

> If Cloudflare switch to this draft for the ENT case too, it will became 
> as worse as Route53 and only NS1 will give distinguishable real NXDOMAIN.
> Or ALL compact lies response implementer should switch to this new draft 
> and be known to have switched.
> 
> I am missing something? (truly possible :-) )

To clarify, it isn't the new 0xff03 sentinel RRTYPE that hinders
distinguishing NXDOMAIN from NODATA responses (once the codepoint is
recognised).  If you see:

nxdomain.example. IN NSEC \0.nxdomain.example. RRSIG NSEC TYPE65283

you know that "nxdomain.example." definitely does not exist.  The issue
I take it that the sentinel-free:

nxdomain.example. IN NSEC \0.nxdomain.example. RRSIG NSEC

which is an ENT per:


https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01#section-3.2

may for some time be ambiguous while still used for NXDOMAIN by earlier
implementations.  For that, sure, we should encourage those
implementations to adopt whatever becomes the published protocol at
their earliest convenience (realistically a year or two based on prior
experience nagging operators to resolve compliance issues).

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

Re: [dns-operations] Trying to reach out to dns.com

[Viktor Dukhovni]

On Wed, Mar 01, 2023 at 03:57:26PM +0100, Florian Streibelt wrote:

> I am trying to reach out to the DNS operators of dns.com as the email
> from the SOA yielded no response.

Try one of:

Email address: supp...@dns.com
Website: https://www.dns.com/contact-us/
Phone number: +1.800.336.4637

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

Re: [dns-operations] Looking for zones using white lies (RFC 4470)

[Viktor Dukhovni]

On Thu, Jan 26, 2023 at 08:33:21PM +0100, Stephane Bortzmeyer wrote:

> I'm looking for zones in the wild that are signed using the technique
> of white lies (RFC 4470).
> 
> [Not the black lies used by Cloudflare.]

Three sample zones:

herokudns.com. IN SOA dns1.p05.nsone.net. hostmaster.nsone.net. 1661188672 
600 900 1209600 10
herokudns.com. IN RRSIG SOA 13 2 60 20230128051202 20230126051202 44688 
herokudns.com. [...]
foobarbaz.herokudns.com. IN NSEC \000.foobarbaz.herokudns.com. RRSIG NSEC
foobarbaz.herokudns.com. IN RRSIG NSEC 13 3 10 20230128051202 
20230126051202 44688 herokudns.com. [...]

technohazard.io. IN SOA squid.technohazard.io. hostmas...@technohazard.io. 
2022081701 900 300 86400 1800
technohazard.io. IN RRSIG SOA 13 2 3600 20230202180551 20230125150551 19807 
technohazard.io. [...]
foobarbaz.technohazard.io. IN NSEC \000.foobarbaz.technohazard.io. A TYPE13 
TXT  TYPE29 TYPE37 TYPE44 RRSIG NSEC TLSA TYPE55 TYPE61 TYPE99
foobarbaz.technohazard.io. IN RRSIG NSEC 13 3 3600 20230204051400 
20230127021400 19807 technohazard.io. [...]

cfccualerts.com. IN SOA ns1.dnsbycomodo.net. admin.dns.com. 2021101281 
10800 864000 7200 7200
cfccualerts.com. IN RRSIG SOA 13 2 7200 20230129122400 20230109122400 39711 
cfccualerts.com. [...]
foobarbaz.*.cfccualerts.com. IN NSEC \000.foobarbaz.*.cfccualerts.com. 
RRSIG NSEC
foobarbaz.*.cfccualerts.com. IN RRSIG NSEC 13 4 3600 20230129122400 
20230109122400 39711 cfccualerts.com. [...]

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

Re: [dns-operations] DNSSEC transition

[Viktor Dukhovni]

On Fri, Jan 20, 2023 at 09:22:34PM -0300, Rubens Kuhl via dns-operations wrote:

> I am considering a DNSSEC transition in the following scenario:
> 
> - Org 1 operates both the parent domain, with a delegation-only
>   server, and the child domain, with a set of authoritative servers. A
>   zone cut is present. 
> - Org 2 operates only authoritative servers 
> - Child domain is currently signed by Org 1, with a DS record matching
>   DNSKEY and RRSIGs served by the authoritative servers.
> - Child domain is moving from the authoritative servers of Org 1 to
>   the authoritative servers of Org 2. Org 1 will keep running the parent
>   domain. 
> - Org 2 will now run the child domain, with no DNSSEC

What does "with no DNSSEC" mean?  Does it mean they can't serve an
already signed zone, in which the RRSIG expirations are far enough
in the future to outlive the DS TTL?  So long as the nameserver S/W
in question is capable of returning DNSSEC-signed responses, the
new operator does not actually need to introduce new keys or sign
the zone beyond the current lifetime of the extant RRSIGs.

> Simple way is to remove the DS from the parent, wait for the DS TTL to
> be over, and then change the delegation at the parent domain. But this
> makes the change to wait for that DS TTL. 

If the new operator's nameservers have no support for serving a
pre-signed zone, then I am not aware of any alternatives.  While the DS
RRset persists in remote caches it signals a signed delegation, and the
child domain has to be signed by a corresponding KSK.

> I wonder if there is a way to make this transition to happen faster
> from an outside POV, even if under the hood there is still work in
> progress during the DS TTL. Is there a way to tell "hey, DNSSEC is
> [no] longer available to this domain, and I can prove that with RRSIG
> record" that resolvers would trust?

No.

> Because other than that, the next option would be to act as a recursor
> querying the new name servers, and on the fly signing the responses. 

Why not just drop the DS now, and do the transfer *after* the DS expires
from caches?  While we're contemplating the question, the DS could
already be removed and aging out.

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

Re: [dns-operations] Resolvers seeing repeated bursts of identical queries

[Viktor Dukhovni]

On Mon, Jan 09, 2023 at 01:55:29PM +, Roy Arends wrote:

> I’ve often seen this behaviour.
> 
> One confirmed explanation was (but there may be more/other) that this
> is the result of a stateful firewall. While the rules are pushed,
> traffic through it is buffereduntil the last rule is pushed, after
> which the buffer is flushed to world, resulting in a barrage of
> queries from the resolver behind the firewall. It depends on the
> resolver what happens with the ID. Some will re-issue the query after
> no response, some re-issue with new ID. 

The repetition of the same DNS query ID and exclusively the same qname
somewhat argues against the firewall theory, because ~100 instances of
just retransmissions of the same query from a resolver seems unlikely,
especially within the time it takes a firewall to reload its ruleset.

Wild speculation: If not some sort of DoS attack, perhaps a stub
resolver or application bug or configuration issue?  For example, some
APIs have timeouts in μs rather than seconds, maybe some code is setting
exceedingly short lookup timeouts?  Still the retry *count* is rather
high.

> > - A burst often has 50 - 100 queries for the same name within a few
> > milliseconds.
> > - All the queries within one burst have the same DNS query ID (but
> > different IP id and source port number).
> > - The same client IP producing such bursts of identical queries also
> > sends regular queries (one query per name, DNS query IDs vary).

Multiple systems behind a shared NAT, just one of them is the problem
system?

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

Re: [dns-operations] DNS measurement traffic etiquette

[Viktor Dukhovni]

On Wed, Dec 21, 2022 at 06:27:29PM -0800, Andreas Ott wrote:

> What are my best options to find out who is behind all this traffic when it
> comes from anonymous sources?

Probably not worth your time, but you could ask the cloud provider abuse
teams to look into this for you.

> For how long should I expect this query traffic to continue?

For a long time.  FWIW, some Internet measurement operatios do use
reasonabl best-practices.  I drop all NXDOMAIN name from future
DNSSEC/DANE survey measurements.  The signed names within ~24 hours, and
the not signed names within ~7 days.  And where I have authoritative
data from a registry (e.g. via CZDS, and a handful of ccTLDs) that
removes the need for periodic checks of live, but not yet signed
domains.  I also don't look below the eTLD+1 zone apex.

The only problem area is that some domains "expire" from their
registrar/DNS operator (which starts returning REFUSED), but remain
listed in the parent ccTLD zone for months.  There's O(50k) (out of 20.5
million) names I'd love to definitively drop, but can't because the
parent zone is a bit of a roach motel.

Since you are actually returning NXDOMAIN and not REFUSED, it doesn't
take much effort to avoid repeatedly querying for these, but I guess the
incentives don't line up for some...

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

Re: [dns-operations] PTR Records for Broadband Network?

[Viktor Dukhovni]

On Wed, Nov 23, 2022 at 12:44:46PM +, Michele Neylon - Blacknight via 
dns-operations wrote:

> Many many moons ago we setup the PTR records for our network using a
> template that clearly flagged that the IPs were static and used for
> hosting.
> 
> Fast forward to 2022 and we now offer broadband to both businesses and
> consumers, but unfortunately some streaming services and others are
> blocking access. So our users have issues with Disney+, All4, Netflix
> and Ticketmaster to name but a few examples. One of the issues appears
> to be the PTR records.

You need to find out whether the streaming service filters are based on
reverse DNS, BGP AS number, or some third party service that classifies
IP sources (in which case tweaking DNS will make no difference).

Do you have your own AS number?  Is it the same for both the business
and consumer address blocks?  Does the WHOIS data for these clearly
distinguish between their uses?

I'd also consider becoming a customer of some of these streaming
services and then opening support tickets as a customer (rather than a
third party) when service is unavaible for your IP address.

I am sceptical that PTR records are the problem, but you could of course
experiment with an alternative PTR format (or no PTR records at all for
the consumer IPs) and see if it helps.

You could also volunteer the non-static consumer IP blocks to the
SpamHaus PBL, which might also help signal the use-case, provided
of course that direct-to-MX email from the consumer pools is not
a supported service.

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

[dns-operations] SOA-less (uncacheable) NODATA from `protection.outlook.com` nameservers

[Viktor Dukhovni]

The nameservers for both `protection.outlook.com` and 
`olc.protection.outlook.com` are:


ns[12]-gtm.glbdns.o365filtering.com

They return uncacheable NODATA responses with no SOA [RFC2308 Sec. 5].  Any
IPv6 client that asks for the  records of various "olc" hosts will
therefore elicit uncacheable answers:

$ ns=ns2-gtm.glbdns.o365filtering.com
$ qname=hotmail-com.olc.protection.outlook.com.
$ qtype=

$ dig +norecur +nocmd -t $qtype $qname @$ns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21255
;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hotmail-com.olc.protection.outlook.com.IN 

;; Query time: 14 msec
;; SERVER: 104.47.38.8#53(104.47.38.8)
;; WHEN: Fri Oct 21 14:32:47 EDT 2022
;; MSG SIZE  rcvd: 67

This seems suboptimal to me.  Is anyone at Microsoft in a position to append
addressing this (mis)behaviour to the list of future improvements?

Note that the host in question is the MX host for hotmail.com, for which 


queries would be quite common, given the billions of email messages a day
handled by hotmail.com and outlook.com (same symptoms).

--
Viktor.

[ Cross-posted on OARC Mattermost "Town Hall" forum ]
___
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

[Viktor Dukhovni]

On Wed, Oct 19, 2022 at 06:58:21AM +1100, Mark Andrews wrote:

> Not for DS  as it is part of the parent zone. 

But is not an "apex" DS query, the parent zone (if "igt" were delegated)
would surely be fiscal.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.

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

[Viktor Dukhovni]

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

In more detail:

$ dig +dnssec +nocrypto +nocl +nottl +nocmd @ns1.treasury.gov 
igt.fiscal.treasury.gov ds
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50116
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;igt.fiscal.treasury.gov. IN DS

;; AUTHORITY SECTION:
fiscal.treasury.gov.SOA ns1.treasury.gov. 
ecb-hosting.fiscal.treasury.gov. 149240 3600 900 1209600 900
fiscal.treasury.gov.RRSIG   SOA 7 3 900 20221023235856 20221016225856 
3908 treasury.gov. [omitted]
f4s09eu1581gb4kordo869r2hnia9mah.treasury.gov. NSEC3 1 0 1 46A5FF83352054F7 
F4S09EU1581GB4KORDO869R2HNIA9MAI NS RRSIG
f4s09eu1581gb4kordo869r2hnia9mah.treasury.gov. RRSIG NSEC3 7 3 900 
20221025185901 20221018175901 3908 treasury.gov. [omitted]

> Because there is a zone cut at fiscal.treasury.gov, the the signer
> should be fiscal.treasury.gov.

That is defintely not kosher, given the SOA, there should of course be
no "treasury.gov" signatures for fiscal.treasury.gov names, and the NSEC
records are on the wrong side of the delegation...

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

Given the conflicting signals, perhaps garbage in garbage out?

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

[Viktor Dukhovni]

On Tue, Oct 18, 2022 at 05:56:25PM +1100, Mark Andrews wrote:

> > However, resolvers generally don't send explicit DS queries.  Instead,
> > when the parent zone is signed, they set the DO bit and expect any
> > referrals to either include the signed DS records, or authenticated
> > denial of existence thereof.
> 
> What resolver doesn’t make DS queries?  BIND makes DS queries.  If you
> have reasonable testing insecure delegations (signed -> unsigned as well
> as signed -> signed (no DS)) from the same server should be part of your
> test suite.

Yes "generally" was the wrong word.  For one it seems that DNSViz is
not doing the right thing.  And I did observe problems problems via
CloudFlare yesterday, and guessed they were related.  Not able to
reproduce them just now.

By the way is the validation workflow used in BIND written up somewhere
as a separate document, or are the comments in the code the best way to
understand how BIND validates names below a trust anchor (finding either
a valid signature or an insecure delegation).

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

[Viktor Dukhovni]

On Tue, Oct 18, 2022 at 02:02:48AM -0400, Viktor Dukhovni wrote:

> However, resolvers generally don't send explicit DS queries.  Instead,
> when the parent zone is signed, they set the DO bit and expect any
> referrals to either include the signed DS records, or authenticated
> denial of existence thereof.

Perhaps "generally" is too strong, some do and some don't.  The
validator module in "libunbound" does in fact walk down the tree probing
for DS records:

...
[1666075678] libunbound[59247:0] info: prime trust anchor
[1666075678] libunbound[59247:0] info: generate keytag query _ta-4f66. NULL 
IN
[1666075678] libunbound[59247:0] info: resolving . DNSKEY IN
[1666075678] libunbound[59247:0] info: resolving _ta-4f66. NULL IN
[1666075678] libunbound[59247:0] info: response for . DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from <.> 2001:500:1::53#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validate keys with anchor(DS): 
sec_status_secure
[1666075678] libunbound[59247:0] info: Successfully primed trust anchor . 
DNSKEY IN
[1666075678] libunbound[59247:0] info: validated DS gov. DS IN
[1666075678] libunbound[59247:0] info: resolving gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: response for _ta-4f66. NULL IN
[1666075678] libunbound[59247:0] info: reply from <.> 199.9.14.201#53
[1666075678] libunbound[59247:0] info: query response was NXDOMAIN ANSWER
[1666075678] libunbound[59247:0] info: response for gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from  
2001:500:4431::2:30#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validated DNSKEY gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: validated DS treasury.gov. DS IN
[1666075678] libunbound[59247:0] info: resolving treasury.gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: response for treasury.gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from  
2610:108:3100:100a::20:53#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validated DNSKEY treasury.gov. 
DNSKEY IN
[1666075678] libunbound[59247:0] info: resolving fiscal.treasury.gov. DS IN
[1666075678] libunbound[59247:0] info: response for fiscal.treasury.gov. DS 
IN
[1666075678] libunbound[59247:0] info: reply from  
2610:108:3100:100a::20:53#53
[1666075678] libunbound[59247:0] info: query response was nodata ANSWER
[1666075678] libunbound[59247:0] info: NSEC3s for the referral proved no DS.
[1666075678] libunbound[59247:0] info: Verified that unsigned response is 
INSECURE
qa.ws.igt.fiscal.treasury.gov has address 199.169.199.63

While CloudFlare 1.1.1.1 sometimes fails to resolve the same name:

$ dig -t a @1.1.1.1 qa.ws.igt.fiscal.treasury.gov

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35710
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 34 37 6d 37 39 ("447m79")
; EDE: 12 (NSEC Missing): (failed to verify an insecure referral proof for 
fiscal.treasury.gov.)
;; QUESTION SECTION:
;qa.ws.igt.fiscal.treasury.gov. IN  A

and sometimes (different anycast location and cache content) succeeds:

$ dig -t a @1.1.1.1 qa.ws.igt.fiscal.treasury.gov

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46190
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 33 38 36 6d 31 32 37 ("386m127")
;; QUESTION SECTION:
;qa.ws.igt.fiscal.treasury.gov. IN  A

;; ANSWER SECTION:
qa.ws.igt.fiscal.treasury.gov. 30 INA   199.169.199.63

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

[Viktor Dukhovni]

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.

> What it looks like to me is that everything [below] fiscal.treasury.gov is 
> supposed to be insecure (unsigned). There is a zone cut at 
> fiscal.treasury.gov, but it is not properly delegated in DNSSEC. The 
> servers are signing above the cut with the treasury.gov ZSK, but there 
> are no DS records in the parent or the DNSKEY records in the 
> fiscal.treasury.gov apex. Thus, the responses are seen as BOGUS.

Close, but not quite.  Explicit DS queries to the parent in fact
elicit a valid denial of existence:

$ dig +dnssec -t ds fiscal.treasury.gov @ns1.treasury.gov +norecur +nocl 
+nottl +noall +nocrypto +question +ans +auth
;fiscal.treasury.gov.   IN DS
treasury.gov.   SOA ns1.treasury.gov. 
ecb-hosting.fiscal.treasury.gov. 2001180551 3600 900 1209600 900
treasury.gov.   RRSIG   SOA 7 2 900 20221022031023 20221015021023 
3908 treasury.gov. [omitted]
4u954er66u6qum644o2088ircof2kt1g.treasury.gov. NSEC3 1 0 1 DADE5BC724805E45 
4U954ER66U6QUM644O2088IRCOF2KT1H NS RRSIG
4u954er66u6qum644o2088ircof2kt1g.treasury.gov. RRSIG NSEC3 7 3 900 
20221025022736 20221018012736 3908 treasury.gov. [omitted]

$ ldns-nsec3-hash -s DADE5BC724805E45 -t 1 fiscal.treasury.gov
4u954er66u6qum644o2088ircof2kt1g.

However, resolvers generally don't send explicit DS queries.  Instead,
when the parent zone is signed, they set the DO bit and expect any
referrals to either include the signed DS records, or authenticated
denial of existence thereof.

Here however, the auth nameserver has no way to know that you're
expecting signed parent-side delegation answers, and answers
authoritatively from the child perspective.  Such answers lack the
requisite signatures.

> Now if our servers saw it as completely broken, I'd understand. But 
> names above fiscal.treasury.gov sometimes work. Sometimes they don't. 
> That's what's really confusing me.

Rather depends whether the denial of existence of DS records manages to
make it into the resolver cache (via an explicit DS query perhaps).

This looks like a poorly understood corner case, serving a DNSSEC-signed
zone and its child from the same server can work poorly, becase either
no or the wrong signatures may accompany query replies.

The delegation NS records are not visible, and the DS records can only
be discovered via explicit DS queries.  And when queries for an interior
node or for other zone apex RRtypes are received, answers from the child
perspective are all the more natural.

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

Re: [dns-operations] ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

[Viktor Dukhovni]

On Tue, Sep 27, 2022 at 09:45:26PM +0200, Stephane Bortzmeyer wrote:

> This specific problem disappeared but there are other funny things in
> the zone. For instance, the three authoritative name servers for .bs
> claim that com.bs has three name servers, but they are the same.
> 
> % dig @anyns.dns.bs. SOA com.bs  
> 
> ; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @anyns.dns.bs. SOA com.bs
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32202
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ; COOKIE: b6dd75980a42dca4e88a412663335275aec889b7585d3e59 (good)
> ;; QUESTION SECTION:
> ;com.bs.  IN SOA
> 
> ;; AUTHORITY SECTION:
> COM.bs.   21600 IN NS anyns.dns.bs.
> COM.bs.   21600 IN NS ns36.cdns.net.
> COM.bs.   21600 IN NS anyns.pch.net.

More precisely, this is a lame-delegation.  The authoritative
nameservers of "com.bs" are replying to an SOA query for com.bs with a
referral to themselves.  Fortunately, this seems to only affect the
zone apex, queries for delegated subdomains are answered correctly:

$ dig +norecur +nocmd +nocl +nottl @ns36.cdns.net -t ns mckinney.com.bs
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56722
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mckinney.com.bs.   IN NS

;; AUTHORITY SECTION:
mckinney.com.bs.NS  ns.sworth.net.
mckinney.com.bs.NS  ns1.sworth.net.
mckinney.com.bs.NS  ns2.sworth.net.
mckinney.com.bs.NS  ns3.sworth.net.

;; Query time: 146 msec
;; SERVER: 2001:678:4::24#53(2001:678:4::24)
;; WHEN: Tue Sep 27 20:00:24 UTC 2022
;; MSG SIZE  rcvd: 155

But this is still an odd configuration.  There are NS records, for
".com.bs" in the parent pointing to its own nameservers, but no
zone cut, ...  This is wrong.

To ensure that ".com.bs" is not an empty-non-terminal, Instead of "NS",
the parent should have added "TXT", or "RP" records...

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

Re: [dns-operations] Why did .KE go insecure? ns36.cdns.net

[Viktor Dukhovni]

On Fri, Sep 23, 2022 at 07:48:50PM +0200, Bill Woodcock wrote:

> > On Sep 23, 2022, at 7:27 PM, Jacques Latour  wrote:
> > Just looking quickly, if you look back in dnsviz on Sept 15, I think a KSK 
> > roll over didn't go as plan...
> 
> That was not the root cause.  I’m sure they’ll discuss it when they’re ready 
> to.

I concur.  There were no observed DNSSEC issues, such as a problem
rollover, ...  The DS records were withdrawn cleanly, with the RRSIGs
still in place long enough to not cause any issues.

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

[dns-operations] ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

[Viktor Dukhovni]

The .COM.BS is an empty non-terminal with various child domains
registered beneath.  The "ns36.cdns.net" nameserver for .BS responds
with NXDOMAIN to "com.bs" qname-minimised queries.

This in turn can and does sometimes lead to NXDOMAIN inference for the
child domains.

This nameserver needs to be withdrawn and fixed before it is returned to
service.

2001:678:4::24ns36.cdns.net
194.0.1.36ns36.cdns.net

Example responses:

@194.0.1.36

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3297
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com.bs.IN SOA

;; AUTHORITY SECTION:
bs. SOA dns.nic.bs. bsadmin.cob.edu.bs. 2022092000 
3600 900 1814400 9000

@2001:678:4::24

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39616
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com.bs.IN SOA

;; AUTHORITY SECTION:
bs. SOA dns.nic.bs. bsadmin.cob.edu.bs. 2022092000 
3600 900 1814400 9000

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

[dns-operations] Broken black lies implementation at ns{1..4}.sectigoweb.com (a.k.a. ns{1..4}.dnsimple.com)

[Viktor Dukhovni]

The nameservers in question attempt to deny the existence of TLSA
records at "_25._tcp.mx2.beheerd.nl" with a "black lies" response
whose type bitmap includes "CNAME", but in that case the correct
response would be to return the CNAME, and the NODATA response is
bogus:

$ dig +nsid +nocmd +nocl +nottl +dnssec +norecur +nosplit +nocrypt -t tlsa 
_25._tcp.mx2.beheerd.nl @ns1.sectigoweb.com.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39716
;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; NSID: 34 34 35 6d 31 32 35 ("445m125")
;; QUESTION SECTION:
;_25._tcp.mx2.beheerd.nl. IN TLSA

;; AUTHORITY SECTION:
beheerd.nl.  SOAns1.sectigoweb.com. admin.sectigo.com. 
1647435746 86400 7200 604800 300
_25._tcp.mx2.beheerd.nl. NSEC   \000._25._tcp.mx2.beheerd.nl. CNAME RRSIG 
NSEC
beheerd.nl.  RRSIG  SOA 8 2 3600 2022112715 2022082915 
15885 beheerd.nl. [omitted]
_25._tcp.mx2.beheerd.nl. RRSIG  NSEC 8 5 300 2022112715 2022082915 
15885 beheerd.nl. [omitted]

;; Query time: 13 msec
;; SERVER: 2400:cb00:2049:1::a29f:1804#53(2400:cb00:2049:1::a29f:1804)
;; WHEN: Sat Sep 17 22:54:03 UTC 2022
;; MSG SIZE  rcvd: 518

This MX host handles at least 25 domains, which may have issues
receiving mail from DANE-enabled sending MTAs.

Some resolver behaviours:

- Forwarding the query to 8.8.8.8 correctly elicits SERVFAIL.

- Forwarding the query to 1.1.1.1 wrongly (bug reported to
  CloudFlare 2022-08-12) incorrectly stutters the NODATA.

- DNSViz.net also (again reported to @caseyd) presently fails to tag
  this as an error.

Does anyone know a contact at dnsimple.com who might investigate and
ultimately resolve the problem?

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

Re: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net"

[Viktor Dukhovni]

On Tue, Aug 30, 2022 at 07:42:30PM +0200, Anand Buddhdev wrote:
> On 30/08/2022 18:42, Randy Bush wrote:
> 
> Hi Randy, Viktor,
> 
> > another day of no response from afrinic, and i guess i should ask the
> > iana to remove them from the NS RRset for GN and LR.
> > 
> > anyone have a way to get afrinic dns folk's attention?
> 
> Try the address dns-mast...@afrinic.net. This is the address I use when 
> I need to ask for configuration changes or alert them about problems.

I forwarded Randy's message to d...@anfrinic.net and got an auto-reply
with the subject tagged with "[DNS #825742]" as the ticket number, and a
"Reply-To" dns-master.  So with a bit of luck that'll match your
suggestion.

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

Re: [dns-operations] .in ccTLD 2-level public suffixes

[Viktor Dukhovni]

On Sat, Aug 27, 2022 at 04:00:01PM -0400, John Levine wrote:

> It appears that Viktor Dukhovni  said:
> >But also some that appear to just mirror other ccTLDs without an obvious
> >connection to a category of child domains (com, edu, gov, net, org, ...):
> >
> >ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in
> >
> >What are these for?  I'm afraid  these may create or add to user confusion.
> 
> The registry web site says since 2005 they've been available for
> anyone to register anything. The 2LDs that limit who can register are
> ac.in res.in edu.in gov.in mil.in.
> 
> https://registry.in/policies

Thanks, that confirms and details their availability as public suffixes.

These suffixes were specifically provisioned (and are not themselves
delegated, they are included directly in the .in zone) by the .IN ccTLD,
and I am curious whether the intent was specifically to "mirror"
similarly named ccTLDs (and if so, why), or whether perhaps these
2-letter abbreviations have some other significance in India...

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

[dns-operations] .in ccTLD 2-level public suffixes

[Viktor Dukhovni]

> Nearly all of the TLDs have second level suffixes (like gov.in, co.in
> and various others) which are used as special names, and zones are
> further delegated from these suffixes.

Speaking of ccTLD second level public suffixes, for .in I've just
noticed not only some "expected" suffixes like:

ac.in biz.in co.in com.in edu.in firm.in gen.in gov.in ind.in
info.in net.in nic.in org.in res.in web.in

But also some that appear to just mirror other ccTLDs without an obvious
connection to a category of child domains (com, edu, gov, net, org, ...):

ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in

What are these for?  I'm afraid  these may create or add to user confusion.

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

Re: [dns-operations] Browser Public suffixes list

[Viktor Dukhovni]

On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:

> this...
> 
> Meir Kraushar via dns-operations wrote on 2022-08-27 02:56:
> > 2) The need to maintain a list dedicated to browser issues is out of our 
> > scope. I'm sure there are good reasons to have it, like you said, there 
> > is gap between the worlds.
> 
> ...is why the IETF DBOUND (domain boundaries) working group was 
> originally formed, and why efforts are underway to resuscitate it.
> 
> see: https://www.ietf.org/mailman/listinfo/dbound

Another aspect of the problem, is that the browsers unified the address
bar and the search bar in order to "improve" (make simpler than
possible) the browser user interface.  This creates a fundamental
ambiguity about user intent.  Did the user type a URL sans scheme prefix
or a search term?  Using the PSL to "disambiguate" is a hack.

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

Re: [dns-operations] Browser Public suffixes list

[Viktor Dukhovni]

On Sat, Aug 27, 2022 at 03:17:18AM +0300, Meir Kraushar wrote:

> You also suggested to not opt-out?  What would be the reason for that?

Attackers can no longer fabricate the existence or non-existence of
unsigned delegations whose hashes fall between those of the signed ones.

Of course all answers under an unsigned delegation are still subject to
some tampering.

Most of the value of avoiding opt-out is obtained in "leaf" zones with
no delegations.  A delegation-mostly zone (such as a TLD) benefits less,
but unless you're operating something as large as .COM, there's little
reason to bother with opt-out.

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

Re: [dns-operations] Browser Public suffixes list

[Viktor Dukhovni]

On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote:

> Yes the problem is that browsers not aware of a TLD, in this case SAFARI
> unaware of xn--4dbrk0ce,  do not treat it as a domain.  It won't resolve
> the given name and go to the address. Instead, it will pass the value to
> the search engine. This is bad. Most certainly not the desired behavior
> when launching a new domain.

That's rather odd.  How old is the Safari release you're testing?  The
TLD is no longer "brand new": DNSSEC/DANE survey data for the TLD shows
a go-live date in Mar 2021, with DNSSEC signing in May of this year.

qname | dnssec |date
--++
 xn--4dbrk0ce | f  | 2021-03-18
 xn--4dbrk0ce | t  | 2022-05-13

If Safari has a built-in list of TLDs, it'd have to have been "baked in"
at least ~1.5 years ago.

Speaking of DNSSEC, I see you're using NSEC3 with opt-out and 5
iterations.  Please consider 0 iterations, *no* opt-out and possibly
empty salt.  See:

https://www.rfc-editor.org/rfc/rfc9276.html

Indeed when trying: xn--5dbedt4e.xn--4dbrk0ce, also recent Firefox and
Chrome suggest a search rather than treating it (בדיקה.ישראל) as a
domain first.

It seems that PSL aside (cookie scope management), the browsers have
additional rules about which punycode strings they accept as domain
names.

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

Re: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Mon, Aug 22, 2022 at 04:18:36PM +0200, Haya Shulman wrote:

> [ Further ad-hominem off-topic to this list removed ]

Please refrain from further efforts in that direction.

> in our project we evaluated two ways to downgrade DNSSEC, by disabling
> validation and by downgrading to a weaker cryptographic algorithm.

There is little evidence for, and much current practice to dispel, the
idea that DNSSEC is intended to ensure that the "strongest" mutually
supported algorithm will be used by validators of multi-algorithm signed
zones.  Failure to ensure that the strongest algorithm is used for
validation is not a bug.  Zone signers should not use weak algorithms
(nor weak parameters, e.g. 512-bit RSA keys) for signing.  If a zone is
signed with weak crypto, it is potentially vulnerable to cryptographic
attacks (more so in the case of DNSSEC from weak parameters than "weak"
algorithms).

> The different vulnerabilities are caused by an attempt to allow
> replacing and adding new algorithms.

No, the reported vulnerability is caused primarily by implementation
bugs and only secondarily by insufficiently prescriptive language about
the responsibilities of the validating resolver that left some of the
requirements implicit.

> Analysis of the different problems leads to one root cause: the
> current algorithm agility in DNSSEC is what allows our attacks.

DNSSEC algorithm agility is a success, and has supported multiple
transitions:

.  RSA with MD5 originally
-> RSA with SHA1 (5)
-> RSA with SHA1 and NSEC3 (7)
-> more recently, RSA with SHA256 (8) or ECDSA P256 (13)
... in a few years time ...
-> EdDSA 25519 (15)

DNSSEC allows the validator to employ a mutually supported algorithm to
validate the signed zone, and, when implemented correctly, does so
without downgrade opportunities to "Insecure".  Bug reports on
implementations that fail to avoid downgrade to "Insecure" are always
appreciated (my thanks to Nils for one such report).

> [RFC7696] says "Algorithm agility is achieved when a protocol
> can easily migrate from one algorithm suite to another more desirable
> one, over time." - The ability to migrate from one algorithm suite to
> another in the current implementations is what exposes DNSSEC to our
> attacks.

This is not correct, as evidenced by implementations that are not
vulnerable to the reported downgrades to "Insecure".  "Downgrades" to
the weaker of two signing algorithms are a "feature not a bug".

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

Re: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Mon, Aug 15, 2022 at 07:43:42AM +, 
jean-pierre.seif...@external.telekom.de wrote:

> I would like to correct the claims of Peter Thomassen. 

[ No factual corrections followed, just ad-hominem. ]

> So, please take what Peter writes with a grain of Salt.

I don't believe such "corrections" (that look largely like mere attempts
to discredit) are on-topic for this list.

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

Re: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Sat, Aug 13, 2022 at 03:07:22PM -0400, Peter Thomassen wrote:

> On 8/11/22 17:56, Phillip Hallam-Baker wrote:
> > NSEC record specifies what is signed but not the algorithm used to
> > sign. DNSSEC allows multiple signature and digest algorithms on the
> > same zone. If a zone does this, validators are prohibited from
> > rejecting records only signed using one of the algorithms rather
> > than both.
> > ...
> > 
> > This definitely needs fixing.
> 
> I agree that the specs should more clearly say that when a validating
> resolver sees a (supported?) algorithm in DS without seeing
> corresponding RRSIG authenticated via such DS record, the response
> MUST be bogus.

I am generally in favour of specifications being somewhat more explicit
even on "obvious" details than is at times common in IETF RFCs.
Implementors are sometimes busy, and the even the obvious may be
overlooked.

> Apart from that: What else needs fixing? (You mentioned something with NSEC.)

The NSEC throw-away in the slides looks spurious to me.  Sure NSEC
records don't specify which RRSIG signature algorithms accompany the
RRsets listed in the type bitmap, but this is not a compelling addition.
NSEC records only accompany denial of existence, normal responses don't
carry NSEC records.  The DS and DNSKEY RRs provide all the needed
information, the rest merely requires an implementation that avoids
unnecessary downgrade issues.

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

Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 07:31:04PM -0700, Phillip Hallam-Baker wrote:

> Looks like the 'downgrade attack' is actually a consequence of the fact
> that support for multiple algorithms means that you end up with the
> security of the weakest. So not really an 'attack' but a consequence of the
> design approach not considering the downgrade issue worth addressing
> because people should not be signing under multiple algorithms for very
> long.

No, the downgrade in question is not from a stronger algoritm to a
weaker (generally accepted, because multi-algorithm signed zones are a
short-term affair), rather, it is a downgrade from "signed" to
"unsigned", which is a serious implementation error.  The paper's
authors did not break any crypto, they just sent replies that some
implementers failed to anticipate (for plausible lack of clear explicit,
however obvious it should have been, advice in RFC 4035).

> But given that, I think we are long past the time when anyone is doing
> anything of the slightest value signing with SHA-1. There is no reason to
> pick SHA-1 over SHA-2. You are not going to improve interop, you are much
> more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to
> go.

Again, SHA-1 has nothing to do with this.  It is already NOT RECOMMENDED
(i.e. SHOULD NOT) for signing:

https://stats.dnssec-tools.org/explore/?ietf.org
https://www.rfc-editor.org/rfc/rfc8624#section-3

but still a MUST for validation.  The numbers have improved a lot since
the RFC was published, see the algorithm counts under "DNSSEC parameter
frequency analysis" at:

https://stats.dnssec-tools.org/

but we're not quite there yet:

https://stats.dnssec-tools.org/explore/?nsa.gov
https://stats.dnssec-tools.org/explore/?icann.org
...

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

Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote:

> So say a zone is signed by the zone owner with both BK and a strong
> algorithm denoted STRONG. As long as a resolver only trusts STRONG
> signatures I don't see how the status of what NSECs say is signed can cause
> forged data to be trusted.

The issue is arguable lack of clarity in the validator requirements of
4035 when the server returns only RRSIGs with algorithms none of which
are supported by the validator.

When only unsupported algorithms appear in DS, the zone is "insecure"
and all's well.  But otherwise, when only unsupported algorithms (or
none at all) appear in an authoritative RRset's set of RRSIGs, the
response is "bogus" not "insecure".

The question of which algorithm is stronger or weaker does not arise
here, MiTM can in fact "downgrade" a multi-signed zone to its weakest
signing algorithm, by stripping the other RRSIGs.  Don't use broken
algorithms, by switching away from deprecated algorithms in a timely
fashion.  This has largely been accomplished for algorithms 5 and 7,
which are down to ~7% of their peak deployment counts.

DNSSEC algorithm agility is serving its intended purpose just fine.
Resolver implementations had an apparently somewhat common bug, which
most should have addressed by now (that the issue is public).

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

Re: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 09:56:31PM +, Phillip Hallam-Baker wrote:

> Looks to me like there is a serious problem here.

There is not a problem with the specification.  DNSSEC algorithm agility
works when implemented correctly.  Now that DNSSEC adoption is finally
becoming noticeable (though at ~5% of global domains, still far from the
norm), the DNS community is addressing operational issues and ferreting
out the latent implementation bugs.

> NSEC record specifies what is signed but not the algorithm used to
> sign. DNSSEC allows multiple signature and digest algorithms on the
> same zone. If a zone does this, validators are prohibited from
> rejecting records only signed using one of the algorithms rather than
> both.

This is misleading.  If any of the algorithms present in the zone's DS
RRset published in the parent zone are supported by the validating
resolver, then the zone is *signed*, and all authoritative response
RRsets from the zone must be accompanied by a valid RRSIG that chains
back to a valid SEP and is mutually supported by the resolver and zone
signer.  If only unsupported RRSIGs are returned, the response is BOGUS.
Implementations that fail to make that conclusion are in error.

Apparently, bugs in some implementations until recently tolerated
responses that carried only unsupported RRSIGs, erroneously treating
these as "insecure", by failing to require the presence of a shared
supported ZSK algorithm chaining up to a valid SEP.

This was an implementation bug, that can at most charitably be treated
as missing explicit guidance in the specification to do the "obvious
right thing(TM)".  Such explicit guidance can be added in a new
clarification RFC, if deemed appropriate, though my personal view is
that it should not have been necessary.  That said, on the evidence of
the recent implementation bugs, perhaps being needlessly explicit is at
times the prudent thing to do.

> Won’t go into extreme detail here as researcher’s slides will be
> available tomorrow.
> 
> This definitely needs fixing.
> 
> One near term fix is to make SHA-1 a MUST NOT. It is long past its
> sell-by date now.

SHA-1 is not the problem here.  The downgrade issue is equally a problem
with NSEC (which does not use SHA-1) and NSEC3 (where use of SHA-1 for
light obfuscation to discourage zone-walking is just fine), and even for
cases that are not denial of existence at all.  And the problem exists
also for zones signed with only SHA-256 (e.g. algorithms 8 and 13 if
some now rare resolver supports only one and not the other).

The abstract makes no mention of NSEC records or denial of existence:

In this talk, we show that the cryptographic agility in DNSSEC,
although critical for making DNS secure with strong cryptography,
also introduces a severe vulnerability. We demonstrate that
adversaries, by manipulating the cryptographic material in signed
DNS responses, can reduce the security level provided by DNSSEC, or,
even worse, prevent resolvers from validating DNSSEC at all. We
experimentally and ethically evaluate our attacks against popular
DNS resolver implementations, public DNS providers, and DNS services
worldwide. We validate the success of DNSSEC-downgrade attacks by
poisoning the resolvers: we inject fake records, from our own signed
domains, into the caches of validating resolvers. Our findings show
that major DNS providers, popular resolver implementations, and many
other DNS services are vulnerable to our attacks.

The abstract is IMNSHO misleading.  Agility is not the problem,
incorrect implementation is the problem, though perhaps the requirements
for correctly handling multiple algorithms could have been more clearly
spelled out in RFC 4035, which covers signer responsibility in full
detail, but omits some of the (I claim obvious as a matter of logic, but
it seems still perhaps worth stating explicitly) corresponding
requirements on validators.

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

Re: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 04:58:46PM -0600, Paul wrote:

> Should we revive the 0x20 draft?

Seems reasonable to me.

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

[dns-operations] Systemic DoE failure at worldnic.com nameservers

[Viktor Dukhovni]

As seen at:

https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/worldnic.com.html

over 400 "small" signed zones (zone apex only in the NSEC chain) return
incorrect "NODATA" RCODEs for "_25._tcp.. TLSA ?".  The
provided NSEC records instead prove "NXDOMAIN".  This breaks email to
these domains from DANE-enabled MTAs.

If I'm not mistaken, "worldnic.com" is a NetworkSolutions brand, don't
know whether they have anyone on this list.  WHOIS contact Cc'd.

-- 
Viktor.

P.S.  Top 5 nameservers with DoE breakage:

609 registrar-servers.com
402 worldnic.com
248 mijndomein.nl
138 axc.nl
 75 ebola.cz
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Name servers returning incorrectly truncated UDP responses

[Viktor Dukhovni]

On Fri, Jul 29, 2022 at 05:04:28PM -0400, Puneet Sood via dns-operations wrote:

> $ dig m.email.sonyentertainmentnetwork.com. TXT 
> @e.ns.email.sonyentertainmentnetwork.com
> ;; Warning: Message parser reports malformed message packet.
> ;; Truncated, retrying in TCP mode.

Indeed this response is truncated to just the question without adjusting
the answer count accordingly (tshark decode):

Domain Name System (response)
Transaction ID: 0x7189
Flags: 0x8600 Standard query response, No error
1...    = Response: Message is a response
.000 0...   = Opcode: Standard query (0)
 .1..   = Authoritative: Server is an authority for 
domain
 ..1.   = Truncated: Message is truncated
 ...0   = Recursion desired: Don't do query recursively
  0...  = Recursion available: Server can't do 
recursive queries
  .0..  = Z: reserved (0)
  ..0.  = Answer authenticated: Answer/authority 
portion was not authenticated by the server
  ...0  = Non-authenticated data: Unacceptable
    = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
m.email.sonyentertainmentnetwork.com: type TXT, class IN
Name: m.email.sonyentertainmentnetwork.com
[Name Length: 36]
[Label Count: 4]
Type: TXT (Text strings) (16)
Class: IN (0x0001)
[Malformed Packet: DNS]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]

002071 89 86 00 00 01 q.
0030  00 01 00 00 00 00 01 6d 05 65 6d 61 69 6c 18 73   ...m.email.s
0040  6f 6e 79 65 6e 74 65 72 74 61 69 6e 6d 65 6e 74   onyentertainment
0050  6e 65 74 77 6f 72 6b 03 63 6f 6d 00 00 10 00 01   network.com.

Another interesting factor is that the nameserver responded to an EDNS0
query without either returning FORMERR or returning an OPT pseudo-RR.

EDNS0 is also ignored over TCP, only this time the response is not
truncated:

$ dig +nocmd +vc +norecur m.email.sonyentertainmentnetwork.com. TXT 
@e.ns.email.sonyentertainmentnetwork.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12793
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;m.email.sonyentertainmentnetwork.com. IN TXT

;; ANSWER SECTION:
m.email.sonyentertainmentnetwork.com. 3600 IN TXT "v=spf1 a mx ... ~all"

;; Query time: 7 msec
;; SERVER: 207.251.96.133#53(207.251.96.133)
;; WHEN: Fri Jul 29 17:35:05 EDT 2022
;; MSG SIZE  rcvd: 542

That said, an earlier case observed internally today trucated to 512
bytes in the middle of an RR, but did adjust the counts, so that
response had extra bytes at the end of the packet, while this one is
missing a promised RR.

So perhaps there's more than one problem implementation, though both
simply ignore EDNS and respond sans FORMERR or OPT.

It is looking like truncation is implemented poorly more often than one
might like...

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

Re: [dns-operations] ns1-proddns.glbdns.o365filtering.com unreachable?

[Viktor Dukhovni]

On Wed, Jul 06, 2022 at 11:42:14AM +0200, Daniel Baumann wrote:

> ns{1,2}-proddns.glbdns.o365filtering.com resolv to the same IP, do
> not support EDNS and don't answer on TCP queries.

Well, FWIW, the same two IPs.

On Wed, Jul 06, 2022 at 11:37:38AM +0200, Stephane Bortzmeyer wrote:

> The authoritative name servers for mail.protection.outlook.com
> apparently don't reply if you use EDNS. And it seems many resolvers
> don't fallback on old-DNS (and rightly so). Seen from the RIPE Atlas
> probes, many resolvers cannot resolve names under
> mail.protection.outlook.com (here, the MX of cybercampus.fr):
> 
> ; <<>> DiG 9.16.1-Ubuntu <<>> @ns1-proddns.glbdns.o365filtering.com. NS 
> mail.protection.outlook.com
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64702
> ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available

Their lack of support for EDNS, and more critically (for DANE) the fact
that they return NOTIMP instead of NXDOMAIN for TLSA queries, has been
known to me since May 2013, when I began work on RFC7672.

The nameservers are the reason for the recommendation to not issue TLSA
queries for the TLSA records of MX hosts (and assume they don't exist or
are also unsigned) when the address (A or , whichever exist) records
of those MX hosts are unsigned.

Without that work-around, DANE-enabled MTAs would not be able to send
email to e.g. nist.gov whose MX RRset is signed, but the corresponding
TLSA queries are difficult to distinguish from a downgrade attack if one
does not already know the zone is unsigned (hence the prior A/
status check):

nist-gov.mail.protection.outlook.com. IN TLSA ? ; ServFail

The load balancers in question have an exceedingly "minimal" DNS
implementation.  For example, when asked for the zone's SOA, they return
it in the authority section (so both NODATA and the actual record).

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52424
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;mail.protection.outlook.com. IN SOA

;; AUTHORITY SECTION:
mail.protection.outlook.com. 3600 IN SOA 
ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 
3600 600 86400 3600

;; MSG SIZE  rcvd: 172

They've been working (in this minimal form) for 9+ years, so I do
understand (be it without much sympathy) some reluctance to fix the
various issues, b/c they've been managing to return the requisite A
records, which is however sadly all they've been expected to do.

Ideally, something better will be deployed eventually.

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

Re: [dns-operations] [Ext] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 07:13:30PM -0400, Phillip Hallam-Baker wrote:

> I am of course fully aware of the commercial and technical issues that make
> it very difficult for the incumbents to address this problem. But that
> doesn't change the fact that a system designed to meet the needs of
> educational institutions exchanging email in the 1980s is really not fit
> for purpose for the needs of five billion users in the 2020s.

Less stridently, we can recognise that the service discovery APIs we
have do not have a first-class notion of overlay "views" each with its
own independent naming tree, and the applications running on top of
these APIs don't have syntax for choosing a view in which to resolve
such names.

The closest we have is the ".local" subspace of the global DNS, and
reaching IETF consensus on such special use namespaces has been
exceedingly complex.

So the DNS is fundamentally a *global* namespace, but one in which
businesses often overlay a single additional internal view.

I don't think this is so much a *DNS* problem as such, or that DNS is
not fit for purpose, but I do agree that requirements are shifting,
and that indeed home automation is served poorly by a global namespace,
and an overly centralised operational model.

Sadly, time to market seems to favour doing what already works, however
poorly.  I do hope that real innovation can happen in this space, and
better solutions found.  It won't be easy.

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

Re: [dns-operations] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 10:03:30PM +0100, John Levine wrote:

> It appears that Viktor Dukhovni  said:
> >Single label names passed to getaddrinfo(3) should not result in single
> >label "A" or "" DNS queries.
> 
> If only. See RFC 7085. I've been doing regular surveys of RRs for
> single label names in the decade since we published that and things
> haven't changed much.

By "should not" I don't mean "typically won't".  I am not describing
"presently expected" behaviour, rather I am describing what a modernised
library might do.

An example of the "predictable" is better than "sometimes right"
approach is seen in the OpenSSL DANE implementation:

When validating peer certificate chains against a DANE-TA(2)
trust-nachor TLSA record, the local trust store is always
completely ignored.  All the certificates needed to build a
matching chain MUST be present in the remote peer's certificate
message.

You might ask why?  Well, because not all validators will have the same
trust store contents, and having a DANE TLSA record that works with some
stacks when you test it, but then fails with others in the field is bad.

So the design is biased in favour of consistent behaviour, which aids
interoperability.  Unpredictable behaviour is not doing anyone a favour.

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

Re: [dns-operations] [Ext] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 09:09:50PM +, Paul Hoffman wrote:

> > The IETF tends to be very conservative in leave lots of lattitude in its
> > specifications for various potential corner cases.  The caution is often
> > times warranted, and yet in the same 3 decades or so nothing has changed
> > the fact that A/ records at TLDs are profoundly fragile.
> 
> What is "profoundly fragile" about A or  records at any level of
> the DNS hierarchy?

The fact that queries for these via almost all real-world systems would
get qualified with the local search list and resolved in highly
non-portable ways, for example:

$ host go
go.corp.google.com is an alias for uberproxy.l.google.com.
uberproxy.l.google.com has address [...]
uberproxy.l.google.com has IPv6 address [...]

If "go" were a ccTLD that attempted to publish A/ records, it would
work rather poorly on the network why I am sitting this minute.

> Also note that the example given earlier is a ccTLD, not a gTLD. ICANN
> does not have contracts with (most of) the ccTLD admins.

Makes no difference.  This has nothing to do with ICANN, and everything
to do with RES_DEFNAMES and RES_DNSRCH.

> > So as a platform library maintainer, I'd be stricter than IETF was
> > willing to be, and would in fact have getaddrinfo(3) return an empty
> > list for "some-tld" and even "some-tld.", with the notable exception of
> > "localhost", whith the nsswitch code sending no A/ DNS queries for
> > TLDs.  Only /etc/hosts and other local sources would be consulted.
> 
> Advocating that a library not check for valid data (even if you
> believe that it is "profoundly fragile" seems more likely to lead to
> damage than checking for it.

In many cases, better to consistently fail than to be lucky some
fraction of the time.  The library in question is above the DNS layer.
Applications that directly query DNS can choose to make A/ queries
with single-label qnames, that's fine, but getaddrinfo(3) would in my
hands shun DNS for such names.

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

Re: [dns-operations] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 04:24:01PM -0400, Dave Lawrence via dns-operations 
wrote:

> I'm aware "SSAC also recommends that the use of DNS resource records
> such as A, , and MX in the apex of a TopLevel Domain (TLD) be
> contractually prohibited where appropriate and strongly discouraged in
> all cases," yet still note that saying "getaddrinfo should not result
> in single label 'A' or '' DNS queries" is a meaningful policy
> change to an API that's older than some of the people on this mailing
> list.

The IETF tends to be very conservative in leave lots of lattitude in its
specifications for various potential corner cases.  The caution is often
times warranted, and yet in the same 3 decades or so nothing has changed
the fact that A/ records at TLDs are profoundly fragile.

So as a platform library maintainer, I'd be stricter than IETF was
willing to be, and would in fact have getaddrinfo(3) return an empty
list for "some-tld" and even "some-tld.", with the notable exception of
"localhost", whith the nsswitch code sending no A/ DNS queries for
TLDs.  Only /etc/hosts and other local sources would be consulted.

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

Re: [dns-operations] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 01:33:51PM -0400, Dave Lawrence wrote:

> Viktor Dukhovni writes:
> > Single label names passed to getaddrinfo(3) should not result in single
> > label "A" or "" DNS queries.
> 
> http://ai./

Well aware of it, and that's why I wrote "worst case you'll actually get
an answer".  The A/ records for "ai" were/are a bad idea.

> Kind of surprising to me the number of TLDs who report their address
> as 127.0.53.53:
> 
> .arab
> .cpa
> .kids
> .music
> .xn--mxtq1m (Chinese: "government")
> .xn--ngbrx (Urdu: "Arab")

And you'll see more detail with an SRV query:

arab. IN SRV 10 10 0 your-dns-needs-immediate-attention.arab.

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

Re: [dns-operations] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 02:31:37PM +0200, Petr Menšík wrote:

> >> - how should single label names be handled?
> >
> > Local policy.
>
> I have made some tests. nss plugins in glibc do not allow trying single 
> label applied with search domain in dns. Then try other plugins like 
> llmnr. Then as a last resort try resolution of this name on DNS with 
> just the name without anything appended. I think this cannot be 
> configured on today's Linux implementation.

See resolv.conf(5):

  options
  ...
  no-tld-query (since glibc 2.14)
 Sets RES_NOTLDQUERY in _res.options.  This option causes
 res_nsearch()  to  not  attempt  to  resolve  an unqualified
 name as if it were a top level domain (TLD).  This option can
 cause problems if the site has ``localhost'' as a TLD rather
 than having localhost on one or more elements of  the  search
 list.   This option has no effect if neither RES_DEFNAMES or
 RES_DNSRCH is set.

The name "localhost" should just be hardcoded to map to "127.0.0.1" and
"::1" in getaddrinfo(3), without any queries to DNS or any other
oracles.  Failing that, just list it in /etc/hosts, and search that
(short) file first (but this is more fragile).

https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

   3.  Name resolution APIs and libraries SHOULD recognize localhost
   names as special and SHOULD always return the IP loopback address
   for address queries and negative responses for all other query
   types.  Name resolution APIs SHOULD NOT send queries for
   localhost names to their configured caching DNS server(s).

   4.  Caching DNS servers SHOULD recognize localhost names as special
   and SHOULD NOT attempt to look up NS records for them, or
   otherwise query authoritative DNS servers in an attempt to
   resolve localhost names.  Instead, caching DNS servers SHOULD,
   for all such address queries, generate an immediate positive
   response giving the IP loopback address, and for all other query
   types, generate an immediate negative response.  This is to avoid
   unnecessary load on the root name servers and other name servers.

See also (expired draft):


https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost-02

> >> -- in which order should be resolution tried? Should machine cache block
> >> queries to single label hostnames not expanded to FQDN on DNS protocol?
> > For getaddrinfo(3), indeed there is no reason to ask a TLD for its IP
> > address, worst case is you actually get an answer!
>
> Well, I am not sure this is sarcasm or not. Current systemd-resolved 
> redirects single label to LLMNR lookup if that is enabled. Should DNS be 
> asked before LLMNR even for single labels? Should local cache try to 
> protect root servers from unnecessary queries? It seems windows 11 does 
> apply search first, then LLMNR. I am not sure whether it tries also 
> single label query as last step.

Single label names passed to getaddrinfo(3) should not result in single
label "A" or "" DNS queries.

> I would display a DNSSEC support somewhere in connection status windows 
> only. I do not think DNSSEC would be as important captive portal 
> indication or limited connectivity. I would like to implement captive 
> portal support in NM, which would allow also DNSSEC. But at least 
> dnssec-trigger implementation reported annoying error every time I got 
> disconnected. I am sure this is not the correct way. It has to be able 
> to guess when DNSSEC is failing and when whole connection does not work.

Some fine-tuning of the various scenarios may still be needed.

> > Of course for DNSSEC on end-user (rather than datacentre) devices to
> > matter, support would need to be broader than just Linux laptops.  It
> > would need to ultimately encompass MacOS, Windows, Android, iOS, ...
> > But some vendor would to be the first mover.
>
> Understood. But I am not able to influence those.

Speaking of which, we now have some news of Apple supporting end-user
device DNSSEC, with applications presently opting in for this service,
so not yet on by default.  The first moves are being made...

> Interesting, would you be able to find a documentation for it?

I'd use Google to find it, which is available to all... :-)


https://www.google.com/search?client=firefox-b-1-d=openbsd+async+dns+lookup
->  https://man.openbsd.org/asr_run.3

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

Re: [dns-operations] How should work name resolution on a modern system?

[Viktor Dukhovni]

On Fri, Jun 10, 2022 at 09:16:11PM +0200, Petr Menšík wrote:

> - first is libc interface getaddrinfo() provided by nss plugins. Names 
> can be resolved also by different protocols than just DNS. A good 
> examples might be MDNS (RFC 6762), LLMNR (RFC 4795) or Samba 
> (nmblookup). Standardized calls provide only blocking resolution interface.

The nsswitch (originall from SunOS IIRC) indeed has limitations, but is
unlikely to fade away quickly, especially because it also handles
non-DNS queries (passwd, group, services, ...).

That said, best practice for "hosts" has been essentially:

hosts: files dns

with a very short /etc/hosts with just the local system address and
name, perhaps only a loopback address at that.  But this was before as
mention below the introduction of "mdns" et. al., and in some
"enterprise" environments "samba" or similar.

> * Asynchronous interface does not exist in useful form. It is easy to 
> handle multiple connections in single thread, but multiple resolutions 
> in single thread are not supported. nss plugins are simple to write, but 
> hard to use in responsibe program. Should that be changed?

Indeed asynchronous interfaces for some of these would be quite useful,
and some dedicated libraries (alternatives to good-*old* libresolv)
provide these for DNS specifically, but they are not ubiquitous, and
would introduce completely new APIs undreamed of in SvID and POSIX.

> * MDNS usually uses names under .local domain. What should be preferred 
> order of single label names, like 'router.'? Should be LLMNR tried 
> first, samba first or DNS search applied first? Should it avoid reaching 
> DNS when search domain is not set?

I rather expect there is no one-size-fits-all answer, and so
nsswitch.conf or equivalent is here to stay.  Sometimes one wants no
"mdns" or similar at all.  The right answer for a laptop trying to
locate nearby printers is rather different than the answer for a server
racked in a datacentre.

> - primary interest for us is DNS protocol. On Unix systems it specifies 
> nameservers to use in /etc/resolv.conf also with some options. We would 
> like to offer DNS cache installed on local machine, which should 
> increase speed of repeatedly resolved names.

Definitely, with DNSSEC validation, and (on laptops) perhaps support for
probing of DNSSEC support when switching between WiFi networks, or
opting in to a captive portal, so that DNSSEC is used when available,
once the portal T etc have been dealt with, and real DNS servers
(ideally) become reachable.

> * I would like to have support for multiple interfaces and redirection 
> of names subtree to local network interfaces servers. For example 
> 'home.arpa' redirected to local router at home, but example.com 
> redirected to VPN connection.

This is largely a laptop problem, but indeed the local caching
nameserver could have appropriate stub zones defined, so that
queries for "special" zones are sent to non-default servers.

> I think RFC 8801 and RFC 7556 specify standardized way to list
> interface specific domains. Existing implementations misuse RFC 2937
> for a source of such list now. Something like this is implemented by
> systemd-resolved on Ubuntu and Fedora systems. But it introduced
> couple of new issues. Is something similar implemented on end user
> machines? I think laptop and phones are typical devices with multiple
> interfaces, where it would make sense.

This is a complex question, that can't be answered in a brief email
thread.  Designs need to be throught through, written up, debated,
zealously supported, ignored, dismissed out of hand, ... :-) :-(

> - how should single label names be handled?

Local policy.

> -- is domain (opt. 15) and search (opt. 117) from DHCP already dead? 
> Should they be completely avoided even in trusted networks?

They had some merit for moving laptops between corporate offices, but
are problematic on shared public WiFi networks, so perhaps by now best
ignored.  The hot new trend is to always leave mobile devides on
"external" networks, even on prem.  And so you're always on the public
Internet, where search lists from DHCP are not trustworthy.

> -- in which order should be resolution tried? Should machine cache block 
> queries to single label hostnames not expanded to FQDN on DNS protocol?

For getaddrinfo(3), indeed there is no reason to ask a TLD for its IP
address, worst case is you actually get an answer!

> -- I have seen usage of search domains on cloud technologies. Is there 
> common example what they are used for? Do we need ndots option with 
> value different from 1?

For managed servers in datacentres there is some plausible value in
search lists, but anything with more than one element used to qualify
names with more than zero dots has dubious semantics in the face of
timeouts, or other transient failures.  Should these abort the query,
or occasionally seek the answer in what could be the wrong place?

> - should we expect DNSSEC 

Re: [dns-operations] Input from dns-operations on NCAP proposal

[Viktor Dukhovni]

On Mon, Jun 06, 2022 at 10:57:01AM -0400, Dave Lawrence wrote:

> I seem to be exceptionally derpy right now, but I'm realizing I can't
> articulate why it can't be done with the standard NXDOMAINs that the
> roots have been issuing all along.

If the "it" is collection of extant use of a suffix, than I think you're
right.  All the prior fancy gymnastics were at the point in time when
the new suffix is actually delegated at the root, but not yet available
for registration of subdomains.  The intent was to let the *users* of
conflicting subdomains know that they are skating on thin ice, before
their favourite domains are directed somewhere even more surprising.

If the need for a signal back to the source of the query is not in
scope, then it seems like NXDOMAIN might suffice.

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