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

[Doug Barton]

On 6/2/23 3:50 PM, Wes Hardaker wrote:

Robert Story  writes:


We are indeed testing with the new addresses, but it will not be
considered  production until 2023-11-27. The addresses and/or routes
may have brief or extended outages, so I wouldn't recommend switching
anything ahead of our announced dates for the cut-over.


Robert is correct that we are operating it (and we made sure we were
before even announcing the upcoming change).  I think there is a good
question as to whether or not we are supporting it fully now as a
"production" address, to which I can say: we have no intent to stop
advertising and supporting service to it from now on.

But, having said that, the announcement and expected change within the
official root zone distributed by IANA will be on 2023-11-27 per the
announcement and our agreement with IANA.  We do not recommend anyone
switch their local root-hints files ahead of that date, as the result
will be a resolver that actually reverts back to our current production
date after receiving the priming query responses anyway (as only our
current addresses are in the root zone and root-servers.net zone today).


Wes,

I am 100% behind this effort to de-centralize the root server network 
resources, and particularly excited that LACNIC has been chosen for this 
important role. We've changed root server addresses in the past, and 
while it hasn't happened in a while folks who haven't been through this 
before should know that there is no reason to panic.  :)



I am a little concerned about the plan for this change though, in the 
sense that in the past when the new addresses were announced they were 
fully operational, barring any unforeseen issues. So during the phase-in 
period (usually a year in advance of the intended cutover) folks were 
free to treat the new addresses as production, bake them into silicon, 
etc. After the cutover date the old addresses continued to answer for a 
year (or so), but folks were discouraged from continuing to use them.


I thought that Robert's announcement was clear, but I think that the 
confusion is coming because Robert's plan didn't seem to line up with 
"how we've always done it," which you've now confirmed.


I'm not saying that you need to change anything, but I think the safer 
alternative would be starting ASAP to treat the new addresses as 
production to the extent possible, since other people will do that 
anyway. I also think that gives you a more realistic chance of making 
sure that when the cutover actually happens that everything will work as 
intended.


Just want to be clear that I am offering these comments solely in the 
spirit of making sure that the project is ultimately successful.


hope this helps,

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

[Doug Barton]

On 6/2/23 11:12 AM, Dave Knight wrote:

commented out the root hints file in /etc/bind/named.conf.default-zones

run named with debugging output enabled and tcpdump running, it primes itself 
and validates the priming response at startup


BIND does not "prime itself." That would be impossible. It has a 
compiled-in version of root hints that it falls back on if it cannot 
find one on the file system.


Regarding your assertion that you can validate the priming query with 
DNSSEC, all you can validate is the NS set. The host records cannot be 
validated because root-servers.net is not signed.


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

[Wes Hardaker]

Robert Story  writes:

> We are indeed testing with the new addresses, but it will not be
> considered  production until 2023-11-27. The addresses and/or routes
> may have brief or extended outages, so I wouldn't recommend switching
> anything ahead of our announced dates for the cut-over.

Robert is correct that we are operating it (and we made sure we were
before even announcing the upcoming change).  I think there is a good
question as to whether or not we are supporting it fully now as a
"production" address, to which I can say: we have no intent to stop
advertising and supporting service to it from now on.

But, having said that, the announcement and expected change within the
official root zone distributed by IANA will be on 2023-11-27 per the
announcement and our agreement with IANA.  We do not recommend anyone
switch their local root-hints files ahead of that date, as the result
will be a resolver that actually reverts back to our current production
date after receiving the priming query responses anyway (as only our
current addresses are in the root zone and root-servers.net zone today).

-- 
Wes Hardaker
USC/ISI
___
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

[Wes Hardaker]

Mike Hollyman via dns-operations  writes:

> My understanding is that the ARIN micro-allocations for Critical
> Infrastructure are not permitted to be transferred to other RIR.

