I want to get all countries ip addresses range from IANA's whois server, Not from maxmind or ip2location site. IANA is authentic site hence I would like to get all ipaddress ranges for countries from that site. Is it possible to query the WHOIS server such a way??
Its not possible to directly get the ip addresses allotted to any country like that.
IP numbers are allocated to regional internet registries.
There are 5 of them , ARIN , APNIC , AFRINIC , LACNIC , RIPE
And again , these RIR allot ip ranges to ISPs of a country.
By doing a whois query for an ip you can find out which RIR is the IP allocated to. The whois response will also contain the country and ISP of the ip address.
Basically you need to whois-query all ip ranges and aggregate the data and form a database. Such a database can be then used to provide all ip addresses belonging to a certain country.
IANA does not have this information so, no, there is no way to get it from them.
IANA only allocates big IP prefixes to RIR (Regional Internet Registries). For instance 31.0.0.0/8 has just been allocated to the RIPE-NCC (by the way, one less IPv4 prefix, time to enable IPv6 if it is not already done), which covers all Europe and a good part of the Middle East. So, these adresses may go to Ireland, Jordan or Greece and you cannot tell it from IANA allocations. Even the RIR whois (whois.ripe.net for the RIPE-NCC) won't tell you with enough details because a prefix may be assigned to a multinational IAP (Internet Access Provider).
Related
I'm interested to know, how does WSAIoctl() with the SIO_ROUTING_INTERFACE_QUERY control code create the list of IP addresses of my host machine? In particular, what criteria does it use to order the IP addresses?
It only returns one! From MSDN (emphasis mine):
SIO_ROUTING_INTERFACE_QUERY (opcode setting: I, O, T==1)
To obtain the address of the local interface (represented as sockaddr structure) that should be used to send to the remote address specified in the input buffer ...
It's true that multiple routes to the destination address might exist, in which case it will no doubt pick the cheapest (routing table entries each contain a cost, or metric, see here).
Or did you mean SIO_ADDRESS_LIST_QUERY?, in which case Windows knows full well what network interfaces you have installed on your machine and the order in which they are returned is supremely unimportant.
A web designer friend of mine is moving a customer of hers to a new hosting provider but she wanted me to look at their email setup to make sure that nothing she was doing would affect their email. I did an assortment of MX record and dns record lookups and to me there seems to be something really strange with their mail setup. For example, there are two mx records where I'm used to seeing one (domain names and ip addresses are dummy's just to be safe): Pref: 10 hostname: mx.name.net ip address: 111.222.555.333 and the second Pref: 20 hostname: mx.ct.diffname.net ip address: 111.222.444.222 and neither "name" nor "diffnam" is their domain name. Then the dns entry for mail.theirdomain.net points to an address that's different from either the two addresses pointed to by the mx record.
I haven't setup a mail server in a while but I checked the last one I did and in the mx record the hostname was mail.domainname.org (and there was only one entry) and the address in the mx record was the same as the address in the mail.domainname.org dns entry.
I could understand if there were two MX records for either load balancing or fail-over in case the main server went down but the setup seems strange and the fact that the mail.domainname.com dns entry doesn't point to the same address as the mx record makes me think something is setup wrong in their email system. Does anyone have some insight into this?
mail.domainname.com has nothing to do with MX or SMTP; it's just a normal domain name.
It typically points to an HTTP server that serves webmail, which may or may not be the same as the SMTP server.
The point of having multiple MX records is in case one of them goes down.
In a DNS zone file, there are different entries that denote the type of service for which a canonical may be directed. One of these is the MX record which determines where services look for email SMTP access. The primary record is called the A record, which usually directs to the IP address(s) for web services and the primary domain.
Hope this helps!
I have a PostgreSQL table with a column (of type Text) 'ip_port'. This column has values like:
167.123.24.25:59874
This is IP:Port
And I'm trying to write a query to list all the subnets from those IP and a count of IPs in each subnet. Is there an elegant way of doing this in Postgres?
Thanks in advance!
You cannot do this - in PostgreSQL or any other tool - if the only information you have is the IP address. You must also know:
The broadcast address for the network;
The network subnet mask or mask prefix length; or
that pre-CIDR class-based address allocation is being used
Consider that a given IP is actually a member of multiple networks of increasing size. For the purpose of local area Ethernet-based IP networking there's a broadcast domain defined by the subnet mask, but there are also a nested set of increasingly broad routing aggregation domains for that address, some of which are visible on the public Internet and some of which are private to an internal network. The line between "public" and "private" can be blurry; for example, within my ISP's network their large network blocks are split into smaller chunks that are not visible from the outside world but are visible to the ISP's customers.
For example, a non-exhaustive list of networks for 167.123.24.25 might be, according to some quick calculations with the sipcalc tool:
167.123.24.25/32 (the host its self)
167.123.24.25/28: (a common ISP allocation): usable 167.123.24.17 - 167.123.24.30, netmask 255.255.255.240
167.123.24.25/24: (a common LAN subnet size): usable 167.123.24.1 - 167.123.24.254, netmask 255.255.255.0
167.123.24.25/20: (a midlevel routing aggregation): usable 167.123.16.1 - 167.123.31.254, netmask 255.255.240.0
167.123.24.25/16: The top-level APNIC allocation of this address block according to whois): usable 167.123.0.1 - 167.123.255.254, netmask 255.255.0.0
If you traceroute that address, consider that any of those routers might (but also might not) be the point at which the address becomes part of a narrower, more specific subnet. See Classless inter-domain routing on Wikipedia.
All that is before you even consider NAT (blech) and internal WAN routing. 167.123.24.25 might be a router for a whole hidden network of NATed hosts. These hosts are invisible to you from the outside without extremely sophisticated passive mapping that only someone close to them along their routing path can do.
To learn more about the address's network you have to do some serious probing to find out what addresses might be treated as broadcast addresses. Of course, most routers will filter packets destined for broadcast addresses from outside the local routing domain, so you might not be able to tell the difference between "host doesn't exist", "is a broadcast address" and "host exists but filters the packet I'm using for probing". Such probing is slow, and it'll also tend to make the network owners grumpy at you. Since this network is owned by the US Department of Public Works, I'd recommend not making them grumpy.
Below is a sample invoking of getaddrinfo()
status = getaddrinfo("www.example.net","1234", &hints, &server_info);
After that, the server_info will point to a linked list with all kinds of address information.
I have the following questions:
Since I have clearly specified the host name and port number, the only address infos I can think of are IPv4 and IPv6 addresses. So, the length of the linked list should be 2. Is there any other kind of address info besides them?
Thanks.
The name could resolve to more than one IPv4 or IPv6 address, there is nothing to say that only one IPv4 address will be returned, for example (try it with "www.google.com" for example, you'll likely get more than one IPv4 address).
But in any case, I think the basic premise of your question is wrong. Even if there was no possibility to return more than one IPv4 and one IPv6 address today, the function is documented to return an arbitrarily-long linked list of addrinfo objects. Therefore, even if your code worked today in every situation, there is no guarantee that it would continue to work tomorrow. If the function is documented to return an arbitrarily-long linked list, then you need to be able to handle that.
You want to disconnect the physical configuration of machines with names in your mind. DNS merely maps a name to a set of addresses. A lot of hosts will only have one interface. Many hosts will have multiple (called multi-homing). DNS doesn't care about what the configuration of the machine or machines that the addresses it maps a name to is. As simple examples often a server will have interfaces on multiple networks with different addresses that will all map to the same name. Sometimes when collapsing services from different machines onto one different names will map to the same address. So don't assume any sort of 1:1 mapping between names and machines much less interfaces.
When browsers look up hostnames, do they do that even when the "host name" is an IP address? For instance http://74.125.39.105/ goes to some Google servers. Will this result in a DNS lookup on common browsers and platforms, such as Safari, IE, Firefox, Chrome, Opera, Windows, Linux, Mac OSX?
Or will the browser (in the common case) just start a connection directly without trying a DNS lookup first?
There is no DNS lookup done if the entire host part is numeric in nature. It could be in dotted quad format, or a single unsigned 32 bit integer. I haven't tested IPv6 yet.
There's no point in performing a lookup as there are no authoritative DNS records for these numeric "names".
Some recursive nameservers (e.g. dnscache) will respond to these kind of queries with the corresponding IP address, as if there was a real record of the form:
74.125.39.105. IN A 74.125.39.105
but this is, I assume, intended to deal with simplistic clients that assume everything is a DNS name. The most common nameserver, BIND, doesn't have this behaviour though - so don't rely on it.