Difference between 'transparent' and 'nodefault' options

[Amanda Constant]

I am out of the office October 1st & 2nd and will respond to your message as quickly as possible once I return.

Amanda

On Oct 1, 2018, at 11:30 AM, Amanda Constant via Unbound-users <unbound-users at nlnetlabs.nl> wrote:

> I am out of the office October 1st & 2nd and will respond to your message as quickly as possible once I return.
> 
> Amanda
> 
> On Oct 1, 2018, at 11:27 AM, Amanda Constant via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
> 
> I am out of the office October 1st & 2nd and will respond to your message as quickly as possible once I return.
> 
> Amanda
> 
> On Oct 1, 2018, at 5:21 AM, Wouter Wijngaards via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
> 
> Hi Kees,
> 
> On 10/1/18 7:36 AM, K. de Jong via Unbound-users wrote:
> Hi,
> 
> 
> 
> I would like to know the difference between 'transparent' and
> 'nodefault'. Transparent sounds like a soft nodefault? When there is
> local-data it does a lookup there, if there is not it will continue
> looking for an answer, such as e.g. going through the forwarders? Is
> that correct? This could also mean it get's a reply from the AS112
> project if the address is private, right?
> 
> Yes it performs the local-data and if not there, continues to the
> upstream servers, like forwarders you have configured.  This could mean
> contacting servers from the AS112 project.
> 
> Unbound also has built-in answers for names from the AS112 namespace,
> and the nodefault makes it not process that so you can use that query
> for normal processing.
> 
> 
> Can someone also explain this sentence for me? "If no local-zone is
> given local-data causes a transparent zone to be created by default."
> What is this transparent zone? Why would it be created and if it is
> created, how can I see it?
> 
> As far as I understand is nodefault a way to use private addresses in
> your zone without having them 'answered' by the AS112 project, correct?
> 
> Without having them answered by the built-in namespace answers in
> Unbound for names in the AS112 namespace.  With that rephrase.
> 
> Transparent (and other local-zone types) implies nodefault.  If you say
> transparent you get also the benefits that nodefault would give.
> Transparent also allows you to add local-data statements, but if you
> have none, there is very little difference for you between transparent
> and nodefault.
> 
> 
> I have a stub-zone to an authoritative name server which has only
> private addresses in its zone. I guess I will need to use 'nodefault'
> for that? At the moment I use 'transparent', that works fine too. What
> kind of problems could I expect if I continue with 'transparent'?
> 
> No, I do not expect problems, I think you would be fine.
> 
> 
> Sorry for all the questions... I just want to clearly understand these
> options, at the moment I don't and I can't find other sources than the
> man page. Thank you.
> 
> Transparent also works for people who want to override like a couple of
> data elements but the rest uses normal upstream processing.  For zones
> that are not private.  Nodefault is used to turn of the build-in AS112
> namespace processing, so that these private namespace names and be used.
> 
> The created transparent zone is made if you give local-data but no
> local-zone statements.  It is simply a higher up domain node.  Not sure
> how to see if but perhaps with unbound-control.  However, I don't think
> you need to worry about it because you have specified the local-zone
> statements.
> 
> Best regards, Wouter
> 
> 
> 
> 
> 
> --
> Kind regards,
> Kees de Jong  |  OpenPGP fingerprint: 0x0E45C98AB51428E6
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________ 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4135 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181001/c6457c2b/attachment.bin>