That is correct.  Additionally, some of the goal was not just RPKI
related but rather to have a critical allocation entirely under the
control of another RIR.  This in no way is intended to say anything
negative about ARIN, who has supported our last address change
perfectly.  But there was a general agreement that the critical
infrastructure associated with the Root Server System would be best
served with an address distribution that came from a spread of all the
RIRs.  USC/ISI offered to re-allocated under LACNIC to help the RSS
achieve this goal, both with and without RPKI.

-- 
Wes Hardaker
USC/ISI
___
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

[Mike Hollyman via dns-operations]

--- Begin Message ---
My understanding is that the ARIN micro-allocations for Critical Infrastructure 
are not permitted to be transferred to other RIR.

https://www.arin.net/reference/research/statistics/microallocations/
ARIN Micro-allocations
arin.net


> On Jun 2, 2023, at 2:59 PM, Geoff Huston  wrote:
> 
> If the aim is to have the server operating with IP addresses under a
> different RPKI TA, then why don’t you just migrate the addresses
> to the intended RIR?
> 
> Geoff
> 
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Geoff Huston]

> On 3 Jun 2023, at 3:44 am, Robert Story  wrote:
> 
> On Fri 2023-06-02 09:33:20-0700 Manu wrote:
>> On Tue, May 30, 2023 at 9:35 AM Robert Story 
>> wrote:
>> 
>> It seems those are live and ready to use, but I did not see in the
>> announcement that people could start updating their root zone before
>> 2023-11-27 and be sure to receive the same service level than with
>> the old addresses.
>> 
>> Could you clarify that those are indeed good to go and there is no
>> need to wait for the renumbering date to update root.hints?
>> Would it be worth clarifying this on the LACNIC announcement?
> 
> We are indeed testing with the new addresses, but it will not be
> considered  production until 2023-11-27. The addresses and/or routes
> may have brief or extended outages, so I wouldn't recommend switching
> anything ahead of our announced dates for the cut-over.
> 

If the aim is to have the server operating with IP addresses under a
different RPKI TA, then why don’t you just migrate the addresses
to the intended RIR?

Geoff



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

Re: [dns-operations] Invalid delegation for "cloud.huawai.com"

[Mark Andrews]

No, it is not delegated properly. There is a referral NS RRset but unless there 
is a zone configured for that name on the targeted servers the delegation is 
broken. 

If named accepted the incorrect SOA record in the negative response it could 
then learn that there is no NS RRset at cloud.Huawei.com and lookups would 
return NXDOMAIN intermittently.

Broken delegations do no one a favour. Papering over them does not help in the 
end. This should take about 10 minutes to fix as it just requires using the 
correct name for the zone on those three servers.  Additionally if DNSSEC is 
ever turned on for that zone they will need to fix it to get the DNSKEY records 
published. I presume all vendors reject attempts to load zones with DNSKEY 
RRsets not at the apex. 

-- 
Mark Andrews

