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.
Related
I noticed that one of Google's mail servers (alt4.aspmx.l.google.com) points to 74.125.200.26, but when I do a reverse DNS lookup on that IP I see that the hostname associated with it is sa-in-f26.1e100.net. My limited understanding of DNS is that when you have a situation like that, one hostname is an alias of the other, but that's not the case here.
My initial goal was making a Python program that given an IP address and a hostname, returns a boolean answer indicating whether the IP belongs to a mail server of that domain. The algorithm I implemented used dig to search all mail servers of a domain and then tried to match any of them to the hostname associated with the given IP (which I found using dig -x). My program fails with the case I mentioned before. What am I missing?
Sorry for my bad english. Thanks!
Many services can run on one server/ipaddress, and many hostnames can resolve to one IP address. In the other direction, one ip address will most often resolve to only one hostname (if it has PTR record at all), and the name will very often be something generic like ip-xx-yy-zz-qq.networkcarrier.net (so unrelated to any of the services that are legitimately running on that server).
Depending on the purpose of your check, perhaps you can just test if the hostname A record points to the required IP address (because your initial requirement is flawed: ip addresses do not belong to domains, they belong to network providers).
(Still, for some purposes, most notably as anti spam measure, there is a use case for checking if ip address resolves to some particular hostname.)
I'm working on a program that tracks when search engines cannot find important files on my server.
From my computer I typed:
nslookup google.com
and I received 11 IP addresses in return all beginning with 74.125.226
I then tried:
dig google.com
and I still receive the same IP addresses.
When I navigate to here through searching: http://www.iplists.com/google.txt, the number of IP addresses is greater than 10 and that list includes ones starting with 64.249 which also appears in my server log.
Am I using the wrong linux tools to find every IP address associated with google? If so, what tools should I use?
I want to generate the IP address database myself rather than rely on someone's post of IP addresses just in case IP addresses are updated in the future.
The keyword here is GeoDNS: When website/service has many servers around the world (with the main purpose of providing the lowest possible latency to user requests), using GeoDNS it can respond with different IP addresses to DNS queries for the same hostname, based on the locaton of the DNS client that is making the query (of course it will try to respond with the IP address of the closest server).
Basically, there is no way you can retrieve all possible addresses just by querying DNS from one location. Also, google can add/remove/change addresses/servers on daily basis so you probably can never have the definite list (unless google publishes it somewhere).
The real-time example, this might help you:
https://www.whatsmydns.net/#A/www.google.com
Additional reading:
What is the difference between Anycast and GeoDNS / GeoIP wrt HA?
Can anybody tell me how the domain name service (searching for the IP of a website) starts?
Or in other words, what happens after I type a web address (say www.google.com) in a browser, press enter and before the DNS server start searching. Is there any communications between my browser and some port of my computer; between the ports of my computer to that of my ISP DNS server?
Many thanks in advance!
You hit enter, the browser services your request by making a network DNS query, queries the DNS server, the DNS server resolves the 'web address' to an IP address. From here on out, the IP address handshake begins to set up the connection between you and the web server.
There are more specifics in each one of these steps that I have not touched on, but here is some info:
1.
DNS primarily uses User Datagram Protocol (UDP) on port number 53 to
serve requests. DNS queries consist of a single UDP request from the
client followed by a single UDP reply from the server. The
Transmission Control Protocol (TCP) is used when the response data
size exceeds 512 bytes, or for tasks such as zone transfers. Some
resolver implementations use TCP for all queries.
2.
There are two types of DNS messages: queries and replies, and they
both have the same format. Each message consists of a header and four
sections: question, answer, authority, and additional. The header
field "flags" controls the content of these four sections but the
structure of all DNS messages are the same.
3.
The Domain Name System specifies a set of various types of resource
records (RRs), which are the basic information elements of the domain
name system. Each record has a type (name and number), an expiration
time (time to live), a class, and type-specific data. Resource records
of the same type are described as a resource record set (RRset).
Short Question :
Since DNS is anycast, is there any way for a DNS Server to know the "first" source DNS Query originated from?
Long Question :
I've developed a custom DynDNS server using PowerDNS, I want to feed it information via web interface by users. I want the web interface to update records for each user "based on IP".
So when the DNS Server gets requests, If it could determine the source IP, it'd be easy to return records associated with that IP.
As long as I tested, the DNS Server can only know the "last" node IP on the DNS chain, not the source. Is there any way?
Regards
Google and Yahoo! submitted a draft (draft-vandergaast-edns-client-ip-01) to the IETF DNS Extensions Working Group that proposed a new EDNS0 option within DNS requests that recursive servers could use to indicate their own client's IP address to the upstream authoritative server.
The intent was to theoretically optimise the use of Content Delivery Networks by ensuring that the web server addresses returned were based on the end user's IP address, rather than on the address of the end user's DNS server.
The idea was not well received and wasn't accepted by the working group because it intentionally broke the caching layer of the DNS, and the draft has subsequently expired.
UPDATE - a variation on this has subsequently been published as RFC 7871.
Perhaps you have control of the software performing the lookup? If so, you could include the IP address as part of the request, e.g.
23-34-45-56.www.example.com
to which your custom-written server replies
23-34-45-56.www.example.com 1800 CNAME www-europe.example.com
or
23-34-45-56.www.example.com 300 A 34.45.56.67
etc.
If the client is a web browser, complications arise due to NAT, HTTP proxies, and the inability to query host interface addresses directly from Javascript. However, you might be able to do an AJAX-style lookup to a what's-my-ip service, which understands X-Forwarded-For.
Long answer to Short Question :
DNS is not anycast. Some content DNS server owners use anycasting to distribute servers in multiple physical locations around the world, but the DNS/UDP and DNS/TCP protocols themselves are not anycast. The notion simply doesn't exist at that protocol layer.
Short answer to Long Question :
No.
Expansion
As noted, there's nothing in the DNS protocol for this. Moreover, the relationship between front-end and back-end transactions at a caching resolving proxy DNS server is not one-to-one.
You'll have to use whatever client differentiation mechanisms exist in the actual service protocol that you're using, instead of putting your client differentiation in the name→IP address lookup mechanism. Client differentiation for other services doesn't belong in name→IP address lookup, anyway. Such lookup is common to multiple protocols, for starters. Use the mechanisms of whatever actual service protocol is being used by the clients who are communicating with your servers.
Imagine a user sitting at an Ethernet-connected PC. He has a browser open. He types "www.google.com" in the address bar and hits enter.
Now tell me what the first packet to appear on the Ethernet is.
I found this question here: Interview Questions on Socket Programming and Multi-Threading
As I'm not a networking expert, I'd like to hear the answer (I'd assume it is "It depends" ;) ).
With a tool like Wireshark, I can obviously check my own computers behaviour. I'd like to know whether the packets I see (e.g. ARP, DNS, VRRP) are the same in each ethernet configuration (is it dependent on the OS? the driver? the browser even :)?) and which are the conditions in which they appear. Being on the data-link layer, is it maybe even dependent on the physical network (connected to a hub/switch/router)?
The answers that talk about using ARP to find the DNS server are generally wrong.
In particular, IP address resolution for off-net IP addresses is never done using ARP, and it's not the router's responsibility to answer such an ARP query.
Off-net routing is done by the client machine knowing which IP addresses are on the local subnets to which it is connected. If the requested IP address is not local, then the client machine refers to its routing table to find out which gateway to send the packet to.
Hence in most circumstances the first packet sent out will be an ARP request to find the MAC address of the default gateway, if it's not already in the ARP cache.
Only then can it send the DNS query via the gateway. In this case the packet is sent with the DNS server's IP address in the IP destination field, but with the gateway's MAC address on the ethernet packet.
You can always download wireshark and take a look.
Though to spoil the fun.
Assuming, the IP address of the host is not cached, and the MAC address of the DNS server is not cached, the first thing that will be sent will be a broadcast ARP message trying to find out the MAC address of the DNS server (which the router will respond to with its own address).
Next, the host name will be resolved using DNS. Then the returned IP address will be resolved using ARP (again the router will respond with its own address), and finally, the HTTP message will actually be sent.
Actually, it depends on a variety of initial conditions you left unspecified.
Assuming the PC is running an operating system containing a local DNS caching resolver (mine does), the first thing that happens before any packets are sent is the cache is searched for an IP address. This is complicated, because "www.google.com" isn't a fully-qualified domain name, i.e. it's missing the trailing dot, so the DNS resolver will accept any records already in its cache that match its search domain list first. For example, if your search domain list is "example.com." followed by "yoyodyne.com." then cached resources matching the names "www.google.com.example.com." "www.google.com.yoyodyne.com." and finally "www.google.com." will be used if available. Also note: if the web browser is one of the more popular ones, and the PC is running a reasonably current operating system, and the host has at least one network interface with a global scope IPv6 address assigned (and the host is on a network where www.google.com has AAAA records in its DNS horizon), then the remote address of the server might be IPv6 not IPv4. This will be important later.
If the remote address of the Google web server was locally cached in DNS, and the ARP/ND6 cache contains an entry for the IPv4/IPv6 address (respectively) of a default router, then the first transmitted packet will be a TCP SYN packet sourced from the interface address attached to the router and destined for the cached remote IPv4/IPv6 address. Alternatively, the default router could be reachable over some kind of layer-2 or layer-3 tunnel, in which case, the SYN packet will be appropriately encapsulated.
If the remote address of the Google web server was not locally cached, then the host will first need to query for the A and/or AAAA records in the DNS domain search list in sequence until it gets a positive response. If the first DNS resolving server address in the resolver configuration is in one of the local IPv4 subnet ranges, or in a locally attached IPv6 prefix with the L=1 bit set in the router advertisement, and the ARP/ND6 cache already contains an entry for the address in question, then the first packet the host will send is a direct DNS query for either an A record or a AAAA record matching the first fully-qualified domain name in the domain search list. Alternatively, if the first DNS server is not addressable on-link, and a default router has an ARP/ND6 cache entry already, then the DNS query packet will be sent to the default router to forward to the DNS server.
In the event the local on-link DNS server or a default router (respectively, as the case above may be) has no entry in the ARP/ND6 cache, then the first packet the host will send is either an ARP request or an ICMP6 neighbor solicitation for the corresponding address.
Oh, but wait... it's even more horrible. There are tweaky weird edge cases where the first packet the host sends might be a LLMNR query, an IKE initiation, or... or... or... how much do you really care about all this, buckaroo?
It depends
Got that right. E.g. does the local DNS cache contain the address? If not then a DNS lookup is likely to be the first thing.
If the host name is not in DNS cache nor in hosts file, first packet will go to DNS.
Otherwise, the first packet will be HTTP GET.
Well, whatever you try to do, the first thing happening is some Ethernet protocol related data. Notably, Ethernet adapters have to decide whether the Ethernet bus is available (so there's some collision detection taking place here)
It's hard to answer your question because it depends a lot on the type of ethernet network you're using. More information on Ethernet transmission can be found here and here