different result between normal query and zone transfer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

different result between normal query and zone transfer

MAYER Hans-2


Dear All,

In my environment we have internal DNS servers and 6 external server all running BIND.
4 of these 6 are located in our network. These are slaves for our domain and fetching the data from one internal server.
And the remaining 2 are maintained by our ISP and doing a zone transfer from our external server.
For some reason we want to have that one DNS name get resolved different depending if the query goes to the internal server or to the external.
So I configured in the external DNS server a subzone which overrides the information coming from the internal server.
This works really fine for our internal and external server. I get the answer I expect.
But not so if the servers of our ISP are queried. There I get the data which was originally defined in our internal DNS server.
The same issue if I do a zone transfer with "dig axfr" from our external server.

For me this looks like a bug. Why is the answer for a normal query different than the answer from a zone transfer ?
Or do I miss a special flag for this setup ?
I am using BIND 9.11.1 <id:e3dc2e7> but I had the same issue with older versions too.

BTW: I tried the same with RPZ but there I have the identical issues.


Kind regards
Hans

--

This is the part of "named.conf"

zone "test44.iiasa.ac.at" in {
  type master ;
  file "db.test44.iiasa.ac.at" ;
} ;

This is the db-file of our external DNS server.

#  cat "db.test44.iiasa.ac.at"

$TTL 3600
$ORIGIN test44.iiasa.ac.at.

@       IN SOA ns2.iiasa.ac.at.  dnsmaster.localhost. (
                                2222000000       ; serial
                                21600      ; refresh (6 hours)
                                3600       ; retry (1 hour)
                                1209600    ; expire (2 weeks)
                                86400      ; minimum (1 day)
                                )
@       IN             NS      ns2.iiasa.ac.at.
test44.iiasa.ac.at. 600 IN A 147.125.5.5
test44.iiasa.ac.at. 600 IN AAAA 2001:628:21f0:5::5:5

Here a normal query from anywhere

# dig +short test44.iiasa.ac.at @ns2.iiasa.ac.at
147.125.5.5

And here a zone transfer from an IP where a zone transfer is allowed

# dig axfr iiasa.ac.at @ns2.iiasa.ac.at | grep test44
test44.iiasa.ac.at.     86400   IN      AAAA    2001:628:21f0:4::4:4
test44.iiasa.ac.at.     86400   IN      A       147.125.4.4




_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: different result between normal query and zone transfer

Steven Carr
On 6 July 2017 at 12:29, MAYER Hans <[hidden email]> wrote:
> For me this looks like a bug. Why is the answer for a normal query different than the answer from a zone transfer ?
> Or do I miss a special flag for this setup ?
> I am using BIND 9.11.1 <id:e3dc2e7> but I had the same issue with older versions too.

A zone transfer is transferring the contents of the zone, the zone in
question is 'iiasa.ac.at', but you've also created a subzone
'test44.iiasa.ac.at' which is a completely separate point of
administration that just happens to hide records inside of the parent
zone. So on your slaves you will also need to slave the subzone if you
want it to override the records there.

A query will traverse the tree until it finds the lowest point of
delegation with which to obtain a response from.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: different result between normal query and zone transfer

MAYER Hans-2

Hi Steven,

Many thanks for your answer.
Isn’t there a flag or option to say handle all sub-zones like normal A or CNAME records too ?

// Hans



> On 6 Jul 2017, at 15:05, Steven Carr <[hidden email]> wrote:
>
> On 6 July 2017 at 12:29, MAYER Hans <[hidden email]> wrote:
>> For me this looks like a bug. Why is the answer for a normal query different than the answer from a zone transfer ?
>> Or do I miss a special flag for this setup ?
>> I am using BIND 9.11.1 <id:e3dc2e7> but I had the same issue with older versions too.
>
> A zone transfer is transferring the contents of the zone, the zone in
> question is 'iiasa.ac.at', but you've also created a subzone
> 'test44.iiasa.ac.at' which is a completely separate point of
> administration that just happens to hide records inside of the parent
> zone. So on your slaves you will also need to slave the subzone if you
> want it to override the records there.
>
> A query will traverse the tree until it finds the lowest point of
> delegation with which to obtain a response from.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: different result between normal query and zone transfer