> On 3 Jun 2023, at 02:56, Ralf Weber  wrote:
> 
> Moin!
> 
>> On 2 Jun 2023, at 17:23, Jesus Cea wrote:
>> 
>> Bind DNS server replies  queries to "oauth-login.cloud.huawei.com" with 
>> SERVFAIL and the logs shows: "Name huawei.com (SOA) not subdomain of zone 
>> cloud.huawei.com". This is not an issue with , but with any query for a 
>> register not present in the zone. This is not a BIND bug, it is a 
>> misconfiguration in the "cloud.huawai.com" delegation.
> 
> The delegation is fine:
> 
> ; <<>> DiG 9.18.15 <<>> +nocookie NS cloud.huawei.com @nsall.huawei.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23409
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;cloud.huawei.com.INNS
> 
> ;; AUTHORITY SECTION:
> cloud.huawei.com.600INNSns4.dnsv5.com.
> cloud.huawei.com.600INNSns3.dnsv5.com.
> cloud.huawei.com.600INNSgns1.huaweicloud-dns.org.
> 
> What is not fine is what the child zone thinks about itself:
> 
> ; <<>> DiG 9.18.15 <<>> +nocookie NS cloud.huawei.com 
> @gns1.huaweicloud-dns.org.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21797
> ;; 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:
> ;cloud.huawei.com.INNS
> 
> ;; AUTHORITY SECTION:
> huawei.com.300INSOAgns1.huaweicloud-dns.org. 
> hwclouds\.cs.huawei.com. 1 7200 900 1209600 300
> 
> My guess is that the reason the resolution is failing is a problem with 
> either qname minimisation or trying to validate zone cuts. If you do regular 
> old style just follow the delegation you get a correct answer (e.g do a dig 
> +trace).
> 
> I agree that you should complain to Huawei, but the domain is certainly 
> resolvable for most resolvers out there.
> 
>> Interestingly, 8.8.8.8, 1.1.1.1, 9.9.9.9 and most other open resolvers just 
>> ignore (or not detect) the misconfiguration. Too bad, since then the issue 
>> goes unresolved because "it works for me!".
>> 
>> This is a common misconfiguration. Would be a public service that common and 
>> popular open DNS resolvers care about it, since a proper SERVFAIL would 
>> prompt a fast and trivial fix in the affected DNS configurations.
> 
> What would be the incentive for those public resolver or other resolvers to 
> give back SERVFAIL? There users would no longer be able to get to the site 
> and complain. To do something requires a concerted effort of all participants 
> like we did with the DNS Flag days, but IMHO this misconfiguration is less 
> severe than others we had flag days for.
> 
> So long
> -Ralf
> ——-
> Ralf Weber
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

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

[Dave Knight]

> On Jun 2, 2023, at 1:14 PM, Chris Adams  wrote:
> 
> Once upon a time, Dave Knight  said:
>> Aiui BIND9 uses the root.hints just once on receipt of the first query when 
>> starting with an empty cache, whereupon it will use the hints to find a root 
>> server to do a priming query, replacing the hints with the result of that.
> 
> It's been a long while since I looked - how is that done?  Do the
> resolvers query multiple servers from their hints (and somehow resolve
> differences), or do they just pick one at random and accept the results?
> 
> It seems like maybe if they'd query multiple and take a majority opinion
> of the results, the potential damage of hijacking of an old IP would be
> minimized.


We don't need to poll the group to validate the data, we have DNSSEC.


I just installed the default bind9 package on Ubuntu 20.04, which got me BIND 
9.16.1.

$ dig +noall +answer @localhost version.bind. ch txt 
version.bind. 0 CH TXT "9.16.1-Ubuntu”


It comes with the key material and default configuration to do dnssec 
validation.

commented out the root hints file in /etc/bind/named.conf.default-zones

run named with debugging output enabled and tcpdump running, it primes itself 
and validates the priming response at startup


# /usr/sbin/named -u bind -d3 -g 
02-Jun-2023 17:42:03.600 starting BIND 9.16.1-Ubuntu (Stable Release) 


[..]

02-Jun-2023 17:42:03.876 validating ./NS: starting
02-Jun-2023 17:42:03.876 validating ./NS: attempting positive response 
validation
02-Jun-2023 17:42:03.876   validating ./DNSKEY: starting
02-Jun-2023 17:42:03.876   validating ./DNSKEY: attempting positive response 
validation
02-Jun-2023 17:42:03.876   validating ./DNSKEY: verify rdataset (keyid=20326): 
success
02-Jun-2023 17:42:03.876   validating ./DNSKEY: marking as secure (DS)
02-Jun-2023 17:42:03.876 validating ./NS: in validator_callback_dnskey
02-Jun-2023 17:42:03.876 validating ./NS: keyset with trust secure
02-Jun-2023 17:42:03.876 validating ./NS: resuming validate
02-Jun-2023 17:42:03.876 validating ./NS: verify rdataset (keyid=60955): success
02-Jun-2023 17:42:03.876 validating ./NS: marking as secure, noqname proof not 
needed
02-Jun-2023 17:42:03.876 resolver priming query complete

[..]


On the wire I see it query a root server for

