Re: [dns-operations] Important change for the .ga TLD 6th june 2023

[Puneet Sood via dns-operations]

--- Begin Message ---
Stephane,

Looks like google.ga is returning NXDOMAIN from the nic.fr servers.
Can you please check what could be wrong with the delegation info?

Thanks,
Puneet

$ dig @d.nic.fr google.ga

; <<>> DiG 9.10.6 <<>> @d.nic.fr google.ga
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55926
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.ga. IN A

;; AUTHORITY SECTION:
ga. 600 IN SOA a.nic.fr. dnsmaster.afnic.fr. 222484 3600 1800 360 600

;; Query time: 97 msec
;; SERVER: 2001:678:c::1#53(2001:678:c::1)
;; WHEN: Sun Jun 04 22:22:48 EDT 2023
;; MSG SIZE  rcvd: 100

On Sun, Jun 4, 2023 at 10:46 AM Stephane Bortzmeyer  wrote:
>
> On Fri, Jun 02, 2023 at 09:28:24AM +0200,
>  Stephane Bortzmeyer  wrote
>  a message of 56 lines which said:
>
> > The .ga TLD will change its mode of operation on 6th june 2023. The majority
> > of domain names, registered under disputable conditions, will be removed. Do
> > not be surprised if many domains will yield NXDOMAIN.
>
> Done in advance, this night (gabonese time).
>
> % check-soa -i ga
> d.nic.fr.
> 2001:678:c::1: OK: 222414 (6 ms)
> 194.0.9.1: OK: 222414 (14 ms)
> f.ext.nic.fr.
> 2001:67c:1010:11::53: OK: 222414 (17 ms)
> 194.146.106.46: OK: 222414 (19 ms)
> g.ext.nic.fr.
> 2001:678:4c::1: OK: 222414 (5 ms)
> 194.0.36.1: OK: 222414 (5 ms)
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

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

[Paul Hoffman]

To augment what Joe and Viktor said, please see RSSAC028, "Technical Analysis 
of the Naming Scheme Used For Individual Root Servers", 
. That 
document is about how the root servers are named, and how that naming affects 
the signing of the records associated with them.

As some folks on this list know, ICANN staff have contracted out the study of 
Recommendation 2 of RSSAC028 (and many of those on the contracted team are on 
this mailing list). We are expecting a final report of the results by the end 
of this year.

--Paul Hoffman


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

Re: [dns-operations] Important change for the .ga TLD 6th june 2023

[Stephane Bortzmeyer]

On Fri, Jun 02, 2023 at 09:28:24AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 56 lines which said:

> The .ga TLD will change its mode of operation on 6th june 2023. The majority
> of domain names, registered under disputable conditions, will be removed. Do
> not be surprised if many domains will yield NXDOMAIN.

Done in advance, this night (gabonese time).

% check-soa -i ga
d.nic.fr.
2001:678:c::1: OK: 222414 (6 ms)
194.0.9.1: OK: 222414 (14 ms)
f.ext.nic.fr.
2001:67c:1010:11::53: OK: 222414 (17 ms)
194.146.106.46: OK: 222414 (19 ms)
g.ext.nic.fr.
2001:678:4c::1: OK: 222414 (5 ms)
194.0.36.1: OK: 222414 (5 ms)
___
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] New addresses for b.root-servers.net

[Joe Abley]

Hi Matthew,

Signing the ROOT-SERVERS.NET zone would provide the ability to validate its 
contents, but since it's rare for applications and end users to ask questions 
that are answerable from that zone the benefit is arguably marginal. The 
ability to follow a chain or trust through keys published in the root, COM and 
CLOUDFLARE.COM allows names in that zone to be validated completely without a 
secure delegation to the ROOT-SERVERS.NET zone, for example.

There would also be some amount operational complexity in managing the signing 
function, and new failure modes of the ability to validate the contents of that 
zone depended on a clean path of trust through the root and NET zones. These 
are probably minor or manageable.

I think the most compelling argument against signing that zone is that many 
priming queries are sent with DO=1, and a priming response that included 
signatures would be significantly larger than it is without, and would require 
either fragmentation or a non-UDP transport to deliver. This would be a 
significant change to a population of DNS clients whose practical constraints 
regarding DNS message delivery are not well-understood.

So, it's difficult to identify a clear benefit and the risks, although quite 
possibly small, have the potential to be significant.

Joe

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

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

[Matthew Richardson via dns-operations]

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

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

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

Would signing it provide additional any additional security?

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