DNS query fails - did the query reach the router?

asked 2022-09-20 11:06:41 +0000

sugar76
9 ●3 ●5 ●8

updated 2022-09-20 11:09:35 +0000

Users did report that visiting a web site via iPad/Safari fails. I found out that the reason a failing DNS query. This issue only applies to some websites (for others it works). Visiting one of the "failing" sites at the same time using an iPhone works.

One of the failing sites is achgut.com. I recorded a network trace on the router. In this trace I see a lot of succeeding DNS queries from 192.168.178.109 (an iPhone). I see some other queries from 2003:ec:df10:1600:f419:5a6c:e4bc:f28e but I am not sure which device this is. The 192.168.178.109 is a MacBook. The router's ip address is 192.168.178.1.

I would like to know if the DNS query of failing iPad did actually reach the router. Unfortunately I do not know the ip address of the iPad. The iPad's hostname is "Abids-iPad".

My questions are: Is there a way to identify the device model in the trace? Does the trace indicate any DNS errors?

Trace: https://drive.google.com/file/d/1vH0U...

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2022-09-22 11:26:31 +0000

SYN-bit

18528 ●9 ●339 ●255 https://SYN-b.it

In your trace I see DHCP requests from the mentioned iPad (filter on dhcp.option.hostname == "Abids-iPad"). Then looking at DHCP and ARP traffic to/from the mac-addess of the iPad (filter on eth.addr == c4:c3:6b:0e:dd:e2 && (dhcp || arp)), I can see that the iPad declines the use of the offered address. This is done after sending ARP probes. I do not see responses to the ARP probes, but based on the DHCP-DECLINE, I assume there was another device on the network that is using the address 192.168.178.100 which sent ARP responses directly to the iPad.

The DHCP-DECLINE message should tell the DHCP server to NOT hand out this address anymore, but the DHCP server keeps handing out this address to the iPad. This is a BUG in the DHCP server as far as I can tell. So the root cause is a duplicate address on the network that should be resolved by the DHCP-DECLINE messages, but because of the BUG on the DHCP server, it prevents the iPad from getting an IP address.

To find the device with the IP address 192.168.178.100, you can disable WiFi on the iPad and then ping 192.168.178.100 and look at the ARP entry for it in your ARP table. Then look for that mac address on your network (for finding out the vendor OUI for that mac-address, visit https://www.wireshark.org/tools/oui-l...)

edit flag offensive delete link

Comments

As a possible workaround one could check in the DHCP server settings if a fixed IP address assignment (for 192.168.178.100) overlaps with the configured dynamic address pool. As said, these fixed addresses should be excluded from the dynamic pool, but this may not be the case. If an overlap is seen the dynamic pool may be adjusted to sidestep the fixed assignments, thereby avoiding this assignment conflict.

Jaap ( 2022-09-22 11:42:10 +0000 )edit

Thanks for this excellent explanation. Indeed I noticed there's another device with fixed ip address 192.168.178.100. So it's a DHCP misconfiguration. Furthermore I didn't understand why the iPad could reach some domains and others not. E.g. I noticed that reaching domain achgut.com fails whereas tichyseinblick.de succeeds. Then I noticed that achgut.com has only a DNS A-record whereas tichyseinblick.de has also a DNS AAAA-record. As the iPad didn't have an IPv4 address in the local network but an IPv6 address this seems to be the reason. Again: thanks to all participants for this great help.

sugar76 ( 2022-09-24 12:39:36 +0000 )edit

add a comment

answered 2022-09-20 12:36:23 +0000

hugo.vanderkooij
76 ●190 ●4

If you filter on udp.dstport == 5353 you can see all those chatty devices announcing themselves on the network. There you can learn MAC addresses and tell who is who on the network.

Abids-iPad.local: type AAAA, class IN, cache flush, addr fe80::18a1:587c:7995:a341

With that Link-Local address you can see the MAC address and use that as filter. (Use http://www.sput.nl/cgi-bin/cgi-llmac if you are lazy or in a hurry.)

But there is no traffic to be found with eth.addr == 1A:A1:58:95:A3:41 so that might be traffic using a different network.

edit flag offensive delete link

Comments

Thanks this helped me a lot to identify the devices in the trace :-) (unfortunately I cannot upvote as I haven't enough credits)

sugar76 ( 2022-09-21 08:33:38 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

DNS query fails - did the query reach the router?

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

DNS query fails - did the query reach the router? edit

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

DNS query fails - did the query reach the router?