"Timeout" DNS IP to name resolution

Discussion in 'Linux Networking' started by buck, Jun 23, 2012.

  1. buck

    buck Guest

    I run a rather busy Apache web server with HostnameLookups On because
    management wants it so.

    The problem is IP addresses that don't resolve. There are 2
    possibilities, one of which is that name resolution immediately fails,
    returning a blank/empty set and the other is that the name resolution
    attempt times out. "Timeout resolution" is causing problems with

    My method for working around this is to DROP all requests on port 80
    that originate from IP address blocks that time out...

    This is difficult for me to explain, so please cut me some slack. I
    [think|hope] that timeout violates internet standards. Your help with
    a politely worded and explicit explanation to the network admin, along
    with a description of at least one good way for [him|her] to correct
    the problem, is solicited.

    1) What is the difference between immediate return of blank/empty set
    and timeout?

    2) Is there an RFC I can read, and perhaps send to the offending
    network administrator, that recommends (or stronger) that IP addresses
    which are not to be resolved return blank?
    buck, Jun 23, 2012
    1. Advertisements

  2. buck

    Chris Davies Guest

    I suspect by your phrasing that this isn't a choice you yourself would
    have made. Is there any mileage in offering near real-time post-resolution
    of names? So Aapche would write IP addresses, and you'd have something
    along the lines of this -

    tail -f access.log |
    while read IP OTHERSTUFF
    NM=`dig +short -x $IP`; echo "${NM:-$IP} $OTHERSTUFF"
    done > access_with_dns.log

    (Don't use that code; it's only to illustrate the idea.)

    The first is a definitive "there is no information available". But you
    can't (shouldn't) draw any definitive conclusions from the second. Maybe
    the network was a little slow today. Maybe your UDP packets or the
    answers got dropped somewhere en route. Maybe the far end's rDNS really
    is misconfigured.

    If you're working in a constrained and more controlled situation than
    the Internet at large, then maybe some of these assumptions are less
    likely to apply.

    Chris Davies, Jun 23, 2012
    1. Advertisements

  3. buck

    buck Guest

    That will work for some reports.
    You say "misconfigured". Does that mean that rDNS is SUPPOSED to be
    up? If so, are you able to cite a reference.

    FWIW and for an example, any ip in the range thru times out so this is not a "busy" situation.

    Thanks for the pseudo code.
    buck, Jun 24, 2012
  4. Hello,

    buck a écrit :
    Any DNS query should get a reply, either positive or negative, from an
    authoritative DNS server.
    $ dig -x @ns2.xaonline.com.

    ; <<>> DiG 9.7.3 <<>> -x @ns2.xaonline.com.
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49606
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
    ;; WARNING: recursion requested but not available

    ; IN PTR


    114.124.in-addr.arpa. 43200 IN NS ns1.xaonline.com.
    114.124.in-addr.arpa. 43200 IN NS ns2.xaonline.com.

    ns1.xaonline.com. 86400 IN A
    ns2.xaonline.com. 86400 IN A

    ;; Query time: 516 msec
    ;; SERVER:
    ;; WHEN: Sun Jun 24 11:49:38 2012
    ;; MSG SIZE rcvd: 182

    $ dig -x @ns1.xaonline.com.

    ; <<>> DiG 9.7.3 <<>> -x @ns1.xaonline.com.
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41200
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available

    ; IN PTR

    114.124.in-addr.arpa. 43200 IN SOA localhost.localdomain.
    root.localhost.localdomain. 2007022012 10800 3600 604800 86400

    ;; Query time: 510 msec
    ;; SERVER:
    ;; WHEN: Sun Jun 24 11:49:02 2012
    ;; MSG SIZE rcvd: 108
    Pascal Hambourg, Jun 24, 2012
  5. buck

    Chris Davies Guest

    I had a quick look through RFCs 1034 and 1035 yesterday evening but
    couldn't a definite statement. In your situation I suspect that my
    *opinion* is irrelevant, but FWIW I would say that you *should* get some
    sort of response for any DNS enquiry, whether forward or reverse.

    I get rDNS for so maybe this is a peering/routing issue
    from your (upstream) provider(s)?

    Chris Davies, Jun 24, 2012
  6. buck

    Moe Trin Guest

    On Sun, 24 Jun 2012, in the Usenet newsgroup comp.os.linux.networking, in

    The DNS RFCs were written before RFC2119 (Key words for use in RFCs to
    Indicate Requirement Levels) so there isn't a specific sentence that
    says PTR records "MUST" (or even "SHOULD") exist.
    RFC 2050 Internet Registry IP Allocation Guidelines section 5
    RFC 2181 Clarifications to the DNS Specification section 10.2
    RFC 2317 Classless IN-ADDR.ARPA delegation entire doc.

    none of which are "STANDARD" track documents.
    It seems that things fall into three main classes:

    1. That information is SECRET - I don't want you to know it
    2. It's too HARD to set up
    3. What's a reverse zone

    This has been an on-going problem for many years - mail administrators
    often configure their mail servers to reject mail from systems that
    don't resolve, or where the forward and reverse names don't match up.
    See question 3.22 in the Sendmail-FAQ as one example.

    Old guy
    Moe Trin, Jun 24, 2012
  7. buck

    buck Guest

    [Moe Trin|Olg Guy]

    My reading of 1035 says NO, reverse is not required, but others
    disagree so what do I know?! All the RFCs I read that talk about
    Email say that rDNS is NOT required, so I presume that the same goes
    for http.

    Pascal & Chris,

    Thanks. I changed to a different nameserver and get the expected

    I'm confounded because only 4 netblocks (so far) were timing out, but
    since they no longer do I really don't care to pursue this.
    buck, Jun 24, 2012
  8. buck

    Moe Trin Guest

    On 24 Jun 2012, in the Usenet newsgroup comp.os.linux.networking, in
    Don't forget that the RFCs are written to create interoperability.
    There is no such thing as the Internet Police to enforce them.
    Correct - you have to understand that the Internet is a cooperative
    grouping of networks. Barring some legal contract between entities,
    there is nothing that _requires_ network A to carry traffic to/from
    network B. A frequently heard statement in the now defunct Usenet
    newsgroup "news.admin.net-abuse.blocklisting" was "my network - my
    rules". A lot of network abuse was reported from systems and/or
    networks that failed to had working or matching name resolution, and
    that's why some admins made "proper DNS" as a pre-requisite for
    receiving mail (or even just traffic).

    Old guy
    Moe Trin, Jun 25, 2012
  9. buck

    J G Miller Guest

    But it would appear that in some countries there are police to
    control the internet (but not enforce the RFCs).


    November 27th, 2010

    Nominet Plans to Let Police Control UK Internet

    Nominet – the quasi-private entity which controls the .uk part
    of the internet - plans to allow the police to take down any
    website without recourse to the Courts.

    This is at the request of the Serious Organised Crime Agency.


    which has become de facto policy


    UK Domain Seizures: Nominet Admits It's Helped Police Seize 3,000 Sites

    While we've been mostly focused on US-based domain name seizures and attempts
    to expand them using something like COICA, we've also noted that similar issues
    are being discussed in the UK, where Nominet has now admitted that it's helped
    police seize about 3,000 domains based simply upon a request from law enforcement.

    Unlike the US, there isn't even a formal process with a judge rubber stamping
    the requests. Instead, the police ask, and Nominet is compelled to suspend the domain.

    In fact, some law enforcement officials are claiming that if Nominet refused their
    requests, then it would automatically become liable. In other words, police have
    a fantastic tool for censorship of any website if they want to use it that way.


    Welcome to the Internet controlled police state.
    J G Miller, Jun 25, 2012
  10. buck

    MJ Guest

    Management would be well-advised to allow you to use the Perl script
    named "jdresolve" to resolve IP addresses whenever any logfile analyses
    are needed, or subsets thereof. It can quickly recurse through any
    addresses to resolve domains for which A or PTR records don't exist (such
    as your point of failure), e.g.:

    $ echo | jdresolve -n -a -r -
    $ echo | jdresolve -n -a -r -

    or entire files:

    # jdresolve -r -n -a /var/log/apache.log > /tmp/resolved.apache.log

    Your management will be highly pleased with your creative shell-scripted
    uses of the program, I promise.

    An example "probe_report" script output of dropped, logged, unsolicited
    packets from iptables:

    # /usr/local/bin/probe_report

    Resolved_Address Packets Bytes Protocol(s) Dest.Port(s) 1 28 ICMP 1 44 TCP 22
    acyv254.neoplus.adsl.tpnet.pl 1 44 TCP 110 210 82600 UDP 631 1 44 TCP 8080
    Totals 214 80.8KB for search pattern
    MJ, Jun 27, 2012
  11. buck

    buck Guest

    jdresolve only resolves 60% of the IPs encountered by my web server
    yesterday. That's not good enough,
    buck, Jun 29, 2012
  12. buck

    Joe Beanfish Guest

    Not all IPs have names. Those will never resolve.
    Question is whether jdresolve resolves any fewer than apache?
    Joe Beanfish, Jun 29, 2012
  13. Tell management that if they really want this, they need something like
    10 times the amount of webservers to handle the same amount of requests.
    And even then, there are no guarentees, so 20 times the amount of
    webservers would be even better. If they are willing to invest this kind
    of money fine. If not, point them to the alternatives given in this

    rDNS requests can and will time out for various reasons, legitimate or
    not. It's easier to resolve afterwards. This may mean that you see some
    rDNSses that are not the same as at the moment the request came in to
    your webserver, but hey, rDNS is informative anyhow. People can set it up
    to whatever they like, so it cannot be relied on anyhow.

    Another idea would be to logrotate-post-process the logs to do the rDNS
    then. Maybe that's acceptable?

    Martijn Lievaart, Jun 29, 2012
  14. buck

    buck Guest

    Since Apache is now happy, I just reported my jdresolve "60% problem"
    for those who stumble across this thread.

    Apache does a lot better than jdresolve at rDNS. My upstream has 3
    servers, 2 of which I'll call "balky" because they sometimes work and
    sometimes/often fail. Since I set up the system to use the one server
    that always works, the problem has been alleviated. Now, only a few
    timeouts a day occur.

    I think the problem with jdresolve is the Net::DNS Perl module it
    requires. If it were to become necessary, I could get the jdresolve
    script worked on to become hierarchical, first trying a caching DNS on
    the LAN, then the upstream NS, and finally - as a "last resort" effort
    - the root servers. But that isn't likely because the only benefits I
    find in jdresolve are that the IP can be anywhere in the logged line
    and that recursion can be turned on. Neither of those things are
    presently necessary.
    buck, Jun 30, 2012
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.