Re: [nznog] NZNOG Digest, Vol 129, Issue 1
Hi Paul,Thanks for the assistance and pointing out a glaringly obvious
problem :S.
NS records are all fixed but not seeing the delegation still. Should this
happen now automatically or do Orcon still need to do something? I've now
learnt how to use the Dig command but can't figure out how to trace it like
in other posts.
Thanks,Jonathan
Jonathan Spence
Chief Information Officer
Mobile: +64-21-1055634
Work: +64-9-9503306
Web: power-business.co.nz
The information contained in this message is privileged and intended only
for the recipient names. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. Views expressed in this message
may notnecessarily be those of Power Business Services Limited. If you have
received this message in error, please immediately notify the sender, and
delete the original message and attachments.
----------------------------------------
From: nznog-request(a)list.waikato.ac.nz
Sent: Monday, September 2, 2013 12:00 PM
To: nznog(a)list.waikato.ac.nz
Subject: NZNOG Digest, Vol 129, Issue 1
Send NZNOG mailing list submissions to
nznog(a)list.waikato.ac.nz
To subscribe or unsubscribe via the World Wide Web, visit
http://list.waikato.ac.nz/mailman/listinfo/nznog
or, via email, send a message with subject or body 'help' to
nznog-request(a)list.waikato.ac.nz
You can reach the person managing the list at
nznog-owner(a)list.waikato.ac.nz
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NZNOG digest..."
Today's Topics:
1. Orcon IPv6 rDNS delegation (Jonathan Spence)
2. Re: Orcon IPv6 rDNS delegation (Leo Vegoda)
3. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
4. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Sep 2013 02:08:47 +1200
From: "Jonathan Spence"
Welcome.
Looks like we are now not delegating. Sorry.
Will follow it up in the morning with a team member.
Some resolvers, ours included wont answer trace requests, its seen as cache snooping.
I would have to do a tcpdump an look but I suspect when dig does a +trace it is doing some queries without the RD flag set.
Could be what you are seeing with your trace attempts, could also be i haven't consumed nearly enough beer tonight and talking rubbish:)
Paul
________________________________
From: nznog-bounces(a)list.waikato.ac.nz [nznog-bounces(a)list.waikato.ac.nz] on behalf of Jonathan Spence [jonathan.spence(a)power-business.co.nz]
Sent: Tuesday, 17 September 2013 11:47 p.m.
To: nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] NZNOG Digest, Vol 129, Issue 1
Hi Paul,
Thanks for the assistance and pointing out a glaringly obvious problem :S.
NS records are all fixed but not seeing the delegation still. Should this happen now automatically or do Orcon still need to do something? I've now learnt how to use the Dig command but can't figure out how to trace it like in other posts.
Thanks,
Jonathan
[Spacer]
Jonathan Spence
Chief Information Officer
Mobile: +64-21-1055634
Work: +64-9-9503306
Web: power-business.co.nzhttps://power-business.co.nz
[Power Business Services Logo]
The information contained in this message is privileged and intended only for the recipient names. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. Views expressed in this message may notnecessarily be those of Power Business Services Limited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
[Spacer]
[Digitize Logo] [OASIS Logo] [NOVA Logo] [Files Online Logo]
________________________________
From: nznog-request(a)list.waikato.ac.nz
Sent: Monday, September 2, 2013 12:00 PM
To: nznog(a)list.waikato.ac.nz
Subject: NZNOG Digest, Vol 129, Issue 1
Send NZNOG mailing list submissions to
nznog(a)list.waikato.ac.nz
To subscribe or unsubscribe via the World Wide Web, visit
http://list.waikato.ac.nz/mailman/listinfo/nznog
or, via email, send a message with subject or body 'help' to
nznog-request(a)list.waikato.ac.nz
You can reach the person managing the list at
nznog-owner(a)list.waikato.ac.nz
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NZNOG digest..."
Today's Topics:
1. Orcon IPv6 rDNS delegation (Jonathan Spence)
2. Re: Orcon IPv6 rDNS delegation (Leo Vegoda)
3. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
4. Re: Orcon IPv6 rDNS delegation (Paul Tinson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Sep 2013 02:08:47 +1200
From: "Jonathan Spence"
On 2013-09-17, at 8:13, Paul Tinson
I believe it is listed as Orcon Magical Pony...
Or a version of unbound, depends of sleep deprivation levels...
If you use the acl and set allow, trace fails, set allow_snoop and trace works.
I seem to recall looking at what dig did during a +trace and it was doing non RD requests, it only showed up like that if you also happen to have @<IP> specified. Which while i type makes sense, because dig "Should" be acting as a recursor and doing non recursive queries.
Clearly I am rambling and in need of sleep. Sorry if you read all the way to this point:)
Paul
________________________________
From: Joe Abley [jabley(a)hopcount.ca]
Sent: Wednesday, 18 September 2013 12:25 a.m.
To: Paul Tinson
Cc: jonathan.spence(a)power-business.co.nz; nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] NZNOG Digest, Vol 129, Issue 1
On 2013-09-17, at 8:13, Paul Tinson
On 2013-09-17, at 08:42, Paul Tinson
I believe it is listed as Orcon Magical Pony... Or a version of unbound, depends of sleep deprivation levels...
If you use the acl and set allow, trace fails, set allow_snoop and trace works.
I had not actually ever heard of "cache snooping" as a concept. Resolvers exist to answer questions from their client pool, and mechanisms that act to ignore queries (like RRL on authoritative-only servers) are generally considered inappropriate for resolvers. "snooping" seems like a weird word for "using a service provided for you to use" :-)
I seem to recall looking at what dig did during a +trace and it was doing non RD requests, it only showed up like that if you also happen to have @<IP> specified. Which while i type makes sense, because dig "Should" be acting as a recursor and doing non recursive queries.
Clearly I am rambling and in need of sleep. Sorry if you read all the way to this point:)
Makes sense, RD=0 queries are not obviously client queries of the type you'd expect end-users to trigger, and dropping them doesn't seem like a completely horrible idea, although you're making assumptions about your users behaviour that might make the support phone ring. The unbound docs say: The action allow_snoop gives nonrecursive access too. This give both recursive and non recursive access. The name allow_snoop refers to cache snooping, a technique to use nonrecursive queries to examine the cache contents (for malicious acts). However, nonrecursive queries can also be a valuable debugging tool (when you want to examine the cache contents). In that case use allow_snoop for your administration host. which seems like it's intended to be used to expand the possible access to your server without opening it fully to the world ("give full access to my users, but allow non-users also to inspect the cache with queries that have RD=0 for diagnostic purposes"). I think the "malicious acts" above does not mean opening the cache to abuse, but rather giving people outside your user pool the opportunity to see whether your particular cache has been poisoned with respect to their names. If I'm reading that right, then I think the expectation is that you would provide full access to your own users, and (if you feel like it) provide allow_snoop access to others. I don't think the implication is that you should expect any advantage to restricting your own users with allow_snoop. ("allow_snoop" to the world would make you a reasonable amplifier for people doing reflection attacks, which I think makes it a bad idea unless contributing to the global effort to fill the pipes is part of your game plan.) I usually tell people that dig +trace is a pretty horrible diagnostic tool, for what that's worth. When it works it doesn't really mean that everything is ok, and when it fails it doesn't really mean that everything is broken. That's not very much awesome. Joe
Joe Abley (jabley) writes:
The action allow_snoop gives nonrecursive access too. This give both recursive and non recursive access. The name allow_snoop refers to cache snooping, a technique to use nonrecursive queries to examine the cache contents (for malicious acts). However, nonrecursive queries can also be a valuable debugging tool (when you want to examine the cache contents). In that case use allow_snoop for your administration host.
which seems like it's intended to be used to expand the possible access to your server without opening it fully to the world ("give full access to my users, but allow non-users also to inspect the cache with queries that have RD=0 for diagnostic purposes"). I think the "malicious acts" above does not mean opening the cache to abuse, but rather giving people outside your user pool the opportunity to see whether your particular cache has been poisoned with respect to their names.
I didn't know about allow_snoop until now, but I've often wondered why unbound didn't allow querying the cache with RD=0, which I've often used for debugging transient resolution issues. Now I do, but I find it odd that the motivation would be to let third party snoop one's cache. If anything, I'd just replace allow with allow_snoop for existing clients. Anything else sounds dangerous. Phil
On 2013-09-17, at 09:35, Phil Regnauld
Now I do, but I find it odd that the motivation would be to let third party snoop one's cache. If anything, I'd just replace allow with allow_snoop for existing clients. Anything else sounds dangerous.
Agreed. It seems slightly bizarre to me that "allow" doesn't allow RD=0 queries. Perhaps a better token than "allow" for the config file would be "allow_but_break_in_unexpected_ways". Joe
I hadn't really considered that not allowing RD=0 would cause any major problems, simply because of all the traffic i have monitored coming in to these current servers and those I managed at Telecom, the number of RD=0 queries was relatively tiny, so much so that it was in the margin of error:)
The operating theory we are currently under is allowing cache "snooping" could potentially allow an attack to enumerate what we hold.
Given that the cache at any point in time is full of a rather large number of entries this premise may not stack up.
Having said that, i havent seen any negative impact, or had the phones ringing due to this policy being in place.
Other than to say we couldn't do RD=0 queries to validate what the cache held.
Paul
On 18/09/2013, at 2:10 AM, Joe Abley
On 2013-09-17, at 09:35, Phil Regnauld
wrote: Now I do, but I find it odd that the motivation would be to let third party snoop one's cache. If anything, I'd just replace allow with allow_snoop for existing clients. Anything else sounds dangerous.
Agreed. It seems slightly bizarre to me that "allow" doesn't allow RD=0 queries. Perhaps a better token than "allow" for the config file would be "allow_but_break_in_unexpected_ways".
Joe _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
participants (4)
-
Joe Abley
-
Jonathan Spence
-
Paul Tinson
-
Phil Regnauld