./IN/DNSKEY?
./IN/NS?

17:42:03.690875 IP6 2610:a1:3004:224::229.50056 > 2001:7fe::53.53: 1260% [1au] 
DNSKEY? . (40)
17:42:03.691657 IP6 2610:a1:3004:224::229.39158 > 2001:7fe::53.53: 45282 [1au] 
NS? . (40)


I can then query it for ./IN/NS? and get an authenticated response. 

; <<>> DiG 9.16.1-Ubuntu <<>> @localhost . IN NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57603
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a8a497a0545fd61b0100647a2a54cb983b8d323a4f9a (good)
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 518296 IN NS f.root-servers.net.
. 518296 IN NS b.root-servers.net.
. 518296 IN NS a.root-servers.net.

[..]

That came from the cache, it sent no more queries to the root servers.


If dnssec-validation is disabled it doesn't do a priming query at startup, 
instead waiting for an initial query before priming, and it doesn't validate 
the priming response. Enable validation :)


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

[Manu Bretelle]

On Fri, Jun 2, 2023 at 10:44 AM Robert Story  wrote:

> On Fri 2023-06-02 09:33:20-0700 Manu wrote:
> > On Tue, May 30, 2023 at 9:35 AM Robert Story 
> > wrote:
> >
> > It seems those are live and ready to use, but I did not see in the
> > announcement that people could start updating their root zone before
> > 2023-11-27 and be sure to receive the same service level than with
> > the old addresses.
> >
> > Could you clarify that those are indeed good to go and there is no
> > need to wait for the renumbering date to update root.hints?
> > Would it be worth clarifying this on the LACNIC announcement?
>
> We are indeed testing with the new addresses, but it will not be
> considered  production until 2023-11-27. The addresses and/or routes
> may have brief or extended outages, so I wouldn't recommend switching
> anything ahead of our announced dates for the cut-over.
>
> Regards,


Thanks for the clarification Robert.

>
> --
> Robert Story
> USC Information Sciences Institute 
> Networking and Cybersecurity Division
>
___
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

[Manu Bretelle]

On Fri, Jun 2, 2023 at 10:06 AM Dave Knight  wrote:

>
>
> On Jun 2, 2023, at 12:33 PM, Manu Bretelle  wrote:
>
>
> Thanks Robert,
>
> On Tue, May 30, 2023 at 9:35 AM Robert Story  wrote:
>
>>
>> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
>> b.root-servers.net on 2023-11-27. Our new IPv4 address will be
>> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
>
>
> It seems those are live and ready to use, but I did not see in the
> announcement that people could start updating their root zone before
> 2023-11-27 and be sure to receive the same service level than with the old
> addresses.
>
> Could you clarify that those are indeed good to go and there is no need to
> wait for the renumbering date to update root.hints?
> Would it be worth clarifying this on the LACNIC announcement?
>
>
> Aiui BIND9 uses the root.hints just once on receipt of the first query
> when starting with an empty cache, whereupon it will use the hints to find
> a root server to do a priming query, replacing the hints with the result of
> that. Given the infrequency of root nameserver renumbering events and the
> long period of dual operation they usually observe it's probably reasonable
> to allow root hints to be updated in the natural cadence of package
> updates.
>


For BIND9 and Unbound, the binary already has the root hints baked in, so
> maintaining hints in a static file which may not get updated with the
> package may be doing slightly more harm than good. All that to say,
> operators who are keeping their nameserver software up to date probably
> don't need to rush to update root hints and may do better to remove the
> static file entirely.
>

Totally agree with your here, but reality is that there is still a ton of
use cases that software may be using a static file to get started with and
the value to handle root.hints update properly is not worth the investment.

Manu

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

[Manu Bretelle]

On Fri, Jun 2, 2023 at 10:20 AM Chris Adams  wrote:

