Bind Failing no Reason on some Clients

  • I have about 40 clients in a zone with a reverse zone as well that is across 4 subnets i.e x.x.1.1 x.x.2.1 x.x.3.1

    I have had corrupted jnl files in the bind DB that where not synced (for whatevrer reason)

    These days I cant add any new PTR records without dig failing to recognise them

    I am at a loss :(

    Here is a copy of my zone file … the last 2 entrys dont work dream2 and dreamdev

    $TTL 7200
    $ORIGIN greeta.local.

    ; Database file greeta.local.DB for greeta.local zone.
    ; Do not edit this file!!!
    ; Zone version 2477802727
    greeta.local. IN  SOA davinci.greeta.local. zonemaster.greeta.local. (
    2477802727 ; serial
    1d ; refresh
    2h ; retry
    4w ; expire
    1h ; default_ttl

    ; Zone Records
    @ IN NS davinci.greeta.local.
    @ IN A
    box IN A
    nas IN A
    davinci IN A
    ns1 IN CNAME  davinci.greeta.local.
    cisco IN A
    davinci IN A
    davinci IN A
    davinci IN A
    neptune IN A
    rabbit IN A
    venus IN A
    falcon IN A
    dream IN A
    cog-cont IN A
    code IN A
    cog-sql IN A
    octopus IN A
    qq IN A
    soa IN A
    mars IN A
    ready IN A
    bert IN A
    pluto IN A
    elvis IN A
    sqlprod IN A
    @ IN PTR
    saas IN PTR
    kermit IN PTR
    ernie IN PTR
    micro IN PTR
    fuckit IN PTR
    dream2 IN PTR
    dreamdev IN PTR

    Any help would be appreciated



    Cant even find itself

    Server:  UnKnown

    *** UnKnown can't find Server failed

    C:\WINDOWS\system32>dig davinci.greeta.local

    ; <<>> DiG 9.11.0 <<>> davinci.greeta.local
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31571
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

    ; EDNS: version: 0, flags:; udp: 4096
    ;davinci.greeta.local.          IN      A

    ;; Query time: 0 msec
    ;; SERVER:
    ;; WHEN: Mon Nov 21 18:16:22 AUS Eastern Daylight Time 2016
    ;; MSG SIZE  rcvd: 49

    C:\WINDOWS\system32> :(

  • LAYER 8 Global Moderator

    So did you delete the jnl files?  There is some other thread or redmine talking about editing the zone while its live causing issues.

  • A couple of  things

    1. I forget this is a Linux based and windows has made me extremely flipant in the way i do things…i.e bull in a china shop
    2. Having DHCP on a subnet with static DNS entries also means there are operations occurring at any/all times
    3. Delete the JNL files and FFS stop the Bind service when you are updating the DNS tables

    There is one rig that wont play ball out of about 60, but Im cool with that  ???

    Check the system Logs as they will tell you what the problem is when DNS resolution is failing

    Old Windows habbits of treating machines badly die hard but pfsense and my new friend ubuntu are setting me on the right path.

    I am converting all my services off MS based servers and onto ubuntu

  • To add some extra insight

    I was running a reverse zone across 4 subnets

    I have created a seperate 1.168.192inappra 2.168.192.inappra for each

    Also removed DHCP on prod and PreProd Subnets seem to have settled things to a certain extent

    I have replaced DIG on all all windows machines and was strange that DIG would fail but nslookup would not

    Have still not been able to get suffix domain lookup working on all but the primary subnet i.e

    I have been experiencing machines not resolving and then a couple of hours later they do. I am sure i am missing something as i cant believe things can be this troublesome


    P.S Learning Lots and Windows is dead to me ina  lot of ways ;)

  • Banned

    "1.168.192inappra" certainly is not a valid reverse zone declaration.

  • LAYER 8 Global Moderator

    What client you use to query shouldn't really matter..  So where do you doing query for any or something vs A..

    This stuff is really pretty basic troubleshooting.  But we need something to go off of.. like the output of your query, your exact query.  Your exact setup.  Log of bind when you did the query, etc.

Log in to reply