Re: dname reverse delegation
On Tue, 13 Oct 2015 21:40:30 +0100,
Paul A wrote:
>
> I have a few /24 that I want to delegate using DNAME.
Are you expecting to save yourself trouble by doing so?
If not, you should probably reconsider.
If you decide DNAME is a useful trick, bear in mind that what DNAME
does is not really delegation, but just a trick for the lazy. I'm
actually one of those lazy people, so please understand that I don't
mean the word offensively. Besides, cleverer people than I have
recognized laziness as a virtue.
I have persuaded the administrator of the
1.0.0.7.7.0.1.0.0.2.ip6.arpa. zone to use a DNAME rather than a
delegation for f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa. Yes, this is for
IPv6, but it's conveniently to hand, and the principles are the
same. I have actually had second thoughts about this, and more than
once, but never felt worried enough that making the change needed
priority before the other things on my do-list.
The trouble I save by doing this is that of maintaining two zone
files for my and corresponding PTR records. Instead, I can
keep both together in one file, like this:
$ORIGIN no8.be.
bode3600IN 2001:770:13f:0:5054:ff:fe00:d978
8.7.9.d.0.0.e.f.f.f.0.0.4.5.0.5.0.0.0.0.f.3.1.0.0.7.7.0.1.0.0.2.ip6 3600 IN PTR
bode
Using 'dig', you can explore how it works, and what zones are
involved, by using commands such as these:
dig bode.no8.be
dig -x 2001:770:13f:0:5054:ff:fe00:d978
dig +trace -x 2001:770:13f:0:5054:ff:fe00:d978
dig f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa ns
dig no8.be ns
You can do the same for your /24's, if the administrator of the
parent reverse zone is minded to co-operate. Alternatively,
you can use a normal delegation and set up your zone as follows,
filling in the gaps appropriately.
$TTL 3600 ;; or whatever
$ORIGIN 13.168.192.in-addr.arpa.
@ IN SOA ...
IN NS ...
IN DNAME whatever.example.net.
Then, you populate the whatever.example.net. zone with the PTR records:
$TTL 3600 ;; or whatever
$ORIGIN whatever.example.net.
@ IN SOA ...
IN NS ...
0 IN PTR base-addr.whatever-else.example.net.
1 IN PTR some-host.whatever-else.example.net.
2 IN PTR anor-host.whatever-else.example.net.
;; and so on ...
255 IN PTR bcast-addr.whatever-else.example.net.
> Lets says I have 192.168.13.0/24 how would I go about doing reserve on
> the forwarding server using DNAME.
>
> Currently on the forwarding server I have
>
> NS ns.isp.com
>
> ;;
>
> DNAME 0/24
Don't be distracted by RFC2317. It describes the trickery you need
when you're dealing with a longer prefix (fewer addresses) than a
/24. If you have "a few /24", you can deal with them without
needing any of that.
> ;;
>
> ;;; delegate to server
>
> 0/24 NS ns.someserver.com.
>
> On the server handling the PTRs (ns.someserver.com) I have:
>
> zone "0/24.13.168.192.IN-ADDR.ARPA" {
>
> type master;
>
> file "/slvdb/db.13.168.192";
>
> };
>
> In the PTR server the zone file looks like a normal PTR file and when
> I query on this server its working, I get the DNAME/CNAME and PTR.
>
> However when I query on the forwarding server it’s not working, I just
> keep getting the CNAME over and over again but not actual PTR.
I'm not sure what in what sense you're using the term "forwarding
server".
If you mean the authoritative server where the DNAME record is sitting,
then I believe that this is normal. An authoritative server should
return just the DNAME and synthesized CNAME, as it's not responsible
for chasing down the CNAME reference. That's the job of a recursive
resolver.
> Shouldn’t the forwarding server query the PTR server since it has a
> 0/24 NS RR? It seems like because of the above DNAME RR it expects and
> zone file for the 0/24. However I just want to forward this.
I'm sorry. I don't understand what you think you're trying to achieve.
I hope this helps.
Best regards,
Niall O'Reilly
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ - override TXT records
Hi Mukund, Hi John, I would need a way to insert oder override a TXT record while still don’t touch all other records and let then pass through in a transparent way. So just having this would be best for my use-case but this removes all other RR. www.cisco.com TXT "CISCO-CLS=app-name:HTTP|app-class:TD” As I have learned this is not going to work: www.cisco.com CNAME rpz-passthru. www.cisco.com TXT "CISCO-CLS=app-name:HTTP|app-class:TD” and I need to take this path: wolfgang.dns-as.org A 193.34.28.108 wolfgang.dns-as.org TXT "CISCO-CLS=app-name:RPZ|app-class:TD” If the latter is the only solution which can’t scale as this could change without me getting a notice my approach will not work ;-(( If we agree that I am not doing something wrong and this seems to be a corner case does this implies the current BIND RPZ behavior works as designed or is more like a bug? Any other idea how this could be solved or do I need to write a script running dig to constantly update the A record inside my RPZ zone file to keep it current? Many thanks, Wolfgang > On 12 Oct 2015, at 10:59AM, Mukund Sivaraman wrote: > > Hi Wolfgang > > On Thu, Oct 08, 2015 at 11:25:14PM +0200, Wolfgang Riedel [CISCO] wrote: >> Hi Folks, >> >> I am currently struggling with using RPZ for inserting or overriding TXT >> resource records. >> >> This is my goal: >> >> ; do not rewrite www.cisco.com (so, PASSTHRU) and add or override >> missing metadata >> www.cisco.com CNAME rpz-passthru. >> www.cisco.com TXT "CISCO-CLS=app-name:HTTP|app-class:TD" >> >> What work's is that I can do one or the other but not both at the same time >> if I need to use a CNAME. >> >> This works: >> >> wolfgang.dns-as.org A 193.34.28.108 >> wolfgang.dns-as.org TXT "CISCO-CLS=app-name:RPZ|app-class:TD" >> >> but in reality this will not work for CDN or load-balanced sites which don't >> have fixed IP address. >> >> Any hint's what I am doing wrong? > > You aren't doing anything wrong. Yours is a corner case. > > I hope I understood what you're trying to do correctly: From the zone > comment, perhaps you want the TXT query type to return the TXT RDATA > you've supplied and everything else passthru to regular processing. It > can't be done as triggers don't use the question's TYPE field. > > An alternative is to include all the RRs for that QNAME in the answer > (your second example). Yours is a weird case, because you can't use the > following in the policy zone which named wouldn't allow loading (it > won't allow CNAME to coexist): > > www.cisco.com CNAME www.cisco.com.akadns.net. > www.cisco.com TXT "CISCO-CLS=app-name:HTTP|app-class:TD" > > So using the A record (your second example) or adding triggers for the > target of the CNAME record chain are your best bet. As the latter > varies, perhaps the former for your region would be best. > > Mukund ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dname reverse delegation
Paul A wrote: > I have a few /24 that I want to delegate using DNAME. > Lets says I have 192.168.13.0/24 how would I go about doing reserve on the > forwarding server using DNAME. Coincidentally I just published this draft less than three hours ago, and it describes how to use DNAME to reduce the need for delegations in the reverse DNS. https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall: Southerly 5 or 6, veering southwesterly 6 to gale 8 in northwest. Rough or very rough. Rain in northwest. Good, occasionally poor in northwest. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dname reverse delegation
Why are you trying to complicate the lookup process unnecessarially?
Just delegate 13.168.192.IN-ADDR.ARPA. People over use stuff that
really isn't needed and by doing so turn a relatively simple
proceedure into a complicated mess.
RFC 2317 delegation techniques really should only be used for /25
-> /32 sized address assignments. Despite what RFC 2317 says,
you can delegate down to the individual reverse name. RFC 2317
main purpose is reducing the number of delegations that need to
be made.
Forwarders are overused when a simple delegation is all that is
needed.
People forget that not all nameservers are configured to recurse
when testing.
In message <005001d105f7$664cdf70$32e69e50$@meganet.net>, "Paul A" writes:
>
> I have a few /24 that I want to delegate using DNAME.
>
> Lets says I have 192.168.13.0/24 how would I go about doing reserve on the
> forwarding server using DNAME.
>
> Currently on the forwarding server I have
>
> NS ns.isp.com
> ;;
> DNAME 0/24
> ;;
>
> ;;; delegate to server
>
> 0/24NS ns.someserver.com.
If the zone fragment above expands out to below then the NS record
is hidden by the DNAME record during normal resolution.
13.168.192.IN-ADDR.ARPA.NS ns.isp.com.
13.168.192.IN-ADDR.ARPA.DNAME 0/24.13.168.192.IN-ADDR.ARPA.
0/24.13.168.192.IN-ADDR.ARPA. NS ns.someserver.com.
Looking up 1.13.168.192.IN-ADDR.ARPA will result in this set of
CNAMES. I suspect you got away with this due to the local server
also serving 0/24.13.168.192.IN-ADDR.ARPA which resulted in you
hitting a different zone.
1.13.168.192.IN-ADDR.ARPA CNAME 1.0/24.13.168.192.IN-ADDR.ARPA
1.0/24.13.168.192.IN-ADDR.ARPA CNAME 1.0/24.0/24.13.168.192.IN-ADDR.ARPA
1.0/24.0/24.13.168.192.IN-ADDR.ARPA CNAME
1.0/24.0/24.0/24.13.168.192.IN-ADDR.ARPA
> On the server handling the PTRs (ns.someserver.com) I have:
>
> zone "0/24.13.168.192.IN-ADDR.ARPA" {
> type master;
> file "/slvdb/db.13.168.192";
> };
>
> In the PTR server the zone file looks like a normal PTR file and when I
> query on this server its working, I get the DNAME/CNAME and PTR.
See above about the local zone preventing the looping which would normally
happen.
> However when I query on the forwarding server it's not working, I just keep
> getting the CNAME over and over again but not actual PTR.
Which is what happens when you don't have the second zone.
> Shouldn't the forwarding server query the PTR server since it has a 0/24 NS
> RR? It seems like because of the above DNAME RR it expects and zone file for
> the 0/24. However I just want to forward this.
No.
> I know I can probably just slave off the PTR server but I rather try and do
> it this way unless someone suggests otherwise.
>
> Any ideas, thanks Paul
Stop trying to be overly smart. If you really must use a DNAME do something
like this.
13.168.192.IN-ADDR.ARPA. DNAME in-addr.arpa.example.net.
zone "in-addr.arpa.example.net" {
type master;
file "/masterdb/db.in-addr.arpa.example.net";
};
And don't forget to slave the zone with the DNAME record so that local
resolution works when the external network is down.
zone "13.168.192.IN-ADDR.ARPA" {
type slave;
masters { . };
file "/slvdb/db.13.168.192";
};
or
zone "168.192.IN-ADDR.ARPA" {
type slave;
masters { . };
file "/slvdb/db.168.192";
};
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
dname reverse delegation
I have a few /24 that I want to delegate using DNAME.
Lets says I have 192.168.13.0/24 how would I go about doing reserve on the
forwarding server using DNAME.
Currently on the forwarding server I have
NS ns.isp.com
;;
DNAME 0/24
;;
;;; delegate to server
0/24NS ns.someserver.com.
On the server handling the PTRs (ns.someserver.com) I have:
zone "0/24.13.168.192.IN-ADDR.ARPA" {
type master;
file "/slvdb/db.13.168.192";
};
In the PTR server the zone file looks like a normal PTR file and when I
query on this server its working, I get the DNAME/CNAME and PTR.
However when I query on the forwarding server it's not working, I just keep
getting the CNAME over and over again but not actual PTR.
Shouldn't the forwarding server query the PTR server since it has a 0/24 NS
RR? It seems like because of the above DNAME RR it expects and zone file for
the 0/24. However I just want to forward this.
I know I can probably just slave off the PTR server but I rather try and do
it this way unless someone suggests otherwise.
Any ideas, thanks Paul
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Request to DNS
To answer the question. What you do when given a name and a port is protocol specific. Read the protocol specification. Note if the port is the well known port for the protocol then it may be ignored. If the protocol does not specify most developers will just implement the protocol over that port to the specified host taking into account well known ports if needed. To used SRV with a protocol you need a specification that says to do so. Using SRV without such a specification results in undefined behaviour. This really isn't a DNS question. The DNS is just the database that stores the values that are being looked up. Mark In message , "Darcy Kevin (FCA)" writes: > > Harshith, > I think you need to understand the proportionality here: the > *vast*majority* of the time, the client already knows the port (because > ports tend to be pre-assigned for specific services), and only needs to > resolve the FQDN to one or more address records (A and/or records), > in order to make a connection. This isn't really a burden, or complicated > logic in the client software, since it can just call a generic hostname > lookup function (e.g. the traditional gethostbyname() or the more modern > getaddrinfo()). It's not like every application programmer needs to deal > with parsing packet contents, handling retries, dealing with label > compression, etc. This is all handled in the library routine. > > Only in a small minority of cases do clients go through the whole NAPTR > or SRV process. Some of the main scenarios for that include: > > * Microsoft Active Directory. The clients use SRV records as part > of the so-called "dc locator" process to find a domain controller that > provides a specific service > > * Certain IM clients (like Lync) use SRV records to find SIP > services > > * SIP telephony clients use NAPTR records > > Note that SMTP clients use MX records rather than SRV records. MX records > can be considered the simpler, mail-specific precursor to SRV records. > Theoretically, SMTP _could_ be switched over to use SRV records, but the > use of MX is so ingrained that it's probably not worth the (massive) > effort. > > If you look at nameserver query statistics, you'll see that the volume of > SRV and/or NAPTR queries on a typical nameserver/resolver is a miniscule > fraction of the A/ traffic. Where MX-record traffic falls between > those extremes, will depend a lot on whether the nameserver/resolver is > internal or external, whether the particular domain is heavily used for > mail, etc. > > > > - Kevin > > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Buxton > Sent: Tuesday, October 13, 2015 7:58 AM > To: Harshith Mulky > Cc: BIND Users > Subject: Re: SRV Request to DNS > > On Oct 5, 2015, at 11:51 PM, Harshith Mulky > mailto:harshith.mu...@outlook.com>> wrote: > Let us say we are having a FQDN and we need to Resolve it. It goes > through the procedure of determining the IP and Port using NAPTR/SRV/A > query mechanisms > > The question I have is if I have a FQDN with a Port Number already > determined, will it go through the Procedure of NAPTR/SRV/A query (or) > simply do a A query (or) Is this left to the client to apply the Logic? > > The client must supply the logic. DNS is conceptually a simple database > service - ask a question, get an answer. The logic of using NAPTR > records, SRV records, A records, records, and CNAME records is > mostly handled by the client. (CNAME and DNAME records are the primary > exception, triggering extra processing on the recursive name server.) > > Chris > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SRV Request to DNS
Harshith, I think you need to understand the proportionality here: the *vast*majority* of the time, the client already knows the port (because ports tend to be pre-assigned for specific services), and only needs to resolve the FQDN to one or more address records (A and/or records), in order to make a connection. This isn't really a burden, or complicated logic in the client software, since it can just call a generic hostname lookup function (e.g. the traditional gethostbyname() or the more modern getaddrinfo()). It's not like every application programmer needs to deal with parsing packet contents, handling retries, dealing with label compression, etc. This is all handled in the library routine. Only in a small minority of cases do clients go through the whole NAPTR or SRV process. Some of the main scenarios for that include: * Microsoft Active Directory. The clients use SRV records as part of the so-called "dc locator" process to find a domain controller that provides a specific service * Certain IM clients (like Lync) use SRV records to find SIP services * SIP telephony clients use NAPTR records Note that SMTP clients use MX records rather than SRV records. MX records can be considered the simpler, mail-specific precursor to SRV records. Theoretically, SMTP _could_ be switched over to use SRV records, but the use of MX is so ingrained that it's probably not worth the (massive) effort. If you look at nameserver query statistics, you'll see that the volume of SRV and/or NAPTR queries on a typical nameserver/resolver is a miniscule fraction of the A/ traffic. Where MX-record traffic falls between those extremes, will depend a lot on whether the nameserver/resolver is internal or external, whether the particular domain is heavily used for mail, etc. - Kevin From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Buxton Sent: Tuesday, October 13, 2015 7:58 AM To: Harshith Mulky Cc: BIND Users Subject: Re: SRV Request to DNS On Oct 5, 2015, at 11:51 PM, Harshith Mulky mailto:harshith.mu...@outlook.com>> wrote: Let us say we are having a FQDN and we need to Resolve it. It goes through the procedure of determining the IP and Port using NAPTR/SRV/A query mechanisms The question I have is if I have a FQDN with a Port Number already determined, will it go through the Procedure of NAPTR/SRV/A query (or) simply do a A query (or) Is this left to the client to apply the Logic? The client must supply the logic. DNS is conceptually a simple database service - ask a question, get an answer. The logic of using NAPTR records, SRV records, A records, records, and CNAME records is mostly handled by the client. (CNAME and DNAME records are the primary exception, triggering extra processing on the recursive name server.) Chris ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Request to DNS
On Oct 5, 2015, at 11:51 PM, Harshith Mulky wrote: > Let us say we are having a FQDN and we need to Resolve it. It goes through > the procedure of determining the IP and Port using NAPTR/SRV/A query > mechanisms > > The question I have is if I have a FQDN with a Port Number already > determined, will it go through the Procedure of NAPTR/SRV/A query (or) simply > do a A query (or) Is this left to the client to apply the Logic? The client must supply the logic. DNS is conceptually a simple database service — ask a question, get an answer. The logic of using NAPTR records, SRV records, A records, records, and CNAME records is mostly handled by the client. (CNAME and DNAME records are the primary exception, triggering extra processing on the recursive name server.) Chris___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
