Forum Discussion

Mittal_119693's avatar
Mittal_119693
Icon for Nimbostratus rankNimbostratus
Sep 27, 2013

DNS::return issue

In DNS_request event, I'm using DNS::return after matching a specific condition but I noticed even after matching specific condition and skipping further TCL processing the irule continues to process remaining code.

 

For example in below irule after condition is met the irule set match=1 and instead of going to DNS response it still continues with irule and set match=0.

 

when DNS_Request {

 

if (condition == 1) { set match 1 DNS::return }

 

set match 0 }

 

when DNS_Response { if (match) ... } }

 

I'm using LTM 11.4 with DNS service addon.

 

7 Replies

  • I faced a similar issue a while ago. You may want to use (elements of) the following syntax to prevent further processing:

    drop
    event disable all
    return
    
  • Thanks for your reply. I can't used drop as I require to respond the dns query. I tried "event disable all" and return but it didn't work still it continues to process further rule.

     

    • StephanManthey's avatar
      StephanManthey
      Icon for MVP rankMVP
      What exactly do you want to achieve? Is there a pool behind the virtual. Do you create an own response inside your iRule? I will have a little spare time on Monday to look after it. Going offline now for the weekend.
  • I am thinking "return" should be what you need, are you sure it does not actualy work? Maybe you should open a case with Support if that is the case:

    when DNS_Request {
      if (condition == 1) { 
        set match 1 
        DNS::return 
        return
      }
      set match 0 
    }
    
  • Thanks Mohamed and Stephan.

     

    @Stephan - I misunderstood return command with DNS::return instead of tcl return. I tried return and the call jumps out of the event. @Mohamed - Thanks for the clarification.

     

  • Hi Mit,

     

    thanks for the update from your side. In my answer I also mentioned the 'event' command. Perhaps you want to skip the processing in context of DNS_RESPONSE or you have a second iRule with a lower priority attached to your virtual server. The 'event disable' will prevent the triggering of lower prioritized events of same types while the 'event disable all' will also avoid the processing in context of i.e. DNS_RESPONSE.

     

    Some sample code for testing and verification attached. Make sure to use the udp_gtm_dns profile (w/ datagram load balancing).

     

    Thanks, Stephan

     

    when DNS_REQUEST {
    
        log local0. "request for [DNS::question name] [DNS::question class] [DNS::question type]"
        switch [DNS::question type] {
            A       {
                    DNS::answer insert "[DNS::question name]. 30 [DNS::question class] [DNS::question type] 10.245.245.101"
                    DNS::return
                    event disable all
                    return
                }
            AAAA    {
                    DNS::answer insert "[DNS::question name]. 30 [DNS::question class] [DNS::question type] 2001:0:0:f5::101"
                    DNS::return
                    event disable all
                    return
                }
            CNAME   {
                    DNS::answer insert "[DNS::question name]. 30 [DNS::question class] [DNS::question type] alias.lb-net.bit"
                    DNS::return
                    event disable all
                    return
                }
            default {
                    pool pool_dns
                }
        }
    }
    when LB_SELECTED  {
    
        log local0. "[LB::server] selected"
    }
    when DNS_RESPONSE {
    
        foreach item [DNS::answer] {
            log local0. "[DNS::rdata $item] [DNS::type $item]"
        }
    }