I am a beginner here, would like to clarify a few things.
I have a server (OPC UA) running on my system, and the specification says it is announcing itself on the local link using DNS SRV records. On doing some research, I figured that mDNS is used along with DNS-SD for service discovery in local networks. The mDNS specifies the terms probing and announcement. I really am not understand the same on the wireshark log when i run the server.
Does the resource record mean, the different types of records (A, SRV,TXT,PTR) for the service(_opcua-tcp._tcp.local?)
Since it should be an announcement on the network, should it just not be a SRV query informing the service name with the port and host information?
When there is a single host and single service on the host, what are the implications of Multicast probe and announce?
Please let me know.
Attahced is the screenshot
enter image description here
Related
In the bitcoin p2p core client, the initial peers are found, as stated, as:
When started for the first time, programs don’t know the IP addresses
of any active full nodes. In order to discover some IP addresses, they
query one or more DNS names (called DNS seeds) hardcoded into Bitcoin
Core and BitcoinJ. The response to the lookup should include one or
more DNS A records with the IP addresses of full nodes that may accept
new incoming connections. For example, using the Unix ``dig command
https://en.wikipedia.org/wiki/Dig_%28Unix_command%29>`__:
source: https://developer.bitcoin.org/devguide/p2p_network.html
Is the same approach required for libp2p for initial peer discovery? I was not able to find any tutorial which covers this information. I was hoping libp2p would handle this problem. Does the libp2p provide guidance or facilities for this?
I am a beginner in OPC UA, exploring the discovery mechanisms mentioned in part 12 of the specification. I have a couple of queries.
In the Multicast extension discovery, the server registers to its Local discovery server(LDS ME), and when client does the registration to its LDS-ME, the client side LDS-ME issues a multicast probe for which the server side LDS-ME responds with an announcement, thus allowing the client to know the list of servers in the network.
My question here is, why is the process referred as Multicast probe and multicast announcement. Because as per the mDNS specification, probe and announcement are used initially to secure unique ownership of a resource record. Anybody could tell me why is it referred as probe and announce?
In the open62541 stack, with the discovery examples, running the server_lds.c, i get a log message saying "Multicast DNS: outbound interface 0.0.0.0, it means that the first OS interface is used (you can explicitly set the interface by using 'discovery.mdnsInterfaceIP' config parameter)".
Now theory says multicast dns IP should be 224.0.0.251: 5353
Why is it being set to 0.0.0.0? Could anyone please let me know?
Regards,
Rakshan
There is no relation to the words "probe" and "announce" used in the mDNS Spec. It just says probe, means look-up or query, and announce like "there are the follwing results related to your probe request".
0.0.0.0 means here every Ipv4 interface is used (bound). So every capable interface in your system will be configured for mDNS. Should be the way you mentioned.
"0.0.0.0" => have a look here https://en.wikipedia.org/wiki/0.0.0.0
I have a few questions about the mdns protocol.
1) mdns additional records add additional data about the services and domains specified in the Answers section. Can the Answer section contain more than one service, and each additional record "point" to a differnt service, depending on its offset flag? in other words, when querying an mdns packet, should we assume additional records refer to different answers, if more than one answer exists? is this scenario possible?
2) mdns provide an "A" type which is the IP address of the service. can this IP mismatch the IP address the response packet was sent from? usually, the service response on its behalf, providing its IP address when responding. but the IP address is anyway known to the receiver because this is the source IP. can the mdns responder provide an IP different than the IP it currently using?
thanks!
Can the Answer section contain more than one service, and each additional record "point" to a different service, depending on its offset flag?
Yes, a single response can contain multiple answers for the same name, e.g. multiple services being announced by the same mdns responder, and so can the additional answers.
In other words, when querying an mdns packet, should we assume additional records refer to different answers?
The additional answer records refer to their name, like any record in dns. This might, or might not, be a name that is also used by/in a record in the answer section.
Can the IP from the "A" record mismatch the IP address the response packet was sent from?
Yes. A mdns responder can resolve any host name to any ip address, not just its own name to its own ip address. An example of this might be a proxy with two network interfaces that connects the two networks by responding on the behalf of the hosts in the other. Or simpler, in the context of service discovery, a local host might announce a service that is running elsewhere, not under a .local name, and has an IP address outside the network.
I am a user of OpenDNS, and I am noticing network traffic to weird subdomains on my local area network. Suppose the "Local Domain Name" setting on my router is named "mynetwork". I am seeing many requests to domains like:
lb._dns-sd._udp.mynetwork
db._dns-sd._udp.mynetwork
b._dns-sd._udp.mynetwork
tvovhvumfcuvo.mynetwork
pqwakwyids.mynetwork
vbqulcywazgwao.mynetwork
wjyuspdzzbac.mynetwork
etc.
If this is not normal traffic how should I discern where my problem lies? Should I install something like "Little Snitch" on my Macs for example?
You may want to check out this answer from menandmice, where they say:
These are queries generated by 'Multicast/Unicast DNS Service Discovery or
Zeroconf', which is a service of Apple 'Bonjour/Rendevous' or Unix Services like
'Avahi'. DNS Queries coming from Port 5353 are DNS queries from a Zeroconf service.
The DNS Service Discovery enabled clients are looking for pointers to services running in their network block 192.0.2.0/24.
This is harmless. If there is not PTR record for the requested ownernames, it
only means that unicast Zeroconf is not configured.
"unicast Zeroconf is not configured" might not be your exact problem, but overall it's nothing to worry about.
I have a number of services running on various machines which need to communicate over arbitrary ports. Right now port discovery happens by pushing a config file to each machine which contains mappings of a service-name to a hostname/port combo.
For all the same reasons that DNS works better than manually maintaining an /etc/hosts on each machine, I'd like to have a centralized system to register and lookup these hostname/port combos.
Yes, building a simple version of this system wouldn't take long at all (it's just a key-value store), but ideally the service would be fast, redundant, auto-updating and have fail-over, which would obviously take a bit more time to build from scratch.
I can't imagine I'm the first to need such a tool, but so far my Google-fu has failed me. Is there something out there built for this purpose? Or should I just set up Kyoto Tycoon or ZooKeeper and write a bit of caching/lookup/failover logic myself?
DNS supports SRV records that are designed just for this (service location.)
SRV records are of the following form (courtesy Wikipedia):
_service._proto.name TTL class SRV priority weight port target
service: the symbolic name of the desired service.
proto: the transport protocol of the desired service; this is usually either TCP or UDP.
name: the domain name for which this record is valid.
TTL: standard DNS time to live field.
class: standard DNS class field (this is always IN).
priority: the priority of the target host, lower value means more preferred.
weight: A relative weight for records with the same priority.
port: the TCP or UDP port on which the service is to be found.
target: the canonical hostname of the machine providing the service.
Most modern DNS servers support SRV records.
Avahi advertises services (by port) that each machine offers. (aka Apple's Bonjour)
Not sure if it's exactly what you're looking for, but definately in this vein.
The concept is that each machine would announce what services it is running on each port.
But this is limited to a LAN implementation, which I'm not sure fits your requirements.
To add a little more meat to this answer, here is an example service file for Avahi advertising a webpage:
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h Web Server</name>
<service>
<type>_http._tcp</type>
<port>80</port>
</service>
</service-group>
I personally think zookeeper is a great fit for this use case. Ephemeral nodes mean that registration cleanup is not a problem, freeing you to use dynamic port allocation on the server side and watches will help with rebalancing client->server mappings. That said, using zookeeper for server side registration and using DNS SRV records for client side lookup(using a zookeeper to dns bridge) would work well for most use cases.