> Once upon a time, Dave Knight  said:
> > Aiui BIND9 uses the root.hints just once on receipt of the first query
> when starting with an empty cache, whereupon it will use the hints to find
> a root server to do a priming query, replacing the hints with the result of
> that.
>
> It's been a long while since I looked - how is that done?  Do the
> resolvers query multiple servers from their hints (and somehow resolve
> differences), or do they just pick one at random and accept the results?


That could be very implementation specific. IIRC, unbound would pick a
working one from the root.hints and prime its list from there.

>
>
> It seems like maybe if they'd query multiple and take a majority opinion
> of the results, the potential damage of hijacking of an old IP would be
> minimized.
> --
> Chris Adams 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Robert Story]

On Fri 2023-06-02 09:33:20-0700 Manu wrote:
> On Tue, May 30, 2023 at 9:35 AM Robert Story 
> wrote:
> 
> It seems those are live and ready to use, but I did not see in the
> announcement that people could start updating their root zone before
> 2023-11-27 and be sure to receive the same service level than with
> the old addresses.
> 
> Could you clarify that those are indeed good to go and there is no
> need to wait for the renumbering date to update root.hints?
> Would it be worth clarifying this on the LACNIC announcement?

We are indeed testing with the new addresses, but it will not be
considered  production until 2023-11-27. The addresses and/or routes
may have brief or extended outages, so I wouldn't recommend switching
anything ahead of our announced dates for the cut-over.

Regards,
--
Robert Story 
USC Information Sciences Institute 
Networking and Cybersecurity Division

___
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

[Chris Adams]

Once upon a time, Dave Knight  said:
> Aiui BIND9 uses the root.hints just once on receipt of the first query when 
> starting with an empty cache, whereupon it will use the hints to find a root 
> server to do a priming query, replacing the hints with the result of that.

It's been a long while since I looked - how is that done?  Do the
resolvers query multiple servers from their hints (and somehow resolve
differences), or do they just pick one at random and accept the results?

It seems like maybe if they'd query multiple and take a majority opinion
of the results, the potential damage of hijacking of an old IP would be
minimized.
-- 
Chris Adams 
___
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

[Dave Knight]

> On Jun 2, 2023, at 12:33 PM, Manu Bretelle  wrote:
> 
> 
> Thanks Robert,
> 
> On Tue, May 30, 2023 at 9:35 AM Robert Story  > wrote:
> 
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> b.root-servers.net  on 2023-11-27. Our new IPv4 
> address will be
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
> 
> It seems those are live and ready to use, but I did not see in the 
> announcement that people could start updating their root zone before 
> 2023-11-27 and be sure to receive the same service level than with the old 
> addresses.
> 
> Could you clarify that those are indeed good to go and there is no need to 
> wait for the renumbering date to update root.hints?
> Would it be worth clarifying this on the LACNIC announcement?

Aiui BIND9 uses the root.hints just once on receipt of the first query when 
starting with an empty cache, whereupon it will use the hints to find a root 
server to do a priming query, replacing the hints with the result of that. 
Given the infrequency of root nameserver renumbering events and the long period 
of dual operation they usually observe it's probably reasonable to allow root 
hints to be updated in the natural cadence of package updates. For BIND9 and 
Unbound, the binary already has the root hints baked in, so maintaining hints 
in a static file which may not get updated with the package may be doing 
slightly more harm than good. All that to say, operators who are keeping their 
nameserver software up to date probably don't need to rush to update root hints 
and may do better to remove the static file entirely.

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

Re: [dns-operations] Invalid delegation for "cloud.huawai.com"

[Ralf Weber]

Moin!

On 2 Jun 2023, at 17:23, Jesus Cea wrote:

> Bind DNS server replies  queries to "oauth-login.cloud.huawei.com" with 
> SERVFAIL and the logs shows: "Name huawei.com (SOA) not subdomain of zone 
> cloud.huawei.com". This is not an issue with , but with any query for a 
> register not present in the zone. This is not a BIND bug, it is a 
> misconfiguration in the "cloud.huawai.com" delegation.

The delegation is fine:

; <<>> DiG 9.18.15 <<>> +nocookie NS cloud.huawei.com @nsall.huawei.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23409
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloud.huawei.com.  IN  NS

