DNS not set up correctly

[allen-ziegenfus]

@willnewbury was trying out the local extension environment and ran into issues with DNS resolution, that the dxp.lfr.dev hostname was not resolving.

running dig dxp.lfr.dev results in this output:

; <<>> DiG 9.11.3-1ubuntu1.18-Ubuntu <<>> dxp.lfr.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42773
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;dxp.lfr.dev.           IN  A

;; ANSWER SECTION:
dxp.lfr.dev.        2980    IN  CNAME   lfr.dev.

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Dec 08 15:36:29 MST 2022
;; MSG SIZE  rcvd: 5

On my machine it has an A record for lfr.dev but that is missing above. What would we need to debug this issue?

Adding a hardcoded /etc/hosts entry for lfr.dev fixes the problem

[gamerson]

if I run dig dxp.lfr.dev I get this:

$ dig dxp.lfr.dev

; <<>> DiG 9.10.6 <<>> dxp.lfr.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58182
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dxp.lfr.dev.           IN  A

;; ANSWER SECTION:
dxp.lfr.dev.        1   IN  CNAME   lfr.dev.
lfr.dev.        1   IN  A   127.0.0.1

;; Query time: 170 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Dec 08 16:58:42 CST 2022
;; MSG SIZE  rcvd: 70

I don't know what the difference is.

[gamerson]

we have a wildcard DNS record registered for *.lfr.dev, to point to loopback so dig foobar.lfr.dev also does the same

$ dig foobar.lfr.dev

; <<>> DiG 9.10.6 <<>> foobar.lfr.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62109
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;foobar.lfr.dev.            IN  A

;; ANSWER SECTION:
foobar.lfr.dev.     1   IN  CNAME   lfr.dev.
lfr.dev.        1   IN  A   127.0.0.1

;; Query time: 180 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Dec 08 17:00:07 CST 2022
;; MSG SIZE  rcvd: 73

[allen-ziegenfus]

we tested that dig @8.8.8.8 dxp.lfr.dev does return the correct result so it must be related to how the dns records are propagated to some servers

[gamerson]

Yes that could be. Maybe we should open a ticket.

On Thu, Dec 8, 2022 at 5:16 PM Allen Ziegenfus @.***> wrote:

we tested that dig @8.8.8.8 dxp.lfr.dev does return the correct result so it must be related to how the dns records are propagated to some servers

— Reply to this email directly, view it on GitHub https://github.com/liferay/liferay-cli/issues/111#issuecomment-1343496979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAERKFNQYPPVXFNRAKSBDPDWMJT5VANCNFSM6AAAAAASYVP6LQ . You are receiving this because you commented.Message ID: @.***>

-- Greg Amerson Liferay Cloud. liferay.com

[gamerson]

hey @allen-ziegenfus i just tried to reproduce this from my Mac:

[greg@bijiben liferay-portal-sparse (master|SPARSE)]$ dig @8.8.8.8 dxp.lfr.dev

; <<>> DiG 9.10.6 <<>> @8.8.8.8 dxp.lfr.dev
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14750
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dxp.lfr.dev.           IN  A

;; ANSWER SECTION:
dxp.lfr.dev.        3600    IN  CNAME   lfr.dev.
lfr.dev.        600 IN  A   127.0.0.1

;; Query time: 56 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 03 17:21:18 CST 2023
;; MSG SIZE  rcvd: 70

and the 8.8.8.8 server responded with the correct loopback address. Can you try again?

[allen-ziegenfus]

@willnewbury can you try this out?

[gamerson]

@willnewbury let us know if you see this again.