Steven Carr
On 9 July 2017 at 06:14, MAYER Hans <[hidden email]> wrote:
> Many thanks for your answer.
> Isn’t there a flag or option to say handle all sub-zones like normal A or CNAME records too ?

Not that I'm aware of. You might want to look at DNS Views to present
different responses instead of overriding with a subzone.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: different result between normal query and zone transfer

Darcy Kevin (FCA)
In reply to this post by MAYER Hans-2
The bottom line is that a *zone* is the basic administrative unit of AXFR/IXFR-based replication. If you create a new zone and you want a replica to serve it, you need to configure the replica to replicate it. There is no "automatic" mechanism within BIND to tell replicas to start slaving new zones. If you have a common provisioning/configuration-control mechanism, then this can be quite convenient, but it sounds like this is between you and your ISP, so I assume that no such common framework exists. You have to follow their procedures for getting the new zone transfer definition established, whether that be a phone call, an email, filling out an online form, something like that.

                                                                                        - Kevin



-----Original Message-----
From: bind-users [mailto:[hidden email]] On Behalf Of MAYER Hans
Sent: Sunday, July 09, 2017 1:14 AM
To: [hidden email]
Subject: Re: different result between normal query and zone transfer


Hi Steven,

Many thanks for your answer.
Isn’t there a flag or option to say handle all sub-zones like normal A or CNAME records too ?

// Hans



> On 6 Jul 2017, at 15:05, Steven Carr <[hidden email]> wrote:
>
> On 6 July 2017 at 12:29, MAYER Hans <[hidden email]> wrote:
>> For me this looks like a bug. Why is the answer for a normal query different than the answer from a zone transfer ?
>> Or do I miss a special flag for this setup ?
>> I am using BIND 9.11.1 <id:e3dc2e7> but I had the same issue with older versions too.
>
> A zone transfer is transferring the contents of the zone, the zone in
> question is 'iiasa.ac.at', but you've also created a subzone
> 'test44.iiasa.ac.at' which is a completely separate point of
> administration that just happens to hide records inside of the parent
> zone. So on your slaves you will also need to slave the subzone if you
> want it to override the records there.
>
> A query will traverse the tree until it finds the lowest point of
> delegation with which to obtain a response from.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: different result between normal query and zone transfer

Tony Finch
Darcy Kevin (FCA) <[hidden email]> wrote:

> There is no "automatic" mechanism within BIND to tell replicas to start
> slaving new zones.

Fans of new features pop up in response to say, you might be able to use
catalog zones to automatically configure replication :-)

https://kb.isc.org/article/AA-01401/0/A-short-introduction-to-Catalog-Zones.html

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northwest 5 or 6, decreasing 4 at times, then occasionally
7 later. Moderate or rough, occasionally slight in far southeast. Occasional
rain in north. Good, occasionally moderate in north.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: different result between normal query and zone transfer

Reindl Harald


Am 10.07.2017 um 18:48 schrieb Tony Finch:
> Darcy Kevin (FCA) <[hidden email]> wrote:
>
>> There is no "automatic" mechanism within BIND to tell replicas to start
>> slaving new zones.
>
> Fans of new features pop up in response to say, you might be able to use
> catalog zones to automatically configure replication :-)
>
> https://kb.isc.org/article/AA-01401/0/A-short-introduction-to-Catalog-Zones.html

This guide shows the basic usage of catalog zones - how to add set up a
master and slave provisioned using catalog zone, how to add a new zone
to the catalog zone and how to possibly automate it. In this guide we'll
be using three servers - master running on 10.53.0.1 and two slaves
running on 10.53.0.2 and 10.53.0.3. To make it easier to try out this
example on your own system, we are using unprivileged ports 5300 and
9953, for DNS and RNDC respectively.

well, bind10 is dead so far and at least no longer a ISC project
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: different result between normal query and zone transfer

Tony Finch
Reindl Harald <[hidden email]> wrote:
>
> well, bind10 is dead so far and at least no longer a ISC project

Catalog zones are a BIND 9.11 feature.

https://kb.isc.org/article/AA-01432/81/BIND-9.11.0-Release-Notes.html#relnotes_features

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/  -  I xn--zr8h punycode
Forth, Tyne, Dogger, Fisher, North German Bight: Cyclonic 4 or 5, increasing 6
at times. Slight or moderate. Rain or thundery showers. Good, occasionally
poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Loading...