;; AUTHORITY SECTION:
cloud.huawei.com.   600 IN  NS  ns4.dnsv5.com.
cloud.huawei.com.   600 IN  NS  ns3.dnsv5.com.
cloud.huawei.com.   600 IN  NS  gns1.huaweicloud-dns.org.

What is not fine is what the child zone thinks about itself:

; <<>> DiG 9.18.15 <<>> +nocookie NS cloud.huawei.com @gns1.huaweicloud-dns.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21797
;; 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:
;cloud.huawei.com.  IN  NS

;; AUTHORITY SECTION:
huawei.com. 300 IN  SOA gns1.huaweicloud-dns.org. 
hwclouds\.cs.huawei.com. 1 7200 900 1209600 300

My guess is that the reason the resolution is failing is a problem with either 
qname minimisation or trying to validate zone cuts. If you do regular old style 
just follow the delegation you get a correct answer (e.g do a dig +trace).

I agree that you should complain to Huawei, but the domain is certainly 
resolvable for most resolvers out there.

> Interestingly, 8.8.8.8, 1.1.1.1, 9.9.9.9 and most other open resolvers just 
> ignore (or not detect) the misconfiguration. Too bad, since then the issue 
> goes unresolved because "it works for me!".
>
> This is a common misconfiguration. Would be a public service that common and 
> popular open DNS resolvers care about it, since a proper SERVFAIL would 
> prompt a fast and trivial fix in the affected DNS configurations.

What would be the incentive for those public resolver or other resolvers to 
give back SERVFAIL? There users would no longer be able to get to the site and 
complain. To do something requires a concerted effort of all participants like 
we did with the DNS Flag days, but IMHO this misconfiguration is less severe 
than others we had flag days for.

So long
-Ralf
——-
Ralf Weber

___
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

[Manu Bretelle]

Thanks Robert,

On Tue, May 30, 2023 at 9:35 AM Robert Story  wrote:

>
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.


It seems those are live and ready to use, but I did not see in the
announcement that people could start updating their root zone before
2023-11-27 and be sure to receive the same service level than with the old
addresses.

Could you clarify that those are indeed good to go and there is no need to
wait for the renumbering date to update root.hints?
Would it be worth clarifying this on the LACNIC announcement?

Thanks

>
> USC/ISI will continue to support root service over our current IPv4 and
> IPv6 addresses for at least one year (until 2024-11-27) in order to
> provide a stable transition period while new root hints files are
> distributed in software and operating system packages.
>
> We are renumbering to increase the resilience of the Root Servers
> System by further diversifying the number of Regional Internet
> Registries (RIRs) that have allocated IP addresses to Root Server
> Operators. Our addresses will be the first in the Root Server System to
> have been allocated by LACNIC and our routes will be verifiable through
> LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor
> Location (TAL). We thank LACNIC for helping make this renumbering
> possible, and ARIN for supporting our prior addressing assignments.
>
>
> The LACNIC announcement, with English, Spanish and Portuguese
> translations, can be found on their website here:
>
>
> https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al-servidor-raiz-de-usc_isi
>
> Please direct any comments or questions to b-poc  isi.edu.
>
> Regards,
> Robert
>
> P.S. Apologies to anyone receiving multiple copies of this announcement.
>
> --
> Robert Story
> USC Information Sciences Institute 
> Networking and Cybersecurity Division
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Sorry, "cloud.huawei.com" - Re: Invalid delegation for "cloud.huawai.com"

[Jesus Cea]

Of course the references to "Huawai" in my previous emails are actually 
referring to "Huawei". I beg your pardon.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Invalid delegation for "cloud.huawai.com"

[Jesus Cea]

Bind DNS server replies  queries to "oauth-login.cloud.huawei.com" 
with SERVFAIL and the logs shows: "Name huawei.com (SOA) not subdomain 
of zone cloud.huawei.com". This is not an issue with , but with any 
query for a register not present in the zone. This is not a BIND bug, it 
is a misconfiguration in the "cloud.huawai.com" delegation.


