Re: From AWS route 53 to Bind9
In message <1aeb1e7d-f2e2-dd1e-baf2-96729656f...@thelounge.net>, Reindl Harald writes: > > > Am 04.02.2017 um 22:30 schrieb Mark Andrews: > > It has been suggested many times that there should be a record which > > says which server(s) serve a zone for HTTP and HTTPS. We could do > > this with SRV (_http._tcp.example.com and _https._tcp.example.com) > > or we could come up with a new record example.com HTTP . > > for the thread starter - use https://intodns.com/ to find out and fix > common mistakes in dns zones > > > Browser vendors refuse to accept either of these solutions because > > they don't want to do a second DNS lookup for the server's addresses > > when the addresses are not included in the initial response. > > someone should point out to the browser vendors that this is technically > already the case when CNAMES pointing to a different domain and the > destination of the CNAME easily can be another CNAME pointing somewhere else They have been but they refuse to listen. Recursive servers marshal answers with cnames. > makes sense when different companies are involved for a lot of records > and each one wants a single entry for easier future changes instead > touch 50 or more > > well, not the browser itself but the involved DNS servers and i don't > see how that's different for the total response time since all that > stuff is also cached in the whole dns chain You add extra rtt between browsers and the recursive server when the additional section is not populated. > ___ > 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 -- 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: From AWS route 53 to Bind9
Am 04.02.2017 um 22:30 schrieb Mark Andrews: It has been suggested many times that there should be a record which says which server(s) serve a zone for HTTP and HTTPS. We could do this with SRV (_http._tcp.example.com and _https._tcp.example.com) or we could come up with a new record example.com HTTP . for the thread starter - use https://intodns.com/ to find out and fix common mistakes in dns zones Browser vendors refuse to accept either of these solutions because they don't want to do a second DNS lookup for the server's addresses when the addresses are not included in the initial response. someone should point out to the browser vendors that this is technically already the case when CNAMES pointing to a different domain and the destination of the CNAME easily can be another CNAME pointing somewhere else makes sense when different companies are involved for a lot of records and each one wants a single entry for easier future changes instead touch 50 or more well, not the browser itself but the involved DNS servers and i don't see how that's different for the total response time since all that stuff is also cached in the whole dns chain ___ 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: From AWS route 53 to Bind9
In message <1983df90-f101-afe4-2fbd-6cb243d60...@gmail.com>, Conconscious writes: > > Sorry I'm blocked in the other email account: > Remote host said: 554 mail server permanently rejected message (#5.3.0) > > I want to keep the 3 web servers and www.domain.com and only domain.com > reference. > > With current config: > > www.domain.com. CNAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > domain.com.CNAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > www.domain.com. CNAME > dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. > domain.com.CNAME > dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. > www.domain.com. CNAME > dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. > domain.com.CNAME > dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. > > Feb 4 named[27974]: dns_master_load: /etc/bind/db.domain.com:26: > www.domain.com: CNAME and other data > Feb 4 named[27974]: zone domain.com/IN: loading from master file > /etc/bind/db.domain.com failed: CNAME and other data You can't have a CNAME with any other data at the same owner name. This means you cannot have a CNAME at the apex of a zone as there is always a SOA record and a NS RRset there. CNAME is also a singleton record which means that there can only be one CNAME at a name. > with DNAME: > > www.domain.com. DNAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > domain.com.DNAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > www.domain.com. DNAME > dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. > domain.com.DNAME > dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. > www.domain.com. DNAME > dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. > domain.com.DNAME > dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. > > Feb 4 named[28045]: dns_master_load: /etc/bind/db.domain.com:28: > www.domain.com: multiple RRs of singleton type > Feb 4 named[28045]: zone domain.com/IN: loading from master file > /etc/bind/db.domain.com failed: multiple RRs of singleton type Two DNAME record at the same name are illegal. You are attempting to add 3 DNAME records at www.domain.com and domain.com. It has been suggested many times that there should be a record which says which server(s) serve a zone for HTTP and HTTPS. We could do this with SRV (_http._tcp.example.com and _https._tcp.example.com) or we could come up with a new record example.com HTTP . Browser vendors refuse to accept either of these solutions because they don't want to do a second DNS lookup for the server's addresses when the addresses are not included in the initial response. It doesn't matter to them that recursive servers could be make to always complete the address chain in the additional section for either of these solutions. There is nothing preventing recursive server vendors from doing this. Mark > Thanks. > > > On 02/04/2017 04:56 PM, Graham Clinch wrote: > > >> [...] > >> But I'm getting errors in bind9. > > What do the errors say? Perhaps the text will point either you or us > > to the cause. > > > > Graham > > --B52CEBE361218F6D5E15BE4D > Content-Type: text/html; charset=utf-8 > Content-Transfer-Encoding: 7bit > > > > > > > > > Sorry I'm blocked in the other email account: > Remote host said: 554 mail server permanently rejected message (#5.3.0) > > I want to keep the 3 web servers and href="http://ww > w.domain.com">www.domain.com and only domain.com > reference. > > With current config: > > href="http://www.domain.com;>www.domain.com. C > NAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > domain.com.CNAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > href="http://www.domain.com;>www.domain.com. C > NAME > dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. > domain.com.CNAME > dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. > href="http://www.domain.com;>www.domain.com. C > NAME > dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. > domain.com.CNAME > dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. > > Feb 4 named[27974]: dns_master_load: /etc/bind/db.domain.com:26: > href="http://www.domain.com;>www.domain.com: CNA > ME and other data > Feb 4 named[27974]: zone domain.com/IN: loading from master file > /etc/bind/db.domain.com failed: CNAME and other data > > with DNAME: > > href="http://www.domain.com;>www.domain.com. D > NAME > dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. > domain.com.DNAME >
Re: From AWS route 53 to Bind9
Sorry I'm blocked in the other email account: Remote host said: 554 mail server permanently rejected message (#5.3.0) I want to keep the 3 web servers and www.domain.com and only domain.com reference. With current config: www.domain.com. CNAME dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. domain.com.CNAME dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. www.domain.com. CNAME dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. domain.com.CNAME dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. www.domain.com. CNAME dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. domain.com.CNAME dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. Feb 4 named[27974]: dns_master_load: /etc/bind/db.domain.com:26: www.domain.com: CNAME and other data Feb 4 named[27974]: zone domain.com/IN: loading from master file /etc/bind/db.domain.com failed: CNAME and other data with DNAME: www.domain.com. DNAME dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. domain.com.DNAME dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. www.domain.com. DNAME dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. domain.com.DNAME dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. www.domain.com. DNAME dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. domain.com.DNAME dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. Feb 4 named[28045]: dns_master_load: /etc/bind/db.domain.com:28: www.domain.com: multiple RRs of singleton type Feb 4 named[28045]: zone domain.com/IN: loading from master file /etc/bind/db.domain.com failed: multiple RRs of singleton type Thanks. On 02/04/2017 04:56 PM, Graham Clinch wrote: >> [...] >> But I'm getting errors in bind9. > What do the errors say? Perhaps the text will point either you or us > to the cause. > > Graham ___ 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: From AWS route 53 to Bind9
> [...] But I'm getting errors in bind9. What do the errors say? Perhaps the text will point either you or us to the cause. Graham ___ 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: Re: Bind Queries log file format
On 04-Feb-17 04:27, Phil Mayers wrote: > On 03/02/17 16:45, Mukund Sivaraman wrote: > >> The query log is getting more fields at the end of it such as >> CLIENT-SUBNET logging. > > Although it would be super-disruptive, has any thought been given to > moving to an entirely new log format, for example k/v or JSON? They're > a lot more extendable going forward and most SIEM/ML systems will read > them with no additional configuration. > > Adding the query log hex/ptr thing just inconvenienced me. Strangely, > changing the entire format to k/v would have massively helped me. This > applies across all logs (RPZ in particular). > > Obviously one sample isn't enough but it's maybe something to consider? I'm not sure whether I'm in favor of this approach, but it's not necessarily very disruptive. It would be trivial to script a converter from JSON to the current log format - or even one that took a format string to select whatever fields in random order. Pipe a new log file though it to existing log readers, and you're done. For almost complete transparency, embed in a daemon that continuously reads the JSON log & appends to the traditional log; the existing log readers can read the old format in near real-time... Then when a support issue (or other requirement) comes up, the enhanced data is in the JSON log. When your old log processor is upgraded to use a new field, just add it to the converter (format). New processors would preferably read the JSON/native format directly. The only annoyance is having to manage 2 log files (and some disk space). FWIW smime.p7s Description: S/MIME Cryptographic Signature ___ 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
From AWS route 53 to Bind9
Hi all, I have a domain in AWS route 53 with this lines: domain.com. A ALIAS dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. domain.com. A ALIAS dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. domain.com. A ALIAS dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. My approach: www.domain.com. IN 2400:6500:ff00::34dc:53c9 domain.com.IN 2400:6500:ff00::34dc:53c9 www.domain.com. IN 2a01:578:13::239c:cb96 domain.com.IN 2a01:578:13::239c:cb96 www.domain.com. IN 2406:da00:ff00::34cd:deff domain.com.IN 2406:da00:ff00::34cd:deff www.domain.com. CNAME dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. domain.com.DNAME dualstack.ap-ulb-traffic-2039629984.ap-southeast-1.elb.amazonaws.com. www.domain.com. CNAME dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. domain.com.DNAME dualstack.ulb-traffic-eu-136029011.eu-central-1.elb.amazonaws.com. www.domain.com. CNAME dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. domain.com.DNAME dualstack.ulb-traffic-1103250353.us-east-1.elb.amazonaws.com. But I'm getting errors in bind9. Thanks in advance. ___ 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: Bind Queries log file format
On 04/02/2017 09:18, Phil Mayers wrote: On 03/02/17 16:53, Alan Clegg wrote: The "rndc" option allows those that KNOW that they may need the data begin the collection where everyone else isn't impacted. If you know that this customer is at risk, tell them "run this command, it's going FWIW, I would tend to agree with this approach; piling a bunch of mostly-unused data into the logs for these very rare events is not an obvious solution IMHO. Sorry I should expand on this point given my other mail; adding extra and largely-unused data absent a structured format is not an obvious solution; structure would change my stance on that, although one still wants to be reasonably parsimonious with space. ___ 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: Bind Queries log file format
On 03/02/17 16:45, Mukund Sivaraman wrote: The query log is getting more fields at the end of it such as CLIENT-SUBNET logging. Although it would be super-disruptive, has any thought been given to moving to an entirely new log format, for example k/v or JSON? They're a lot more extendable going forward and most SIEM/ML systems will read them with no additional configuration. Adding the query log hex/ptr thing just inconvenienced me. Strangely, changing the entire format to k/v would have massively helped me. This applies across all logs (RPZ in particular). Obviously one sample isn't enough but it's maybe something to consider? ___ 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: Bind Queries log file format
On 03/02/17 16:53, Alan Clegg wrote: The "rndc" option allows those that KNOW that they may need the data begin the collection where everyone else isn't impacted. If you know that this customer is at risk, tell them "run this command, it's going FWIW, I would tend to agree with this approach; piling a bunch of mostly-unused data into the logs for these very rare events is not an obvious solution IMHO. ___ 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