This online tool identifies the issue perfectly: 
https://dnsviz.net/d/cloud.huawei.com/dnssec/


A thread in the bind-users mailing list: 
https://lists.isc.org/pipermail/bind-users/2023-June/107692.html. A 
couple of years ago one cause of many instance misconfiguration was well 
described: 
https://lists.isc.org/pipermail/bind-users/2021-January/104064.html


I have tried to reach Huawai dnsadmins with no luck so far.

Interestingly, 8.8.8.8, 1.1.1.1, 9.9.9.9 and most other open resolvers 
just ignore (or not detect) the misconfiguration. Too bad, since then 
the issue goes unresolved because "it works for me!".


This is a common misconfiguration. Would be a public service that common 
and popular open DNS resolvers care about it, since a proper SERVFAIL 
would prompt a fast and trivial fix in the affected DNS configurations.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
___
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

[Bill Woodcock]

> On Jun 2, 2023, at 3:53 PM, Stephane Bortzmeyer  wrote:
> On Fri, Jun 02, 2023 at 11:03:19AM +0300,
> Frank Habicht  wrote 
>> I'm not involved at all, but wondering:
>> no webpage for registrants to check whether their domain will 'survive'?
> The way I see it (disclaimer: I don't work for ANINF), if you
> registered through a registrar, you're probably safe (check the list
> of registrars in , and check with your
> registrar), if you registered directly from Freenom, you're probably
> not safe (Freenom did not send the data to the registry).

There’s a tremendous amount of malware and phishing, and even some national 
military cyber-offensive stuff, in the domains that Freenom gave away for free. 
 Each of the countries that’s repatriating gets to make its own policy decision 
about how it wants to handle those, but most of them seem to be leaning toward 
“flush all the bad stuff and let people re-justify if they can.”  Having looked 
closely at the registrations, I can say that I have pretty high confidence that 
very few good domains are likely to get caught up with the bad, in that 
flushing process, and the good ones should be able to re-authenticate 
themselves to the legit registry.

-Bill
___
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 11:03:19AM +0300,
 Frank Habicht  wrote 
 a message of 33 lines which said:

> I'm not involved at all, but wondering:
> no webpage for registrants to check whether their domain will 'survive'?

The way I see it (disclaimer: I don't work for ANINF), if you
registered through a registrar, you're probably safe (check the list
of registrars in , and check with your
registrar), if you registered directly from Freenom, you're probably
not safe (Freenom did not send the data to the registry).


___
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

[Marco Davids (SIDN) via dns-operations]

--- Begin Message ---

There's an interesting recent news article about the guy behind Freenom:

https://www.nrc.nl/nieuws/2023/05/26/het-riool-van-het-internet-loopt-via-amsterdam-en-tokelau-domeinen-die-gratis-weggegeven-worden-trekken-ellende-aan-a4165670

(in Dutch)

Op 02-06-2023 om 09:28 schreef Stephane Bortzmeyer:


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.

https://mon.ga/english.html

See the details in the press release:

https://www.afnic.fr/wp-media/uploads/2023/05/ga-domain-names-soon-to-return-to-Gabonese-management-1.pdf


--
Marco Davids
Research Engineer

SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids
https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl
Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34


OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
___
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

[Frank Habicht]

Hi all,

On 02/06/2023 10:28, Stephane Bortzmeyer wrote:

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.

https://mon.ga/english.html

See the details in the press release:

https://www.afnic.fr/wp-media/uploads/2023/05/ga-domain-names-soon-to-return-to-Gabonese-management-1.pdf


I'm not involved at all, but wondering:
no webpage for registrants to check whether their domain will 'survive'?

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

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

[Stephane Bortzmeyer]

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.

https://mon.ga/english.html

See the details in the press release:

https://www.afnic.fr/wp-media/uploads/2023/05/ga-domain-names-soon-to-return-to-Gabonese-management-1.pdf



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